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? 


 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.


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. 



begin 666 fe_simple.c



M2519.PT*(V5L<V4 +RH /R!C;VUP:6QE<B J+PT*97AT97)N(&-O;G-T(&-H
M87()1D5?4TE-4$Q%7U!23T-%4U-?241%3E1)5%E;73L-"B-E;F1I9B O*B!C


M*G!T;VME;BD-"GL-" E35$Q33T947U-54%!215-37U5.55-%1"AR97-E<G9E

M04Y42$5)3U-?0T%,3"AV;VED*2!P86YT:&5I;W-?9F5?=6YI;FET*'9O:60 
M*G1O:V5N*0T*>PT*"5-43%-/1E1?4U504%)%4U-?54Y54T5$*'1O:V5N*3L-
M"GT-" T*4$%.5$A%24]37T-!3$PH8VAA<B!C;VYS="HI('!A;G1H96EO<U]F



M;G1H96EO<U]F95]I<U-E=F5R:71Y3&]G9V5D*"  =F]I9 DJ=&]K96X-"B  
M("  ("  ("  ("  ("  ("  ("  ("  ("  ("  ("  ("  ("  ("  ("  



M4U504%)%4U-?54Y54T5$*'-E=F5R:71Y*3L-" E35$Q33T947U-54%!215-3

M('-E=F5R:71Y(#P


`
end
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 */


 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" <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 */


 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 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