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):
#   include BOOST_PP_STRINGIZE(boost/mpl/list/MPL_AUX_LIST_HEADER)

//from boost\preprocessor\stringize.hpp:
# if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MWCC()
#    define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text)
# else
#    define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_OO((text))
#    define BOOST_PP_STRINGIZE_OO(par) BOOST_PP_STRINGIZE_I ## par
# endif
# define BOOST_PP_STRINGIZE_I(text) #text

//from boost\mpl\list.hpp:
#   define MPL_AUX_LIST_HEADER \
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:
# if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MWCC()
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
# else
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_OO((a, b))
#    define BOOST_PP_CAT_OO(par) BOOST_PP_CAT_I ## par
# endif
#
# if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC()
#    define BOOST_PP_CAT_I(a, b) a ## b
# else
#    define BOOST_PP_CAT_I(a, b) BOOST_PP_CAT_II(a ## b)
#    define BOOST_PP_CAT_II(res) res
# endif

//from boost\mpl\limits\list.hpp:
#if !defined(BOOST_MPL_LIMIT_LIST_SIZE)
#   define BOOST_MPL_LIMIT_LIST_SIZE 10
#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
concatenate tokens, whereas it should use ##.

"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




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




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




 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):
 #   include BOOST_PP_STRINGIZE(boost/mpl/list/MPL_AUX_LIST_HEADER)

 //from boost\preprocessor\stringize.hpp:
 # if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MWCC()
 #    define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text)
 # else
 #    define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_OO((text))
 #    define BOOST_PP_STRINGIZE_OO(par) BOOST_PP_STRINGIZE_I ## par
 # endif
 # define BOOST_PP_STRINGIZE_I(text) #text

 //from boost\mpl\list.hpp:
 #   define MPL_AUX_LIST_HEADER \
 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:
 # if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MWCC()
 #    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
 # else
 #    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_OO((a, b))
 #    define BOOST_PP_CAT_OO(par) BOOST_PP_CAT_I ## par
 # endif
 #
 # if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC()
 #    define BOOST_PP_CAT_I(a, b) a ## b
 # else
 #    define BOOST_PP_CAT_I(a, b) BOOST_PP_CAT_II(a ## b)
 #    define BOOST_PP_CAT_II(res) res
 # endif

 //from boost\mpl\limits\list.hpp:
 #if !defined(BOOST_MPL_LIMIT_LIST_SIZE)
 #   define BOOST_MPL_LIMIT_LIST_SIZE 10
 #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
concatenate tokens, whereas it should use ##.




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:



  Summary: missing ## in some concatenations
  
  Initial Comment:
  in file "...boost\mpl\list.hpp":
  
  #   define MPL_AUX_LIST_HEADER 
  BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp /**/
  
  Results in a space being inserted in the filename, before 
  the period. Adding a "##" to the line above fixes the 
  problem, i.e.:
  
  .....,BOOST_MPL_LIMIT_LIST_SIZE)##.hpp /**/
  
  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
concatenate tokens, whereas it should use ##.







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




 submitted to boost, and the reply I got:

  Summary: missing ## in some concatenations

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

  #   define MPL_AUX_LIST_HEADER
  BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp /**/

  Results in a space being inserted in the filename, before
  the period. Adding a "##" to the line above fixes the
  problem, i.e.:

  .....,BOOST_MPL_LIMIT_LIST_SIZE)##.hpp /**/

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






I don't see how that derives from the spec. The only token concatention
allowed by the spec is with ##, extra whitespace should be quite irrelevant.


 and a concatenation here is undefined
 behavior.



## is defined as token concatenation, so I don't see how that is undefined.
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
allowed by the spec is with ##, extra whitespace should be quite irrelevant.


 and a concatenation here is undefined
 behavior.



## is defined as token concatenation, so I don't see how that is undefined.
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,
but only need dozens of ## in many files to work with DM.  I wouldn't be
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




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




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




 a kind of 'separator'..)?

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




 but only need dozens of ## in many files to work with DM.  I wouldn't be
 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
rely on the 'juxtaposition-equals-concatenation' kludge, the ## operator was
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
rely on the 'juxtaposition-equals-concatenation' kludge, the ## operator was
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