[PATCH 2/2] MAMDA: LLVM 5.1 Fixes - redeclared structs


Philip Preston
 

XCode 5.1 update includes LLVM/CLang 5.1 (CLang 3.4) which now fires a number of build errors.

struct FieldUpdateTradeId
struct FieldUpdateOrigTradeId

each are declared twice in MamdaTradeListener class

Signed-off-by: Phil Preston <philippreston@mac.com>
---
mamda/c_cpp/src/cpp/MamdaTradeListener.cpp | 2 --
1 file changed, 2 deletions(-)

diff --git a/mamda/c_cpp/src/cpp/MamdaTradeListener.cpp b/mamda/c_cpp/src/cpp/MamdaTradeListener.cpp
index 747c3cc..4e8c768 100644
--- a/mamda/c_cpp/src/cpp/MamdaTradeListener.cpp
+++ b/mamda/c_cpp/src/cpp/MamdaTradeListener.cpp
@@ -372,8 +372,6 @@ namespace Wombat
struct FieldUpdateSettleDate;
struct FieldUpdateOffExchangeTradePrice;
struct FieldUpdateOnExchangeTradePrice;
- struct FieldUpdateTradeId;
- struct FieldUpdateOrigTradeId;
struct FieldUpdateGenericFlag;
struct FieldUpdateShortSaleCircuitBreaker;
struct FieldUpdateOrigShortSaleCircuitBreaker;
--
1.8.5.2 (Apple Git-48)


Damian Maguire <DMaguire@...>
 

Cheers Phil, 

I've stuck this into Bugzilla,  BZ85, so we can track it there. Looks good anyway, just need some info on the compiler warnings you're seeing. 

D

From: Philip Preston <philippreston@...>
Date: Wednesday, April 2, 2014 8:56 PM
To: OpenMAMA Dev List <openmama-dev@...>
Subject: [Openmama-dev] [PATCH 2/2] MAMDA: LLVM 5.1 Fixes - redeclared structs

XCode 5.1 update includes LLVM/CLang 5.1 (CLang 3.4) which now fires a number of build errors.

struct FieldUpdateTradeId
struct FieldUpdateOrigTradeId

each are declared twice in MamdaTradeListener class

Signed-off-by: Phil Preston <philippreston@...>

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange Group, Inc. (ICE), NYSE Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.