www.digitalmars.com         C & C++   DMDScript  

c++ - space added to num by some prepro bug?

reply dan <dan_member pathlink.com> writes:
Fatal Error: g:\BAKNET\BAKNET.MAK(10865368): don't know how to make
.\boost-1.30.2\boost\mpl\list\list10 .hpp
Errors: 1  Warnings: 0
Build failed

notice the space between "list10" and ".hpp"

The file exists as named but without the space. Copying the file and adding the
space to the name appears to solve the problem. I can't find any bug in the
boost file that should be causing the anomaly, even highlighted the text in all
those macros to try and catch hidden blank spaces, and nothing. Here's the
relevant boost code:

//from boost\mpl\list.hpp (the line where the error occurs):


//from boost\preprocessor\stringize.hpp:








//from boost\mpl\list.hpp:

BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp \
/**/

//I'd say probably the problem occurs either in the macro above,
//or the one right below...

//from boost\preprocessor\cat.hpp:














//from boost\mpl\limits\list.hpp:
#if !defined(BOOST_MPL_LIMIT_LIST_SIZE)

#endif

Cheers!
Nov 28 2003
parent reply "Walter" <walter digitalmars.com> writes:
It's a bug in the boost headers. It's relying on juxtaposition to


"dan" <dan_member pathlink.com> wrote in message
news:bq8qvi$jn4$1 digitaldaemon.com...

 Fatal Error: g:\BAKNET\BAKNET.MAK(10865368): don't know how to make
 .\boost-1.30.2\boost\mpl\list\list10 .hpp
 Errors: 1  Warnings: 0
 Build failed

 notice the space between "list10" and ".hpp"

 The file exists as named but without the space. Copying the file and


adding the

 space to the name appears to solve the problem. I can't find any bug in


the

 boost file that should be causing the anomaly, even highlighted the text


in all

 those macros to try and catch hidden blank spaces, and nothing. Here's the
 relevant boost code:

 //from boost\mpl\list.hpp (the line where the error occurs):


 //from boost\preprocessor\stringize.hpp:








 //from boost\mpl\list.hpp:

 BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp \
 /**/

 //I'd say probably the problem occurs either in the macro above,
 //or the one right below...

 //from boost\preprocessor\cat.hpp:














 //from boost\mpl\limits\list.hpp:
 #if !defined(BOOST_MPL_LIMIT_LIST_SIZE)

 #endif

 Cheers!
Nov 28 2003
parent reply dan <dan_member pathlink.com> writes:
In article <bq8u65$obq$1 digitaldaemon.com>, Walter says...

It's a bug in the boost headers. It's relying on juxtaposition to




The boost guys appear to... not quite 'disagree', but... I'm too low level in
C++ to dare express an opinion of my own, but the following is the bug report I
submitted to boost, and the reply I got:




  
  Initial Comment:
  in file "...boost\mpl\list.hpp":
  

  BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp /**/
  
  Results in a space being inserted in the filename, before 

  problem, i.e.:
  

  
  I'm using latest betas for boost, STLport and Digital Mars.
  
  Regards.
  dan



The compilers are wrong to insert a space, and a concatenation here is undefined
behavior.  A better way to fix it would be to try this:

#define MPL_AUX_LIST_HEADER
MPL_AUX_LIST_HEADER_I(BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST
_SIZE))     /**/
#define MPL_AUX_LIST_HEADER_I(name) name.hpp

Regards,
Paul Mensonides
Dec 01 2003
parent reply "Walter" <walter digitalmars.com> writes:
"dan" <dan_member pathlink.com> wrote in message
news:bqfdld$nhl$1 digitaldaemon.com...

 In article <bq8u65$obq$1 digitaldaemon.com>, Walter says...

It's a bug in the boost headers. It's relying on juxtaposition to



 The boost guys appear to... not quite 'disagree', but... I'm too low level


in

 C++ to dare express an opinion of my own, but the following is the bug


report I

 submitted to boost, and the reply I got:



  Initial Comment:
  in file "...boost\mpl\list.hpp":


  BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp /**/

  Results in a space being inserted in the filename, before

  problem, i.e.:



  I'm using latest betas for boost, STLport and Digital Mars.


 The compilers are wrong to insert a space,


I don't see how that derives from the spec. The only token concatention



 and a concatenation here is undefined
 behavior.



Or perhaps I misunderstood you.


 A better way to fix it would be to try this:

 #define MPL_AUX_LIST_HEADER
 MPL_AUX_LIST_HEADER_I(BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST
 _SIZE))     /**/
 #define MPL_AUX_LIST_HEADER_I(name) name.hpp


If that works, I suppose it's good enough <g>.
Dec 01 2003
parent reply dan <dan_member pathlink.com> writes:
In article <bqgkt3$2jsj$1 digitaldaemon.com>, Walter says...

I don't see how that derives from the spec. The only token concatention



 and a concatenation here is undefined
 behavior.



Or perhaps I misunderstood you.


Walter, I'm no professed expert in C++, I don't even know what the Standard
looks like :)  I'm just acting as messenger between you and the boost guys.  I
once used concatenation, years ago, and I still shiver from the experience.
May I suggest a bit of a compromise?  I'm not sure he's right when he says...


 The compilers are wrong to insert a space,




.. but I'm sure it wouldn't hurt to remove it either. After all, you ARE
concatenating for them, right?  So why not remove the space while someone
figures out the best way to concatenate the file extension?

Just my 2c.

PS, I have a couple other postings about other problems, sorry that it took me 4
tries to submit one report right.



 A better way to fix it would be to try this:

 #define MPL_AUX_LIST_HEADER
 MPL_AUX_LIST_HEADER_I(BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST
 _SIZE))     /**/
 #define MPL_AUX_LIST_HEADER_I(name) name.hpp


If that works, I suppose it's good enough <g>.
Dec 01 2003
parent reply dan <dan_member pathlink.com> writes:
Even if 'concatenation' per-se is not called for, and against the Standard,
could it be that the "." (dot) relieves the preprocessor from responsibility for
adding a space at the end of the preceding string (since the dot already acts as
a kind of 'separator'..)?

I just find it hilarious how the boost libraries work with so many compilers,

surprised at all that they'd be all wrong; --won't be the first time that
everybody is wrong, but this bug may be just about ready for acceptance by
ANSI/ISO/whatever...  ;-)

Cheers!
dan
Dec 01 2003
parent reply "Walter" <walter digitalmars.com> writes:
"dan" <dan_member pathlink.com> wrote in message
news:bqgrf1$2t4t$1 digitaldaemon.com...

 Even if 'concatenation' per-se is not called for, and against the


Standard,

 could it be that the "." (dot) relieves the preprocessor from


responsibility for

 adding a space at the end of the preceding string (since the dot already


acts as

 a kind of 'separator'..)?

 I just find it hilarious how the boost libraries work with so many


compilers,


 surprised at all that they'd be all wrong; --won't be the first time that
 everybody is wrong, but this bug may be just about ready for acceptance by
 ANSI/ISO/whatever...  ;-)


The separator inserted by dmc is to make the preprocessor work right, it
isn't easilly removed. I don't really understand why boost seems to want to

added to Standard C specifically to move away from that practice.
Dec 01 2003
parent dan <dan_member pathlink.com> writes:
The separator inserted by dmc is to make the preprocessor work right, it
isn't easilly removed. I don't really understand why boost seems to want to

added to Standard C specifically to move away from that practice.


Ok, I'll re-report to them. Have you noticed my post titled "(my god, I forgot"?
There appears to be some missed inheritance relationship. I reported that to
STLport and they say it's the compiler.

Also, when I try to compile boost's state-machine example...
G:\boost-1.30.2\libs\mpl\example\fsm\player.cpp
..I get "no type for T" problem for quote.hpp and another header. I reported
this to boost, and they blame the compiler... ;-)
Anyways, this is the more crucial problem for me because,
a) I haven't a clue how to work around it and
b) I have a job to do for work with state machines (a BACnet interface) which
I coded entirely with boost's fsm while waiting for the DM CD.

Cheers!
dan
Dec 02 2003