• dan <dan_member pathlink.com> Nov 28 2003
• "Walter" <walter digitalmars.com> Nov 28 2003
• dan <dan_member pathlink.com> Dec 01 2003
• "Walter" <walter digitalmars.com> Dec 01 2003
• dan <dan_member pathlink.com> Dec 01 2003
• dan <dan_member pathlink.com> Dec 01 2003
• "Walter" <walter digitalmars.com> Dec 01 2003
• dan <dan_member pathlink.com> Dec 02 2003

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!

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!

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

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

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

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

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

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