www.digitalmars.com         C & C++   DMDScript  

c++.beta - DMC++ 8.48.5

reply Walter Bright <newshound digitalmars.com> writes:
Fixed wxWindows problem. -Walter

http://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip

http://www.digitalmars.com/download/freecompiler.html
Apr 28 2006
parent reply "W這dzimierz Skiba" <abx abx.art.pl> writes:
Walter Bright <newshound digitalmars.com> wrote in
news:e2uoho$1pbq$1 digitaldaemon.com:
 Fixed wxWindows problem. -Walter

Many, many thanks! Works fine. Another problem is related to linking. We have series of labels (names of controls) which we introduce in headers like: extern const wxChar wxStaticBoxNameStr[]; and later within .cpp file we give them value, like: extern const wxChar wxStaticBoxNameStr[] = "groupBox"; (with typedef char wxChar;) Every keyword in these constructions was added to please one of the compilers or build mode but they in current shape cause linking problem with DMC: .\..\..\lib\dmc_lib\wxmsw27d_core.lib(sizer) Error 42: Symbol Undefined ?wxStaticBoxNameStr 3QBDB (const char const *const wxStaticBoxNameStr) We had in this place char* rather than char[] and it worked fine but now it is failing. The strange thing is that only some of labels cause this linking error. Any idea? ABX
May 02 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
W這dzimierz Skiba wrote:
 We had in this place char* rather than char[] and it worked fine but now it is 
 failing. The strange thing is that only some of labels cause this linking
error. Any 
 idea? 

No, I don't know what's going on at the moment. But can you live with it for now?
May 02 2006
parent reply "W這dzimierz Skiba" <abx abx.art.pl> writes:
Walter Bright <newshound digitalmars.com> wrote in
news:e38sj1$2t9l$1 digitaldaemon.com: 
 Wlodzimierz Skiba wrote:
 We had in this place char* rather than char[] and it worked fine but
 now it is failing. The strange thing is that only some of labels
 cause this linking error. Any idea? 

No, I don't know what's going on at the moment. But can you live with it for now?

Not sure what kind of 'now' are you asking for :( On one hand it's kind of private problem since it's in development branch (ie. not in any release yet). OTOH the relase of these sources was planned at the end of April and we delay it due to not finished work around scripts for using more automation in releases. ABX
May 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
W這dzimierz Skiba wrote:
 Walter Bright <newshound digitalmars.com> wrote in
 news:e38sj1$2t9l$1 digitaldaemon.com: 
 Wlodzimierz Skiba wrote:
 We had in this place char* rather than char[] and it worked fine but
 now it is failing. The strange thing is that only some of labels
 cause this linking error. Any idea? 

it for now?

Not sure what kind of 'now' are you asking for :( On one hand it's kind of private problem since it's in development branch (ie. not in any release yet). OTOH the relase of these sources was planned at the end of April and we delay it due to not finished work around scripts for using more automation in releases.

I mean can you live with it without a change in the compiler?
May 04 2006
parent "W這dzimierz Skiba" <abx abx.art.pl> writes:
Walter Bright <newshound digitalmars.com> wrote in
news:e3de6i$2o26$1 digitaldaemon.com: 
 Not sure what kind of 'now' are you asking for :( On one hand it's
 kind of private problem since it's in development branch (ie. not in
 any release yet). OTOH the relase of these sources was planned at the
 end of April and we delay it due to not finished work around scripts
 for using more automation in releases. 

I mean can you live with it without a change in the compiler?

I don't think so :( These labels are part of public headers and replacing them from const char* to char* would require other people to change where they use them. And doing such change for only single release (until it's not fixed) would be not nice for them. Moreover I don't even know if they can be made non-const due to requirements of other ports. OTOH I don't want to put any pressure on you so I can live with informing people that this issue is 'under fixing' and the temporary fix it to do following changes in local copy: .... All in all it is for wxWidgets 2.7.0 which is named development release so things can be broken in this release ;) ABX
May 04 2006
prev sibling parent reply "Matthew" <nowhere noaddress.co.us> writes:
I've had the same problem with Pantheios.

I've just had to special-case DMC++, as in

#if defined(__DMC__)
extern const char *FE_SIMPLE_PROCESS_IDENTITY;
#else /* ? compiler */
extern const char FE_SIMPLE_PROCESS_IDENTITY[];
#endif /* compiler */





"W這dzimierz Skiba" <abx abx.art.pl> wrote in message 
news:e383ac$19e6$1 digitaldaemon.com...
 Walter Bright <newshound digitalmars.com> wrote in 
 news:e2uoho$1pbq$1 digitaldaemon.com:
 Fixed wxWindows problem. -Walter

Many, many thanks! Works fine. Another problem is related to linking. We have series of labels (names of controls) which we introduce in headers like: extern const wxChar wxStaticBoxNameStr[]; and later within .cpp file we give them value, like: extern const wxChar wxStaticBoxNameStr[] = "groupBox"; (with typedef char wxChar;) Every keyword in these constructions was added to please one of the compilers or build mode but they in current shape cause linking problem with DMC: .\..\..\lib\dmc_lib\wxmsw27d_core.lib(sizer) Error 42: Symbol Undefined ?wxStaticBoxNameStr 3QBDB (const char const *const wxStaticBoxNameStr) We had in this place char* rather than char[] and it worked fine but now it is failing. The strange thing is that only some of labels cause this linking error. Any idea? ABX

May 03 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Matthew wrote:
 I've had the same problem with Pantheios.
 
 I've just had to special-case DMC++, as in
 
 #if defined(__DMC__)
 extern const char *FE_SIMPLE_PROCESS_IDENTITY;
 #else /* ? compiler */
 extern const char FE_SIMPLE_PROCESS_IDENTITY[];
 #endif /* compiler */

The compiler doesn't emit data for unreferenced const declarations. To make it work, extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo"; will do it.
May 03 2006
parent reply "Matthew" <nowhere noaddress.co.us> writes:
It's not unreferenced. See attached file. (And all other compilers/linkers 
do the 'right' thing, so I'm assuming it is genuinely right. It certainly 
accords with my understanding of C these last 18 yrs. <g>)


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e3b89g$13r6$1 digitaldaemon.com...
 Matthew wrote:
 I've had the same problem with Pantheios.

 I've just had to special-case DMC++, as in

 #if defined(__DMC__)
 extern const char *FE_SIMPLE_PROCESS_IDENTITY;
 #else /* ? compiler */
 extern const char FE_SIMPLE_PROCESS_IDENTITY[];
 #endif /* compiler */

The compiler doesn't emit data for unreferenced const declarations. To make it work, extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo"; will do it.

May 03 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
I can't compile your file because it is incomplete. However, this file:
--------------
extern const char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";

const char *f()
{
     return FE_SIMPLE_PROCESS_IDENTITY;
}
--------------
compiles to:
--------------
FLAT    group
includelib SNN.lib

         public  ?f  YAPBDXZ
_TEXT   segment
         assume  CS:_TEXT
?f  YAPBDXZ:
                 mov     EAX,offset FLAT:_DATA
                 ret
_TEXT   ends
_DATA   segment
D0      db      066h,06fh,06fh,000h
_DATA   ends
--------------
So it is put in the object file, it just isn't made global. So, as a 
workaround, I suggest either removing the 'const' or referencing it via 
a function.


Matthew wrote:
 It's not unreferenced. See attached file. (And all other compilers/linkers 
 do the 'right' thing, so I'm assuming it is genuinely right. It certainly 
 accords with my understanding of C these last 18 yrs. <g>)
 
 
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e3b89g$13r6$1 digitaldaemon.com...
 Matthew wrote:
 I've had the same problem with Pantheios.

 I've just had to special-case DMC++, as in

 #if defined(__DMC__)
 extern const char *FE_SIMPLE_PROCESS_IDENTITY;
 #else /* ? compiler */
 extern const char FE_SIMPLE_PROCESS_IDENTITY[];
 #endif /* compiler */

make it work, extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo"; will do it.


May 03 2006
parent reply "Matthew" <matthew hat_synesis.dot_.com.dot_.au> writes:
So you're saying that, for DMC++, the const qualifier means that the extern 
aspect is ignored? Do I understand correctly?

I presume that that's not standard, but don't _know_. Am interested to hear 
your take on that.



"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e3bd9n$1dsu$1 digitaldaemon.com...
I can't compile your file because it is incomplete. However, this file:
 --------------
 extern const char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";

 const char *f()
 {
     return FE_SIMPLE_PROCESS_IDENTITY;
 }
 --------------
 compiles to:
 --------------
 FLAT    group
 includelib SNN.lib

         public  ?f  YAPBDXZ
 _TEXT   segment
         assume  CS:_TEXT
 ?f  YAPBDXZ:
                 mov     EAX,offset FLAT:_DATA
                 ret
 _TEXT   ends
 _DATA   segment
 D0      db      066h,06fh,06fh,000h
 _DATA   ends
 --------------
 So it is put in the object file, it just isn't made global. So, as a 
 workaround, I suggest either removing the 'const' or referencing it via a 
 function.


 Matthew wrote:
 It's not unreferenced. See attached file. (And all other 
 compilers/linkers do the 'right' thing, so I'm assuming it is genuinely 
 right. It certainly accords with my understanding of C these last 18 yrs. 
 <g>)


 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e3b89g$13r6$1 digitaldaemon.com...
 Matthew wrote:
 I've had the same problem with Pantheios.

 I've just had to special-case DMC++, as in

 #if defined(__DMC__)
 extern const char *FE_SIMPLE_PROCESS_IDENTITY;
 #else /* ? compiler */
 extern const char FE_SIMPLE_PROCESS_IDENTITY[];
 #endif /* compiler */

make it work, extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo"; will do it.



May 03 2006
parent Walter Bright <newshound digitalmars.com> writes:
Matthew wrote:
 So you're saying that, for DMC++, the const qualifier means that the extern 
 aspect is ignored? Do I understand correctly?
 
 I presume that that's not standard, but don't _know_. Am interested to hear 
 your take on that.

I'd have to go reread the spec carefully on that to see.
May 04 2006