Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

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

↑ ↓ ← 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:
# 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:
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
↑ ↓ "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):

//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:
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
↑ ↓ 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":

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
↑ ↓ "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":

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:

_SIZE))     /**/

If that works, I suppose it's good enough <g>.
Dec 01 2003
↑ ↓ 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:

_SIZE))     /**/

If that works, I suppose it's good enough <g>.

Dec 01 2003
↑ ↓ 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
↑ ↓ "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
↑ ↓ → 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