[preprocessor] pp-strings
Hello all, As I understand it, Boost.Preprocessor was largely based on another preprocessor library from the same authors named CHAOS. Is this correct? Do you know where I can find CHAOS source and its documentation? Specifically, I am curious if CHAOS supports "pp space-separated strings" -- i.e., macros like the followings: PP_STRING_CAT( b o o s t ) // expand to `boost` PP_STRING_AT(3, b o o s t ) // expand to `s` etc... If yes, why were these pp-strings not ported from CHAOS to Boost.Preprocessor? Thanks a lot. --Lorenzo
As I understand it, Boost.Preprocessor was largely based on another preprocessor library from the same authors named CHAOS. Is this correct?
No, chaos has been developed later.
Do you know where I can find CHAOS source and its documentation?
http://chaos-pp.cvs.sourceforge.net/viewvc/chaos-pp/ Regards Hartmut --------------- http://boost-spirit.com
On Mon, 20 Jun 2011 22:08:13 -0400, Lorenzo Caminiti wrote:
Hello all,
As I understand it, Boost.Preprocessor was largely based on another preprocessor library from the same authors named CHAOS. Is this correct? Do you know where I can find CHAOS source and its documentation?
Specifically, I am curious if CHAOS supports "pp space-separated strings" -- i.e., macros like the followings:
PP_STRING_CAT( b o o s t ) // expand to `boost` PP_STRING_AT(3, b o o s t ) // expand to `s` etc...
If yes, why were these pp-strings not ported from CHAOS to Boost.Preprocessor?
As Hartmut indicated, Chaos was developed after (and was loosely based on) Boost.Preprocessor. However, unlike Boost.Preprocessor, Chaos targets standard C and C++ (not particular compilers) and is therefore not limited by broken preprocessors (e.g. VC++). Regards, Paul Mensonides
On Sun, Jun 26, 2011 at 8:42 AM, Paul Mensonides <pmenso57@comcast.net> wrote:
As Hartmut indicated, Chaos was developed after (and was loosely based on) Boost.Preprocessor. However, unlike Boost.Preprocessor, Chaos targets standard C and C++ (not particular compilers) and is therefore not limited by broken preprocessors (e.g. VC++).
OK.
PP_STRING_CAT( b o o s t ) // expand to `boost` PP_STRING_AT(3, b o o s t ) // expand to `s` etc...
If yes, why were these pp-strings not ported from CHAOS to Boost.Preprocessor?
Any comment on "pp comma-separated strings" support (of lack of thereof) in Boost.Preprocessor and/or CHAOS? Thanks! --Lorenzo
On Sun, 26 Jun 2011 11:00:16 -0400, Lorenzo Caminiti wrote:
Any comment on "pp comma-separated strings" support (of lack of thereof) in Boost.Preprocessor and/or CHAOS?
Boost.Preprocessor represents the lowest common denominator in what can be made portable across most C and C++ compilers. The main roadblock to more significant improvement (nowadays) is VC++'s horrible preprocessor. By "comma-separated strings" I assume you mean something like: a, b, c? Boost.Preprocessor doesn't support them, of course. Chaos doesn't support them in that form (generally speaking, data structures containing open commas = bad design). Regards, Paul Mensonides
Paul Mensonides wrote:
On Sun, 26 Jun 2011 11:00:16 -0400, Lorenzo Caminiti wrote:
Any comment on "pp comma-separated strings" support (of lack of thereof) in Boost.Preprocessor and/or CHAOS?
Boost.Preprocessor represents the lowest common denominator in what can be made portable across most C and C++ compilers. The main roadblock to more significant improvement (nowadays) is VC++'s horrible preprocessor.
By "comma-separated strings" I assume you mean something like: a, b, c? Boost.Preprocessor doesn't support them, of course. Chaos doesn't support them in that form (generally speaking, data structures containing open commas = bad design).
I am sorry, I meant to say "*space* separated strings" (not commas). These are tokens like `a b c` where a character can be a-z, A-Z, 0-9, or _ and all characters must be separated from each other by one or more spaces. Concatenation can be used to parse these "space separated strings", for example (leaving aside reentrancy issues, etc): #include <boost/preprocessor.hpp> #define PP_STRING_CHAR_PP_STRING_NULL_NEXT() /* nothing */ #define PP_STRING_CHAR_PP_STRING_NULL PP_STRING_CHAR_PP_STRING_NULL_NEXT( #define PP_STRING_NEXT_c(str) BOOST_PP_CAT(PP_STRING_CHAR_, str) ) #define PP_STRING_CHAR_c (c) PP_STRING_NEXT_c( #define PP_STRING_NEXT_b(str) BOOST_PP_CAT(PP_STRING_CHAR_, str) ) #define PP_STRING_CHAR_b (b) PP_STRING_NEXT_b( #define PP_STRING_NEXT_a(str) BOOST_PP_CAT(PP_STRING_CHAR_, str) ) #define PP_STRING_CHAR_a (a) PP_STRING_NEXT_a( #define PP_STRING_TO_SEQ(str) \ BOOST_PP_CAT(PP_STRING_CHAR_, str PP_STRING_NULL) ) PP_STRING_TO_SEQ( a b c ) // expand to (a) (b) (c) Does CHAOS support these spaced-strings? Where these spaced-strings considered for Boost.Preprocessor? NOTE: This is more a curiosity than anything else because I don't actually have a real use case for these spaced-strings. I researched them because there was a request for a macro like: STRING_TO_TYPE( MyType ) // expand to: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; http://boost.2283326.n4.nabble.com/mpl-string-to-type-conversion-td2668494.h... As far as I know, such a macro cannot be implemented but both the following macros can be done (and I'd prefer somewhat (1) over (2)): SP_STRING_TO_TYPE( M y T y p e ) // (1) SEQ_STRING_TO_TYPE( (M)(y)(T)(y)(p)(e) ) // (2) Another example I was looking at is the possibility of removing the parenthesis around arbitrary function names in the signature below: CONTRACT_FUNCTION( void (myfunc) ( int x, (int&) y ) ) // (3) The following could be done (using pp spaced-strings): CONTRACT_FUNCTION( void m y f u n c ( int x, (int&) y ) ) // (4) But at the end I find (4) rather ugly and I chose to only support (3) instead (so no use for spaced-strings here). Thanks a lot! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/preprocessor-pp-strings-tp3613014p3627742... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 06/27/2011 03:39 PM, lcaminiti wrote:
NOTE: This is more a curiosity than anything else because I don't actually have a real use case for these spaced-strings. I researched them because there was a request for a macro like:
STRING_TO_TYPE( MyType ) // expand to: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; http://boost.2283326.n4.nabble.com/mpl-string-to-type-conversion-td2668494.h...
As far as I know, such a macro cannot be implemented but both the following macros can be done (and I'd prefer somewhat (1) over (2)):
SP_STRING_TO_TYPE( M y T y p e ) // (1) SEQ_STRING_TO_TYPE( (M)(y)(T)(y)(p)(e) ) // (2)
FYI, You can do STRING_TO_TYPE("MyType") or STRING_TO_TYPE(MyType) in C++0x by expanding it to "MyType"[0], "MyType"[1] etc.
On Mon, Jun 27, 2011 at 5:34 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
FYI, You can do STRING_TO_TYPE("MyType") or STRING_TO_TYPE(MyType) in C++0x by expanding it to "MyType"[0], "MyType"[1] etc.
IIRC you can do it even more directly with C++0x user-defined literals, though I don't think any compilers support them yet: "MyType"mpl_string -- -Matt Calabrese
On Mon, Jun 27, 2011 at 05:40:34PM -0400, Matt Calabrese wrote:
IIRC you can do it even more directly with C++0x user-defined literals, though I don't think any compilers support them yet:
"MyType"mpl_string
Note that according to N3290 17.6.4.3.5/1 - all suffixes that do not start with an underscore are reserved for future standardisation. -- Lars Viklund | zao@acc.umu.se
On 27/06/11 22:40, Matt Calabrese wrote:
On Mon, Jun 27, 2011 at 5:34 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
FYI, You can do STRING_TO_TYPE("MyType") or STRING_TO_TYPE(MyType) in C++0x by expanding it to "MyType"[0], "MyType"[1] etc.
IIRC you can do it even more directly with C++0x user-defined literals, though I don't think any compilers support them yet:
"MyType"mpl_string
By my reading of the standard that doesn't work with user defined string literals, only integer and floating point. User defined string literals can only be accessed at runtime. John Bytheway
On Mon, 27 Jun 2011 06:39:00 -0700, lcaminiti wrote:
Paul Mensonides wrote:
On Sun, 26 Jun 2011 11:00:16 -0400, Lorenzo Caminiti wrote:
Any comment on "pp comma-separated strings" support (of lack of thereof) in Boost.Preprocessor and/or CHAOS?
Boost.Preprocessor represents the lowest common denominator in what can be made portable across most C and C++ compilers. The main roadblock to more significant improvement (nowadays) is VC++'s horrible preprocessor.
By "comma-separated strings" I assume you mean something like: a, b, c? Boost.Preprocessor doesn't support them, of course. Chaos doesn't support them in that form (generally speaking, data structures containing open commas = bad design).
I am sorry, I meant to say "*space* separated strings" (not commas). These are tokens like `a b c` where a character can be a-z, A-Z, 0-9, or _ and all characters must be separated from each other by one or more spaces. Concatenation can be used to parse these "space separated strings", for example (leaving aside reentrancy issues, etc):
Chaos supports such data structures. E.g. #include <chaos/preprocessor/algorithm/reverse.h> #include <chaos/preprocessor/generics/strip.h> #include <chaos/preprocessor/string/core.h> CHAOS_PP_REVERSE( (CHAOS_PP_STRING) a b c d e f ) // (CHAOS_PP_STRING) f e d c b a CHAOS_PP_STRING_TO_UPPER( CHAOS_PP_STRIP( CHAOS_PP_REVERSE( (CHAOS_PP_STRING) a b c d e f ) ) ) // F E D C B A Regards, Paul Mensonides
Paul Mensonides wrote:
On Mon, 27 Jun 2011 06:39:00 -0700, lcaminiti wrote:
Paul Mensonides wrote:
On Sun, 26 Jun 2011 11:00:16 -0400, Lorenzo Caminiti wrote:
Any comment on "pp comma-separated strings" support (of lack of thereof) in Boost.Preprocessor and/or CHAOS?
Boost.Preprocessor represents the lowest common denominator in what can be made portable across most C and C++ compilers. The main roadblock to more significant improvement (nowadays) is VC++'s horrible preprocessor.
By "comma-separated strings" I assume you mean something like: a, b, c? Boost.Preprocessor doesn't support them, of course. Chaos doesn't support them in that form (generally speaking, data structures containing open commas = bad design).
I am sorry, I meant to say "*space* separated strings" (not commas). These are tokens like `a b c` where a character can be a-z, A-Z, 0-9, or _ and all characters must be separated from each other by one or more spaces. Concatenation can be used to parse these "space separated strings", for example (leaving aside reentrancy issues, etc):
Chaos supports such data structures. E.g.
#include <chaos/preprocessor/algorithm/reverse.h> #include <chaos/preprocessor/generics/strip.h> #include <chaos/preprocessor/string/core.h>
CHAOS_PP_REVERSE( (CHAOS_PP_STRING) a b c d e f ) // (CHAOS_PP_STRING) f e d c b a
CHAOS_PP_STRING_TO_UPPER( CHAOS_PP_STRIP( CHAOS_PP_REVERSE( (CHAOS_PP_STRING) a b c d e f ) ) ) // F E D C B A
Yep, this is pretty cool :)) especially the `(pp-data-type) pp-data` syntax. Great job with Chaos!! What will it take to port the (splendid) Chaos library into Boost? "Just" fixing VC++ pp or more? Btw, are Chaos docs online in HTML form somewhere? --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/preprocessor-pp-strings-tp3613014p3630324... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, 28 Jun 2011 06:18:46 -0700, lcaminiti wrote:
Paul Mensonides wrote:
What will it take to port the (splendid) Chaos library into Boost? "Just" fixing VC++ pp or more?
That probably still wouldn't be enough. VC++ is particularly bad, but it isn't the only poor preprocessor that Boost supports. What it would really take is a mentality shift. I will not put workarounds in Chaos regardless of length or practical utility (nor will I allow them). Chaos targets C and C++. It doesn't target a single compiler. Does a library that operates under that ethic belong in Boost? I'm not so sure.
Btw, are Chaos docs online in HTML form somewhere?
http://chaos-pp.cvs.sourceforge.net/viewvc/chaos-pp/chaos-pp/built-docs/ headers.html Regards, Paul Mensonides
participants (8)
-
Hartmut Kaiser -
John Bytheway -
Lars Viklund -
lcaminiti -
Lorenzo Caminiti
-
Mathias Gaunard -
Matt Calabrese -
Paul Mensonides