Rogue Wave C++ standardstdcomp.h

It is really neat that Sun C++ Studio 11 has been enhanced with the

latest patches to compile Boost (without ICU). To obtain the full

benefits, it seems necessary to tweak the Rogue Wave C++ standard

library header stdcomp.h to avoid compiler errors like:

% CC -DHAVE_CONFIG_H -I. -I../../../framework/common -I/h/goanna/1/sw/tntnet/include -I/usr/sfw/include -mt -c comp.cpp -KPIC -DPIC -o .libs/comp.o

"comp.cpp", line 70: Warning:::comp::localcomp_p_type::operator() hides the virtual function tnt::Component::operator()(tnt::HttpRequest&, tnt::HttpReply&, cxxtools::QueryParams&).

"comp.cpp", line 210: Error: Could not find a match for std::vector<std::string>::vector(cxxtools::QueryParams::const_iterator, cxxtools::QueryParams::const_iterator) needed in::comp::localcomp_type::operator()(tnt::HttpRequest&, tnt::HttpReply&, cxxtools::QueryParams&).

and a compiler error that occurs compiling code with std::difference

with 2 parameters. The tweaks are:

/% diff -wc /h/goanna/0/SC12_02_07/SUNWspro/prod/include/CC/Cstd/orig/stdcomp.h /h/goanna/0/SC12_02_07/SUNWspro/prod/include/CC/Cstd/stdcomp.h

*** /h/goanna/0/SC12_02_07/SUNWspro/prod/include/CC/Cstd/orig/stdcomp.h Thu Feb 8 23:18:51 2007

/h/goanna/0/SC12_02_07/SUNWspro/prod/include/CC/Cstd/stdcomp.hThu Apr 19 14:57:28 2007

***************

*** 1304,1311 ****

/* #define _RWSTD_NO_BAD_CAST 1 */

/* #define RWSTD_NO_BAD_CAST 1 */

! #define _RWSTD_NO_MEMBER_TEMPLATES 1

! #define RWSTD_NO_MEMBER_TEMPLATES 1

#define _RWSTD_NO_FRIEND_TEMPLATES 1

#define RWSTD_NO_FRIEND_TEMPLATES 1

1304,1311 -

/* #define _RWSTD_NO_BAD_CAST 1 */

/* #define RWSTD_NO_BAD_CAST 1 */

! /* #define _RWSTD_NO_MEMBER_TEMPLATES 1 */

! /* #define RWSTD_NO_MEMBER_TEMPLATES 1 */

#define _RWSTD_NO_FRIEND_TEMPLATES 1

#define RWSTD_NO_FRIEND_TEMPLATES 1

***************

*** 1406,1415 ****

#define _RWSTD_NO_INIT_CONST_TEMPLATE_REF_ARG 1

#define RWSTD_NO_INIT_CONST_TEMPLATE_REF_ARG 1

! #define _RWSTD_NO_CLASS_PARTIAL_SPEC 1

! #define RWSTD_NO_CLASS_PARTIAL_SPEC 1

! #define _RWSTD_NO_FUNC_PARTIAL_SPEC 1

! #define RWSTD_NO_FUNC_PARTIAL_SPEC 1

/* #define _RWSTD_NO_OVERLOAD_OF_TEMPLATE_FUNCTION 1 */

/* #define RWSTD_NO_OVERLOAD_OF_TEMPLATE_FUNCTION 1 */

1406,1415 -

#define _RWSTD_NO_INIT_CONST_TEMPLATE_REF_ARG 1

#define RWSTD_NO_INIT_CONST_TEMPLATE_REF_ARG 1

! /* #define _RWSTD_NO_CLASS_PARTIAL_SPEC 1 */

! /* #define RWSTD_NO_CLASS_PARTIAL_SPEC 1 */

! /* #define _RWSTD_NO_FUNC_PARTIAL_SPEC 1 */

! /* #define RWSTD_NO_FUNC_PARTIAL_SPEC 1 */

/* #define _RWSTD_NO_OVERLOAD_OF_TEMPLATE_FUNCTION 1 */

/* #define RWSTD_NO_OVERLOAD_OF_TEMPLATE_FUNCTION 1 */

/%

Thanks, Mark

[2940 byte] By [markw22a] at [2007-11-27 2:28:41]
# 1

Good point but are you sure these changes do not break all aspects of binary compatibility between application linked with libCstd without these changes and new version of libCstd. I think binary compatibility may be broken because changes in the header files affect binary code of libCstd That's why we do not implement new features in the libCstd and recommend to use stlport4 when you need to use Boost.

Atanasyana at 2007-7-12 2:41:09 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2

I did not rebuild libCstd.so.1, I only changed the stdcomp.h header file.

I wonder if these particular #define changes might only affect the header files, since they

are related to C++ templates.

However as you note, if these #define changes were made to stdcomp.h, and

libCstd.so.1 was rebuilt, it would be necessary to somehow check that the change is

binary compatible.

Thanks, Mark

Message was edited by:

markw22 - changed libstd to libCstd.so.1

markw22a at 2007-7-12 2:41:09 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3

If you modify any of the configuration parameters associated with libCstd, the code you compile will not match the runtime library. That is, the configuration parameters affect the members, size, and layout of the classes in the headers. Your program and the libCstd runtime library will have different ideas about what these classes look like. You cannot expect a program to run correctly under these circumstances.

clamage45a at 2007-7-12 2:41:09 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 4

To check those concerns, it is necessary to do a recursive grep on the #defines I changed

through all the header files, and inspect each match to see if it changed the size of any

data. I did that, and it looks OK to me. As in, these particular #defines only appear to

affect:

- the declarations and definitions of template methods. Since they are both in the header

files, this seems OK to me.

- some typedefs, however the changed typedefs appear to be compatible (same size).

I only did a quick check of each match. Since any change to the data would cause

serious problems, anyone comtemplating changing stdcomp.h should check those

concerns.

I understand that Sun could only make binary compatible changes to

the header files, and that the code changes would have to be carefully code reviewed.

Thanks, Mark

markw22a at 2007-7-12 2:41:09 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 5

By changing the configuration parameters, you also wind up using code from the headers that has never been tested by Sun. We do not support user modification of the libraries that we ship.

As noted in the C++ FAQ that comes with the compiler, you have two supported options in choosing a standard library:

1. Use libCstd without modification.

2. Use STLport if you need better conformance to the C++ Standard.

A third choice is to install your own 3rd-party library implementation, but you would have to get support from that 3rd party.

clamage45a at 2007-7-12 2:41:10 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 6

Another alternative is to use the Apache C++ Standard Library which is derived from

version 4.1.2 of the Rogue Wave C++ Standard Library (Sun ships an ancient version

of our code from 1999). Apache stdcxx is a conforming and highly efficient

implementation of the C++ Standard Library that's portable to and certified in dozens

of environments, including all versions of Sun C++ starting with 5.3 on Solaris/SPARC

and Solaris/x86. You can get a glimpse of the platforms stdcxx is nightly tested on by

following this link: http://people.apache.org/~sebor/stdcxx/results/

Like all Apache projects stdcxx is free to use. It is being maintained and supported

by the open source community around the project which includes a team of Rogue

Wave contributors.

See this page for more information about the library:

http://incubator.apache.org/stdcxx/

sebor@roguewave.coma at 2007-7-12 2:41:10 > top of Java-index,Development Tools,Solaris and Linux Development Tools...