Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
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.
Sent: Tuesday, October 03, 2017 10:27 AM
To: Yury Batrakov <yury.batrakov@...>; openmama-users <openmama-users@...>; openmama-dev <openmama-dev@...>
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
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD
velatradingtech.com | @vela_tt
From:
openmama-dev-bounces@... <openmama-dev-bounces@...> 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.
No problem Yury,
Yes, if I remember correctly the problem here was with some compilers which warned about the declaration of a deprecated method, which meant we wanted to both mark it as deprecated and also silence the deprecation warning at the same time. Not the most straight
forward of things to manage in a portable cross platform fashion unfortunately.
Regarding the deprecated method, the 'mamaMsg_createForPayloadBridge ()' method was specifically created to handle this case - using the payload bridge itself to generate the message, rather than a simple identifier. There's an
accessor for the payload bridges as well - 'mama_getPayloadBridge ()' (declared in mama.h) which you can use to search for an already loaded payload bridge. (it returns NULL in the case of a bridge not being found). Alternatively, 'mama_loadPayloadBridge ()'
will either load the bridge or return an already loaded bridge if it exists.
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
Sent: 03 October 2017 10:07
To: Damian Maguire; openmama-users; openmama-dev
Subject: RE: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
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@...>; openmama-dev <openmama-dev@...>
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
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD
velatradingtech.com | @vela_tt
From:
openmama-dev-bounces@... <openmama-dev-bounces@...> 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.
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
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
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
Classification: Public
Thanks for the details guys!
Sent: Tuesday, October 03, 2017 8:53 PM
To: Yury Batrakov <yury.batrakov@...>
Cc: Damian Maguire <dmaguire@...>; openmama-users <openmama-users@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
Hi Yury,
Yes that method is deprecated because OpenMAMA prefers dynamic loading methods now (so that payloads don't need to be registered in OpenMAMA's core code to load or depend on magic characters).
Have you looked at mamaMsg_createForPayloadBridge? It should do the same thing, but accepts a payload bridge rather than a char identifier and is not deprecated.
Damian also provided some helper functions included 6.2.1 to help look up bridges by name which might be helpful for lookup and cache, including mama_getPayloadBridge.
Cheers,
Frank
On Tue, Oct 3, 2017 at 10:07 AM, Yury Batrakov <yury.batrakov@...> wrote:
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@...>; openmama-dev <openmama-dev@...>
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
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD
velatradingtech.com | @vela_tt
From: openmama-dev-bounces@... <openmama-dev-bounces@...> 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@...
https://lists.openmama.org/mailman/listinfo/openmama-dev
---
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.