Classification: For internal use only

Hey Damian,

 

OK, thank you for clarification. The reason why I thought that deprecation warnings should be deleted automatically (after defining MAMA_DLL and BRIDGE preprocessor variables) is the following declaration of mamaMsg_createForPayload

MAMAIgnoreDeprecatedOpen

MAMAExpDeprecatedDLL(

        "mamaMsg_createForPayload has been deprecated, use dynamic loading instead!")

extern mama_status

mamaMsg_createForPayload (mamaMsg* msg, const char id);

MAMAIgnoreDeprecatedClose

 

The background of this question is: I’m writing a middleware bridge which always has to create messages for specific payload - it’s a problem because mamaMsg_createForPayload is deprecated and mamaMsg_create creates messages for “default” payload - the payload initialized by a first bridge created by OpenMAMA. This will be a problem when two or more bridges are loaded to a process.

 

 

From: Damian Maguire [mailto:dmaguire@...]
Sent: Tuesday, October 03, 2017 10:27 AM
To: Yury Batrakov <yury.batrakov@...>; openmama-users <openmama-users@lists.openmama.org>; openmama-dev <openmama-dev@....org>
Subject: Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux?

 

Hey Yury,

 

I'm not sure the behaviour you're describing is an issue - the purpose of the pragma's is to allow you to use 'deprecated' features of the API without generating warnings, rather than disable the deprecation completely. For example, when we implemented dynamic loading, we deprecated the 'mamaPayloadType' here. However, in order to support legacy clients, we continue to use the type within the MAMA codebase. We generally aim to be 'warning free' in the code, and understand the risks associated with using the type, so where we make use of mamaPayloadType we mark them with MamaIgnoreDeprecatedOpen and MamaIgnoreDeprecatedClose pragma's. This disables the deprecation specific warnings at those sites - for example, here.

 

Using your code, the equivalent would be:

 

int __attribute__((deprecated)) b() {

   return 0;

}

 

int main() {

        printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__);

MamaIgnoreDeprecatedOpen

        b();

MamaIgnoreDeprecatedClose

        return 0;

}

 

Which shouldn't warn about the use of b();.

 

Let me know if that makes sense, or if you have further questions around this.

 

Thanks,

 

Damian

 

 

DAMIAN MAGUIRE 

Senior Sales Engineer 

 

O. +44 289 568 0298  

M. +44 783 584 4770 

dmaguire@... 

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD  

velatradingtech.com | @vela_tt

 

 

---

From: openmama-dev-bounces@lists.openmama.org <openmama-dev-bounces@lists.openmama.org> on behalf of Yury Batrakov <yury.batrakov@...>
Sent: 02 October 2017 17:16
To: openmama-users; openmama-dev
Subject: [Openmama-dev] Did MAMAIgnoreDeprecatedOpen ever work on Linux?

 

Classification: Public

Hi team,

 

Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6?

See the following example:

 

// Next 3 lines were copied from wombat/…/linux/port.h

_Pragma ("GCC diagnostic push")

_Pragma ("GCC diagnostic ignored \"-Wdeprecated\"")

_Pragma ("GCC diagnostic ignored \"-Wdeprecated-declarations\"")

 

int __attribute__((deprecated)) b() {

   return 0;

}

 

_Pragma ("GCC diagnostic pop")

 

int main() {

        printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__);

        b();

        return 0;

}

 

When compiling with 4.8 it shows the following warnings anyway:

/opt/gcc/gcc-4.8.1/bin/g++ -Wall -Wextra 123.c

123.c: In function ‘int main()’:

123.c:15:9: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations]

         b();

         ^

123.c:15:11: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations]

         b();

           ^

 

But if we place those pragmas around invocation of b() (not around the definition) all warnings go away

---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC

---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev