Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>>>Your correction above makes everything clear to me now.
>> So do you feel you need an additional library feature? ;-)
>
> I suppose not. What I really wanted was the ability to take a
> regular old template class and create a generator out of it:
>
> template
> struct my_type { ... } // Note: no ::type member
>
> typedef SHAZAM > generator;
>
> typedef generator::template apply::type my_type_inst;
>
> I want SHAZAM to be generic enough to take any template class,
> not just my_type.
You can do that, up to N arguments, for some N.
> If I understand your solution correctly,
> it requires a manually-constructed generator for my_type:
>
> template
> struct my_type_generator {
>typedef my_type type;
> };
>
> SHAZAM then becomes mpl::lambda.
>
> The problem is, I'll have to create these trivial "generators"
> (I hesitate to even call it that) many times over, once for each
> class I want to bind.
>
> But I can construct a generic trivial generator:
>
> template class Base,
> typename T, typename U, typename V>
> struct trivial_generator {
> typedef Base type;
> };
>
> Then I can use MPL lambda facilities. Unfortunately, I need a
> trivial_generator for every arity of class template.
Only as part of the implementation. You just need a nice wrapper over
the top to hide it all.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Making Generators
- Original Message -
From: "David B. Held" <[EMAIL PROTECTED]>
> "Jon Kalb" <[EMAIL PROTECTED]> wrote in message
>
news:[EMAIL PROTECTED]
> icrosoft.com...
> > [...]
> > Vandevoorde and Josuttis call it SFINAE, "substitution failute is not an
> > error."
>
> Ah, I've heard of this, but didn't realize what it was all about.
>
> > In "C++ Templates: The Complete Guide" (Recommended), they give
> > this example on pages 106-107:
> >
> > typedef char RT1;
> > typedef struct {char a[2];} RT2;
> > template RT1 test(typename T::X const*);
> > template RT2 test(...);
> >
> > #define type_has_member_type_X(T) \
> > (sizeof(test(0) == 1)
>
> This is cool. What compilers are known to support it?
Comeau C++ certainly supports it (what a surprise...). BTW, this is nothing
new. It was discovered a while back based on an "is_enum" implementation,
which was converted to an "is_class" implementation, which, finally, was
converted to a "has_member_..." implementation. (I think by Rani Sharoni,
but I'm not sure.) The bad part about it is that there is no way, given the
nature of the solution, to parametize the member name.
Also, SFINAE, according to the standard does not apply to expression errors,
and is very unclear about what happens, for example in the code above, if
"X" is a template instead of a regular type.
I talked to Daveed Vandevoorde about this issue this past week. Supposedly,
the SFINAE principle used to be very broad, but compilers were having
difficulty implementing it "robustly," so they (as in core-3) dumbed it down
to only include the "list of ways that deduction/substitution can fail" in
14.8.2. This list is, in effect, a list of negatives--which IMO is a bad
idea. Apparently, they've added things to this list in each of the last
three core-3 meetings (or whatever they are).
Personally, I believe the SFINAE principle should be significantly broader.
The original argument about the "difficulty" of a robust implementation is
pretty bogus considering that most compilers won't handle just the invalid
type-creation attempts listed in 14.8.2 anyway. Also, the line between
"invalid type" and "invalid expression" is significantly blurred because of
the sizeof and typeid operators (not to mention "invalid templates").
Consider again how brittle the above might be:
template char test(typename T::X const*);
template char (& test(...))[2];
#define has_member_type_X(T) \
(sizeof( test(0) ) == 1)
struct Y {
template struct X { };
};
has_member_type_X(Y) // ?
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
On Thursday 05 December 2002 02:41 pm, David Abrahams wrote: > I propose: > > #ifndef BOOST_STRICT_CONFIG > # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol > test) #else > # define BOOST_WORKAROUND(symbol, test) 0 > #endif > > Comments? I'm still not sure that BOOST_STRICT_CONFIG is the right macro to determine if workarounds are enabled or not, but if John agrees then I'm happy with it. Regardless of what macro determines which BOOST_WORKAROUND is used, I like the above definition (+ dumb compiler workarounds). Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote:
Your correction above makes everything clear to me now.
So do you feel you need an additional library feature? ;-)
I suppose not. What I really wanted was the ability to take a
regular old template class and create a generator out of it:
template
struct my_type { ... } // Note: no ::type member
typedef SHAZAM > generator;
typedef generator::template apply::type my_type_inst;
I want SHAZAM to be generic enough to take any template class,
not just my_type. If I understand your solution correctly,
it requires a manually-constructed generator for my_type:
template
struct my_type_generator {
typedef my_type type;
};
SHAZAM then becomes mpl::lambda.
The problem is, I'll have to create these trivial "generators"
(I hesitate to even call it that) many times over, once for each
class I want to bind.
But I can construct a generic trivial generator:
template class Base,
typename T, typename U, typename V>
struct trivial_generator {
typedef Base type;
};
Then I can use MPL lambda facilities. Unfortunately, I need a
trivial_generator for every arity of class template. But I
don't think there's any way around that. MPL needs the same
thing for its placeholders. It just seems a shame that this
enumeration needs to be repeated for this special case when
it already exists for _1, _2, etc.
I don't know... well, it could detect whether there was a ::type
member, and if it were not present, it could just give you the outer
class. I think that's a bit of a hack, though.
Agreed. Urk...I'm not sure how to get around this problem without
requiring template template parameters (beyond what's used for
placeholders currently).
There's no way. So what? Your compiler supports them.
Of course. But others don't. I'm more concerned about the duplication
of effort described above. But again, I don't think there's any way
around that.
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
Gennaro Prota <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: > [...] >> I propose: >> >> #ifndef BOOST_STRICT_CONFIG >> # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test) >> #else >> # define BOOST_WORKAROUND(symbol, test) 0 >> #endif >> >> Comments? > > Sorry for jumping in without really following this thread. I'm busy > and just trying to read the posts quickly. This example struck me > though. Please take a look at this: > > http://groups.google.com/groups?threadm=m4TT8.211653%24nZ3.100438%40rwcrnsc53 Hmm. Well, if it's non-conforming we probably shouldn't use it. If it's just a vc bug, we could do something like #ifndef BOOST_STRICT_CONFIG # ifdef BOOST_MSVC # define BOOST_WORKAROUND(symbol, test) BOOST_DEFINED_##symbol && symbol test # define BOOST_DEFINED_BOOST_MSVC BOOST_MSVC # define BOOST_DEFINED_BOOST_DINKUMWARE_STDLIB BOOST_DINKUMWARE_STDLIB ... # else # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test) #else # define BOOST_WORKAROUND(symbol, test) 0 #endif -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, December 05, 2002 9:38 PM Subject: Re: [boost] [Config] Testing instructions for compiler vendors > [EMAIL PROTECTED] (Joerg Walter) writes: > > >> > >> 1. Should we do something to make this easier for them? > > > > No. We should focus on serving our users. > > Our users will be happy and our lives will be easier if their > compilers finally start working. Didn't they have enough time and resources to work this out 'til now? Best regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
[EMAIL PROTECTED] (Joerg Walter) writes: >> >> 1. Should we do something to make this easier for them? > > No. We should focus on serving our users. Our users will be happy and our lives will be easier if their compilers finally start working. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: "boost" <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 9:27 PM Subject: [boost] [Config] Testing instructions for compiler vendors > > Hi, > > I'm trying to come up with instructions for compiler vendors who want > to use Boost to test their compilers. What preprocessor symbols do > they need to define? So far, it looks like: > > - BOOST_NO_COMPILER_CONFIG > - BOOST_NO_STDLIB_CONFIG - if they want to check the library > - BOOST_STRICT_CONFIG - to disable some checks in source code > - macros for any known-not-implemented features, >e.g. BOOST_NO_TEMPLATE_TEMPLATES. > > Right? > > Questions: > > 1. Should we do something to make this easier for them? No. We should focus on serving our users. > 2. What about all the places we make compiler-specific checks in >Boost code? Could we define some macros which make it easier >and less error-prone to write these, and which can be globally >turned off when needed? > > # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) > ... > #else > ... > #endif I'm sometimes not even able to decide who is wrong ;-( Best regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
--- David Abrahams <[EMAIL PROTECTED]> wrote: [...] > I propose: > > #ifndef BOOST_STRICT_CONFIG > # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test) > #else > # define BOOST_WORKAROUND(symbol, test) 0 > #endif > > Comments? Sorry for jumping in without really following this thread. I'm busy and just trying to read the posts quickly. This example struck me though. Please take a look at this: http://groups.google.com/groups?threadm=m4TT8.211653%24nZ3.100438%40rwcrnsc53 Genny. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: unicode support
Vladimir Prus wrote: First interpretation is that you're interested in support for different Unicode encodings, via appropriate facets. Then Alberto Barbati is the last person who touches this matter, in news://news.gmane.org:119/aq72e4$pog$[EMAIL PROTECTED] I assume he's holding a lock on implementation work. Alberto, did you get anywhere? Yes, despite the clear lack of interest from Boosters about this issue, I'm still working on it ( but I don't have any "lock" ;) ). I had a few problems with the interpretation of the standard, but thanks to a few guys from comp.std.c++ I can now say that I have a working implementation of facets to converts from UTF-8/16/32 (external) to UTF-16/32 (internal), with endian variants, a total of 10 facets. The implementation fulfill a basic suite of tests on VS.NET with both the native STL and STLport. The facets are conformant to Unicode 3.2 requirements about non-characters, use of surrogates and non-shortest UTF-8 sequences. After a private discussion with a field expert, I decided to drop the UCS-2 facets, so surrogate support is no longer optional. I also decided to drop facets with UTF-8 as the internal encoding because they are not very useful and the current wording of the C++ standard de facto disallows a portable implementation :(. I hope the LWG would consider clarifying the issue. My next steps would be to polish the code, write the docs and prepare a more complete test suite. If everything goes well, I think I could submit the library for review by the end of the month. Second interpretation is conversion between all the 8-bit encodings out there. E.g. from koi8-r to windows-1251. Since there's GNU iconv already, I'd rather see a tiny wrapper over it. (GNU iconv works on Windows, too). Here things become more complex. UTF conversions are just algorithmic stuff, easy to do. Other conversions like koi8-r o windows-1251 require look-up tables and simply gathering the data for all of them will be equivalent to rewriting a part of ICU, which is a huge piece of work. The idea of wrapping ICU is very interesting. However the Boost policy explictly disallows dependencies from external libraries, so this solution is out of discussion. Moreover, the only things ICU is missing are the conversion facets. I don't see any reason to wrap anything else. Unfortunately, as I said before, not all conversions can be portably expressed as a facet with the current C++ standard, so even writing wrapping facets has little meaning. Alberto Barbati ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [MPL] Making Generators
"Jon Kalb" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
icrosoft.com...
> [...]
> Vandevoorde and Josuttis call it SFINAE, "substitution failute is not an
> error."
Ah, I've heard of this, but didn't realize what it was all about.
> In "C++ Templates: The Complete Guide" (Recommended), they give
> this example on pages 106-107:
>
> typedef char RT1;
> typedef struct {char a[2];} RT2;
> template RT1 test(typename T::X const*);
> template RT2 test(...);
>
> #define type_has_member_type_X(T) \
> (sizeof(test(0) == 1)
This is cool. What compilers are known to support it?
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> I'm trying to come up with instructions for compiler vendors who want >> to use Boost to test their compilers. What preprocessor symbols do >> they need to define? So far, it looks like: >> >> - BOOST_NO_COMPILER_CONFIG >> - BOOST_NO_STDLIB_CONFIG - if they want to check the library >> - BOOST_STRICT_CONFIG - to disable some checks in >> source code >> - macros for any known-not-implemented features, >>e.g. BOOST_NO_TEMPLATE_TEMPLATES. >> >> Right? > > As far as I understand, defining BOOST_STRICT_CONFIG only should be > sufficient (for compiler tests) - given that the compiler being > tested has a bumped up version number. That's a big assumption. Some vendors will want to check their current release, and sometimes we begin to set up configuration for pre-released compilers. >> >> 2. What about all the places we make compiler-specific checks in >>Boost code? Could we define some macros which make it easier >>and less error-prone to write these, and which can be globally >>turned off when needed? >> >> # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) >> ... >> #else >> ... >> #endif >> > > The checks for the past versions of the compiler, e.g. > > #if defined(BOOST_MSVC) && BOOST_MSVC <= 1300 > # define BOOST_MPL_MSVC_ETI_BUG > #endif > > are harmless for the beta-testing of the new one. I suppose. I can see it being useful to be able to demonstrate bugs in any version of a compiler, though. > As for checks for current bugs, I think it's our current convention that > they should be guarded by BOOST_STRICT_CONFIG, like this: > > #if defined(__BORLANDC__) \ > && (__BORLANDC__ <= 0x570 || !defined(BOOST_STRICT_CONFIG)) > # define BOOST_MPL_BROKEN_OVERLOAD_RESOLUTION > #endif > > so defining BOOST_STRICT_CONFIG would disable them. I'm not sure there's universal agreement about that, but now that Doug has fixed the function headers, the code says otherwise. > I am afraid it's not thoroughly enforced, though. If we come up with > a way to simplify the above, personally I would be more than happy. I propose: #ifndef BOOST_STRICT_CONFIG # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test) #else # define BOOST_WORKAROUND(symbol, test) 0 #endif Comments? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes: >> So do you feel you need an additional library feature? > > That's what I'm trying to find out. It seems like most of the > stuff is there already in MPL placeholders and binders. > >>>Plus your solution here doesn't bind T to a type. :) >> Are you just pointing out my error? > > Well...yeah. :) It wasn't meant as an attack. Wasn't taken that way. > I honestly was confused about what you presented. Understandably. > Your correction above makes everything clear to me now. So do you feel you need an additional library feature? ;-) >>>g++ 3.2. The MPL paper and docs don't say anything about >>>using placeholders or binders with classes that aren't >>>metafunctions. How would the binders know what to typedef >>>as apply::type? >> I don't know... well, it could detect whether there was a ::type >> member, and if it were not present, it could just give you the outer >> class. I think that's a bit of a hack, though. > > Agreed. Urk...I'm not sure how to get around this problem without > requiring template template parameters (beyond what's used for > placeholders currently). There's no way. So what? Your compiler supports them. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Generators
> -Original Message-
> From: David B. Held [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 05, 2002 10:56 AM
> To: [EMAIL PROTECTED]
> Subject: [boost] Re: [MPL] Making Generators
>
>
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > [...]
> > I don't know... well, it could detect whether there was a ::type
> > member, [...]
>
> Really??? Is it possible to detect the presence of a typedef
> without generating an error? How do you do this? I think
> this is a very useful feature!
>
> Dave
Vandevoorde and Josuttis call it SFINAE, "substitution failute is not an
error."
In "C++ Templates: The Complete Guide" (Recommended), they give this
example on pages 106-107:
typedef char RT1;
typedef struct {char a[2];} RT2;
template RT1 test(typename T::X const*);
template RT2 test(...);
#define type_has_member_type_X(T) \
(sizeof(test(0) == 1)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Making Generators
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> I don't know... well, it could detect whether there was a ::type >> member, >> [...] > > Really??? Is it possible to detect the presence of a typedef without > generating an error? How do you do this? I think this is a very useful > feature! On many compilers, yes. See mpl/aux_/has_xxx.hpp -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
David Abrahams wrote: > I'm trying to come up with instructions for compiler vendors who want > to use Boost to test their compilers. What preprocessor symbols do > they need to define? So far, it looks like: > > - BOOST_NO_COMPILER_CONFIG > - BOOST_NO_STDLIB_CONFIG - if they want to check the library > - BOOST_STRICT_CONFIG - to disable some checks in > source code > - macros for any known-not-implemented features, >e.g. BOOST_NO_TEMPLATE_TEMPLATES. > > Right? As far as I understand, defining BOOST_STRICT_CONFIG only should be sufficient (for compiler tests) - given that the compiler being tested has a bumped up version number. > > 2. What about all the places we make compiler-specific checks in >Boost code? Could we define some macros which make it easier >and less error-prone to write these, and which can be globally >turned off when needed? > > # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) > ... > #else > ... > #endif > The checks for the past versions of the compiler, e.g. #if defined(BOOST_MSVC) && BOOST_MSVC <= 1300 # define BOOST_MPL_MSVC_ETI_BUG #endif are harmless for the beta-testing of the new one. As for checks for current bugs, I think it's our current convention that they should be guarded by BOOST_STRICT_CONFIG, like this: #if defined(__BORLANDC__) \ && (__BORLANDC__ <= 0x570 || !defined(BOOST_STRICT_CONFIG)) # define BOOST_MPL_BROKEN_OVERLOAD_RESOLUTION #endif so defining BOOST_STRICT_CONFIG would disable them. I am afraid it's not thoroughly enforced, though. If we come up with a way to simplify the above, personally I would be more than happy. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote:
template
struct my_type_generator
{
typedef my_type type;
};
lambda does it
Oops, I meant
lambda >
of course!
Ok, that makes more sense now. :)
, unless of course your compiler
needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of a
savings, though.
Not for one class, no, but when we're talking several classes
with several binding requirements, I think there's a significant
savings to be had.
So do you feel you need an additional library feature?
That's what I'm trying to find out. It seems like most of the
stuff is there already in MPL placeholders and binders.
Plus your solution here doesn't bind T to a type. :)
Are you just pointing out my error?
Well...yeah. :) It wasn't meant as an attack. I honestly
was confused about what you presented. Your correction above
makes everything clear to me now.
g++ 3.2. The MPL paper and docs don't say anything about
using placeholders or binders with classes that aren't
metafunctions. How would the binders know what to typedef
as apply::type?
I don't know... well, it could detect whether there was a ::type
member, and if it were not present, it could just give you the outer
class. I think that's a bit of a hack, though.
Agreed. Urk...I'm not sure how to get around this problem without
requiring template template parameters (beyond what's used for
placeholders currently).
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [MPL] Making Generators
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > I don't know... well, it could detect whether there was a ::type > member, > [...] Really??? Is it possible to detect the presence of a typedef without generating an error? How do you do this? I think this is a very useful feature! Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes:
>
>> template
>> struct my_type_generator
>> {
>> typedef my_type type;
>> };
>> lambda does it
Oops, I meant
lambda >
of course!
> , unless of course your compiler
>> needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of a
>> savings, though.
>
> Not for one class, no, but when we're talking several classes
> with several binding requirements, I think there's a significant
> savings to be had.
So do you feel you need an additional library feature?
> Plus your solution here doesn't bind T to a type. :)
Are you just pointing out my error?
>>>I thought lambda might do the trick, but apparently not:
>>>
>>>typedef my_type my_type_generator;
>>>
>>>(This will be passed to an MPL algorithm so I didn't
>>>bother with lambda<>).
>>>
>>>This causes a static assertion in mpl::arg<2> where it
>>>sees a void type for V (I think).
>>>
>>>Is the problem that my_type doesn't contain a ::type
>>> member?
>> Maybe. What compiler are you using?
>
> g++ 3.2. The MPL paper and docs don't say anything about
> using placeholders or binders with classes that aren't
> metafunctions. How would the binders know what to typedef
> as apply::type?
I don't know... well, it could detect whether there was a ::type
member, and if it were not present, it could just give you the outer
class. I think that's a bit of a hack, though.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
> [mailto:[EMAIL PROTECTED]]On Behalf Of David A. Greene > Sent: 05 December 2002 16:56 > > > Is the problem that my_type doesn't contain a ::type > member? my_type is not a metafunction so maybe it just > can't be used conveniently with mpl. IIRC mpl::lambda does need metafunctions to work on. I don't know if that is the cause of yopur problem though. /ikh ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote:
template
struct my_type_generator {
template
struct apply {
typedef my_type type;
};
};
Looks good to me.
Is there a convenient way to create this with MPL?
You want it to be more convenient than that?!
Perhaps "convenient" is the wrong word. There are several places
I need to do this sort of thing and writing custom binders for
each class (or generic generators with varying number of
template template aritys) is tedious. Different argument
positions must be bound for each of these generators, so
that adds to the scalability problem of custom classes.
Sometimes I want to bind different arguments to the same
class. MPL binders seems the way to go.
template
struct my_type_generator
{
typedef my_type type;
};
lambda does it, unless of course your compiler
needs BOOST_MPL_AUX_LAMDA_SUPPORT.
I don't think it's much of a savings, though.
Not for one class, no, but when we're talking several classes
with several binding requirements, I think there's a significant
savings to be had.
Plus your solution here doesn't bind T to a type. :)
I thought lambda might do the trick, but apparently not:
typedef my_type my_type_generator;
(This will be passed to an MPL algorithm so I didn't
bother with lambda<>).
This causes a static assertion in mpl::arg<2> where it
sees a void type for V (I think).
Is the problem that my_type doesn't contain a ::type
member?
Maybe. What compiler are you using?
g++ 3.2. The MPL paper and docs don't say anything about
using placeholders or binders with classes that aren't
metafunctions. How would the binders know what to typedef
as apply::type?
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes:
> [Posted to boost because MPL is not yet released. At what
> point should these questions go to boost-users?]
>
> Say I have a type my_type:
>
> template
> struct my_type { ... }
>
> Now let's say I want to create a generator that
> binds T to some type but leaves U and V free to
> be filled in later. Basically, I want something
> like this:
>
> template
> struct my_type_generator {
> template
> struct apply {
>typedef my_type type;
> };
> };
Looks good to me.
> Is there a convenient way to create this with MPL?
You want it to be more convenient than that?!
template
struct my_type_generator
{
typedef my_type type;
};
lambda does it, unless of course your compiler
needs BOOST_MPL_AUX_LAMDA_SUPPORT.
I don't think it's much of a savings, though.
> I thought lambda might do the trick, but apparently not:
>
> typedef my_type my_type_generator;
>
> (This will be passed to an MPL algorithm so I didn't
> bother with lambda<>).
>
> This causes a static assertion in mpl::arg<2> where it
> sees a void type for V (I think).
>
> Is the problem that my_type doesn't contain a ::type
> member?
Maybe. What compiler are you using?
> my_type is not a metafunction so maybe it just can't be used
> conveniently with mpl. It's easy enough to manually define
> my_type_generator, but I think this is a pretty common pattern and
> it might be useful as a library component.
H...
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Anthony Williams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Eric Woodruff writes: > > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Thus, given that h.storage is properly aligned, (which is the purpose of > > the > > > other union member), after "new(h.storage) Foo", h.storage contains a Foo > > > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the > > > dynamic type of the object. > > > > > > > This is precisely my reasoning why reinterpret_cast<> is _not_ > > implementation defined. > > > > It must be the case that it is equal to the situation of having > > > > Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object. > > Nowhere do I see a requirement that supports your deductions. Indeed there are > very few requirements on reinterpret_cast<>, other than the fact that what it > does must be defined by the implementation. For pointers to objects, these > amount to: > > * T1* can be converted to T2* and back again unchanged (unless T2 has stricter > alignment requirements). Precisely, T1 is Foo in this case as you have already pointed out. This is simply the identity conversion T1 -> T2 -> T1, which is pretty much the only thing reinterpret_cast can do portably. > > * You can convert a pointer to the first member of a POD struct to a pointer > to the struct, and vice-versa. > > * A Null pointer of any type can be cast to a null pointer of any other type. > > Anthony > -- > Anthony Williams > Senior Software Engineer, Beran Instruments Ltd. > Remove NOSPAM when replying, for timely response. > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] Making Generators
[Posted to boost because MPL is not yet released. At what
point should these questions go to boost-users?]
Say I have a type my_type:
template
struct my_type { ... }
Now let's say I want to create a generator that
binds T to some type but leaves U and V free to
be filled in later. Basically, I want something
like this:
template
struct my_type_generator {
template
struct apply {
typedef my_type type;
};
};
Is there a convenient way to create this with MPL? I
thought lambda might do the trick, but apparently not:
typedef my_type my_type_generator;
(This will be passed to an MPL algorithm so I didn't
bother with lambda<>).
This causes a static assertion in mpl::arg<2> where it
sees a void type for V (I think).
Is the problem that my_type doesn't contain a ::type
member? my_type is not a metafunction so maybe it just
can't be used conveniently with mpl. It's easy enough
to manually define my_type_generator, but I think this
is a pretty common pattern and it might be useful as a
library component.
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
Eric Woodruff writes: > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Thus, given that h.storage is properly aligned, (which is the purpose of > the > > other union member), after "new(h.storage) Foo", h.storage contains a Foo > > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the > > dynamic type of the object. > > > > This is precisely my reasoning why reinterpret_cast<> is _not_ > implementation defined. > > It must be the case that it is equal to the situation of having > > Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object. Nowhere do I see a requirement that supports your deductions. Indeed there are very few requirements on reinterpret_cast<>, other than the fact that what it does must be defined by the implementation. For pointers to objects, these amount to: * T1* can be converted to T2* and back again unchanged (unless T2 has stricter alignment requirements). * You can convert a pointer to the first member of a POD struct to a pointer to the struct, and vice-versa. * A Null pointer of any type can be cast to a null pointer of any other type. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
(inline) "Anthony Williams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [snip] > Gabriel Dos Reis writes: > unsigned char* has _additional_ properties to void* --- you can access the > object representation of _any_ object through an unsigned char* (and for PODs, > you can copy them around using this) > > 3.9p4: > "The object representation of an object of type T is the sequence of N > unsigned char objects taken up by the object of type T, where N equals > sizeof(T)." > > 3.10p15: > "If a program attempts to access the stored value of an object through an > lvalue of other than one of the following types the behavior is undefined: > > - the dynamic type of the object, > > ... > > - a char or unsigned char type." > [snip] > Thus, given that h.storage is properly aligned, (which is the purpose of the > other union member), after "new(h.storage) Foo", h.storage contains a Foo > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the > dynamic type of the object. > This is precisely my reasoning why reinterpret_cast<> is _not_ implementation defined. It must be the case that it is equal to the situation of having Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object. [snip] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
Douglas Gregor <[EMAIL PROTECTED]> writes: > I like BOOST_COMPILER_WORKAROUND. We should use it and ban explicit references > to compiler/platform/library version macros outside of the config library > that don't use it. I'm convinced ;-) I think we should probably just call it BOOST_WORKAROUND, though: we might need to check library versions, too. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
On Wednesday 04 December 2002 03:27 pm, David Abrahams wrote: > 1. Should we do something to make this easier for them? Yeah, let's add a macro BOOST_HOLY_GRAIL to skip all workarounds :) > 2. What about all the places we make compiler-specific checks in >Boost code? Could we define some macros which make it easier >and less error-prone to write these, and which can be globally >turned off when needed? > > # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) > ... > #else > ... > #endif > > Thoughts? I like BOOST_COMPILER_WORKAROUND. We should use it and ban explicit references to compiler/platform/library version macros outside of the config library that don't use it. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
"John Maddock" <[EMAIL PROTECTED]> writes: >> I'm trying to come up with instructions for compiler vendors who want >> to use Boost to test their compilers. What preprocessor symbols do >> they need to define? So far, it looks like: >> >> - BOOST_NO_COMPILER_CONFIG >> - BOOST_NO_STDLIB_CONFIG - if they want to check the library >> - BOOST_STRICT_CONFIG - to disable some checks in source code >> - macros for any known-not-implemented features, >>e.g. BOOST_NO_TEMPLATE_TEMPLATES. >> >> Right? > > Not quite: > > BOOST_NO_CONFIG : turns off all checking for defects, Well, sure. But if they're just trying to check the core compiler and NOT the library, I don't think they want BOOST_NO_CONFIG, do they? And since that also turns of platform workarounds, it could get them into trouble with platform bugs over which they have no control, couldn't it? > IMO compiler specific fixes should be turned off by this as well (in > many cases this is all you need - certainly this is what I used for > testing a certain recent alpha compiler release...) Well, in my code I've been using BOOST_STRICT_CONFIG to turn off version-specific fixes. So we have a problem. > Then define: any macros that define features: BOOST_HAS_LONG_LONG > etc. Right, I guess that will tend to test more of the compiler. > Then define any defect macros you want to temporarily enable until the > compiler is fixed :-) OK. >> Questions: >> >> 1. Should we do something to make this easier for them? >> >> 2. What about all the places we make compiler-specific checks in >>Boost code? Could we define some macros which make it easier >>and less error-prone to write these, and which can be globally >>turned off when needed? >> >> # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) >> ... >> #else >> ... >> #endif >> >> Thoughts? > > That's not a bad idea IMO. #1 or #2? > Compiler vendors aren't necessarily typical boost users though :-) No, it's true. In some ways they're dumber. It seems as though the ability of compiler vendors to get the tests running properly if you don't hold their hand every step of the way is pretty low. That aside, I think if we don't use something like BOOST_COMPILER_WORKAROUND, we're bound to continue to have problems like deciding whether to check BOOST_STRICT_CONFIG or BOOST_NO_CONFIG. Not to mention the fact that simply writing these sorts of checks is error-prone and makes the code hard-to-read: #if defined(__SUNPRO_CC) && __SUNPRO_CC <= 0x540 && !defined(BOOST_NO_CONFIG) // workaround here #else ... #endif -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_CONFIG
On Thursday 05 December 2002 08:51 am, David Abrahams wrote: > Douglas Gregor <[EMAIL PROTECTED]> writes: > > F> On Wednesday 04 December 2002 08:53 am, David Abrahams wrote: > >> It looks like some people (ahem! >> BOOST_NO_CONFIG where they should be using BOOST_STRICT_CONFIG. See > >> boost/function/function_base.hpp. > > > > Oops. Fixed now. > > Well, now John Maddock may be quarrelling with you over the correct > approach. We need to decide how this will work. > > -Dave It seems like places that need BOOST_(STRICT|NO)_CONFIG in the source don't fit the documentation for either macro. BOOST_STRICT_CONFIG just tells the config system how pessimistic to be w.r.t. new compiler versions. BOOST_NO_CONFIG tells the config system not to include any of its configuration headers (i.e., don't define any defect/extension macros). As it stands now, I think the right way to write compiler/library/platform-dependent workarounds is to check for _both_ BOOST_STRICT_CONFIG and BOOST_NO_CONFIG. BOOST_STRICT_CONFIG disables the workaround when dealing with a new compiler version, whereas BOOST_NO_CONFIG disables the workaround when the user has asked not to configure for the compiler. Maybe BOOST_NO_CONFIG (actually, BOOST_NO_COMPILER_CONFIG) should define BOOST_STRICT_CONFIG? Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_CONFIG
Douglas Gregor <[EMAIL PROTECTED]> writes: F> On Wednesday 04 December 2002 08:53 am, David Abrahams wrote: >> It looks like some people (ahem! > BOOST_NO_CONFIG where they should be using BOOST_STRICT_CONFIG. See >> boost/function/function_base.hpp. > > Oops. Fixed now. Well, now John Maddock may be quarrelling with you over the correct approach. We need to decide how this will work. -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] dangerous_cast<>
Gabriel Dos Reis writes: > Anthony Williams <[EMAIL PROTECTED]> writes: > > | > Anthony Williams <[EMAIL PROTECTED]> writes: > | > > | > [...] > | > > | > | 3.10p15: > | > | "If a program attempts to access the stored value of an object through an > | > | lvalue of other than one of the following types the behavior is undefined: > | > | > | > | - the dynamic type of the object, > | > | > | > | ... > | > | > | > | - a char or unsigned char type." > | > | > | > | So given a Foo object foo, static_cast(static_cast(&foo)) is > | > | legal, and can be used to access the object representation of the object. > | > > | > There is no question that the above cast is legal. I thin the issue > | > is elsewhere. The key question is whether that may be different from > | > > | >reinterpret_cast(&foo); > | > | I thought the issue was whether the pair of static_cast<>s in dangerous_cast<> > | was as implementation defined as a reintepret_cast<> would be. If you read my > | mail to the end, hopefully I have explained that I think that the > | static_cast<> pair is legal and well-defined, as opposed to using > | reinterpret_cast, which is implementation-defined. If I haven't made myself > | clear, I apologise, and will try again. > > You made youself clear. > > However, there are two running issues originating from a claim of Dave > that dangerous_cast<> might be better than reinterpret_cast<> in > casting from U* to T* (dangerous_cast<> uses the intermediate step > void* via static_cast<>). > > 1) is dangerous_cast<> better than reinterpret_cast<>? > > 2) is it well-defined to dereference the value obtained from > >U* -> void* -> T* > > ? > > You've showed that si U == char, (the case in Dave's example) then it > is well-formed. The other cases are left undefined. > > So the key question (1) is still unanswered. Well, given that we have a valid use when U==(unsigned) char, I think it is certainly better than reinterpret_cast<> in that case. However, for (2), it is only safe to dereference the resulting pointer if there is a T at the location that the final T* points to. This is true irrespective of what U is. However, there are very few cases in which you are guaranteed to be able to get a valid U* that holds a valid T* --- given that U and T may have different alignment requirements, and an implementation is permitted to drop any unnecessary info from pointers, so T* and U* may only store addresses which are valid multiples of the alignment for T and U respectively, so it is unlikely that you would get a valid case, unless there was special dispensation. One of these is U==char or void, as I showed. Another case to consider is when U is a POD-struct and T is the type of the first data member (or vice-versa). In this case, reinterpret_cast<> is guaranteed to work (9.2p17), so what about dangerous_cast<>? IMO, there is no guarantee, though I would be surprised if it didn't work. Indeed, I read the note on that paragraph to indicate that the intent is that the address is the same, and thus static_cast will yield the same result. However, I can't find any normative guarantee. A third case to consider is when T and U are the types of members of the same union. In this case, reinterpret_cast<> to a pointer to the union type and back is guaranteed (since the members are to be allocated as if they were the only member of a struct), and I would be surprised if it didn't work, but I can't find a normative guarantee. If these last two cases are guaranteed to be OK, then I think we have sufficient to indicate that dangerous_cast<> can be useful. If not, then it ought to be renamed, and only defined for char types. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] dangerous_cast<>
Anthony Williams <[EMAIL PROTECTED]> writes: | > Anthony Williams <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | 3.10p15: | > | "If a program attempts to access the stored value of an object through an | > | lvalue of other than one of the following types the behavior is undefined: | > | | > | - the dynamic type of the object, | > | | > | ... | > | | > | - a char or unsigned char type." | > | | > | So given a Foo object foo, static_cast(static_cast(&foo)) is | > | legal, and can be used to access the object representation of the object. | > | > There is no question that the above cast is legal. I thin the issue | > is elsewhere. The key question is whether that may be different from | > | >reinterpret_cast(&foo); | | I thought the issue was whether the pair of static_cast<>s in dangerous_cast<> | was as implementation defined as a reintepret_cast<> would be. If you read my | mail to the end, hopefully I have explained that I think that the | static_cast<> pair is legal and well-defined, as opposed to using | reinterpret_cast, which is implementation-defined. If I haven't made myself | clear, I apologise, and will try again. You made youself clear. However, there are two running issues originating from a claim of Dave that dangerous_cast<> might be better than reinterpret_cast<> in casting from U* to T* (dangerous_cast<> uses the intermediate step void* via static_cast<>). 1) is dangerous_cast<> better than reinterpret_cast<>? 2) is it well-defined to dereference the value obtained from U* -> void* -> T* ? You've showed that si U == char, (the case in Dave's example) then it is well-formed. The other cases are left undefined. So the key question (1) is still unanswered. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Static lookup
"Rozental, Gennadiy" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > If anyone interested I have more generic solution, that
> > includes both
[...snip...]
> namespace mapping {
> template
> class fixed_sized;
>
> // constructed by Key1,Value1,Key2,Value2 ... list plus "invalid value"
>
> template
> class dynamic;
>
> // constrcted by "invalid_value"
>
"invalid_value" ... is what / defined how?
> };
>
> mapping::fixed_sized test_mapping1(
> "Key1", 1,
> "Key2", 2,
> "QWE", 3,
> 0
> );
>
> mapping::dyanamic test_mapping2(
> "Key1", 1,
> "Key2", 2,
> "QWE", 3,
> 0
> );
What would the actual signature of the constructor be in this case?
>
> mapping::dynamic test_mapping3( 0 );
> test_mapping3.add( "Key1", 1 );
> test_mapping3.add( "Key2", 2 );
> test_mapping3.add( "QWE" , 3 );
>
> Usage:
> test_mapping1["Key1"]
> test_mapping2["Key2"]
> test_mapping3["QWE"]
>
And reverse lookup? Does it require another template instantiation with the
first two parameters defined in reverse order, or is it included through
operator [] overloading, or ...?
// Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_CONFIG
On Wednesday 04 December 2002 08:53 am, David Abrahams wrote: > It looks like some people (ahem! BOOST_NO_CONFIG where they should be using BOOST_STRICT_CONFIG. See > boost/function/function_base.hpp. Oops. Fixed now. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] dangerous_cast<>
Gabriel Dos Reis writes: > Hi, Hi > Anthony Williams <[EMAIL PROTECTED]> writes: > > [...] > > | 3.10p15: > | "If a program attempts to access the stored value of an object through an > | lvalue of other than one of the following types the behavior is undefined: > | > | - the dynamic type of the object, > | > | ... > | > | - a char or unsigned char type." > | > | So given a Foo object foo, static_cast(static_cast(&foo)) is > | legal, and can be used to access the object representation of the object. > > There is no question that the above cast is legal. I thin the issue > is elsewhere. The key question is whether that may be different from > >reinterpret_cast(&foo); I thought the issue was whether the pair of static_cast<>s in dangerous_cast<> was as implementation defined as a reintepret_cast<> would be. If you read my mail to the end, hopefully I have explained that I think that the static_cast<> pair is legal and well-defined, as opposed to using reinterpret_cast, which is implementation-defined. If I haven't made myself clear, I apologise, and will try again. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
> I'm trying to come up with instructions for compiler vendors who want > to use Boost to test their compilers. What preprocessor symbols do > they need to define? So far, it looks like: > > - BOOST_NO_COMPILER_CONFIG > - BOOST_NO_STDLIB_CONFIG - if they want to check the library > - BOOST_STRICT_CONFIG - to disable some checks in source code > - macros for any known-not-implemented features, >e.g. BOOST_NO_TEMPLATE_TEMPLATES. > > Right? Not quite: BOOST_NO_CONFIG : turns off all checking for defects, IMO compiler specific fixes should be turned off by this as well (in many cases this is all you need - certainly this is what I used for testing a certain recent alpha compiler release...) Then define: any macros that define features: BOOST_HAS_LONG_LONG etc. Then define any defect macros you want to temporarily enable until the compiler is fixed :-) > Questions: > > 1. Should we do something to make this easier for them? > > 2. What about all the places we make compiler-specific checks in >Boost code? Could we define some macros which make it easier >and less error-prone to write these, and which can be globally >turned off when needed? > > # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) > ... > #else > ... > #endif > > Thoughts? That's not a bad idea IMO. Compiler vendors aren't necessarily typical boost users though :-) John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Lambda and Borland C++
Joel de Guzman wrote: BTW, Vladimir Prus, if you are there, this version generates optimal code on Borland. All the boost::tuples tests except the cons are working just fine. And did I mention that there is just a single implementation (no special case for VC6/7). And hey, it can do a 50 element make_tuple! That's terrific! I could have hoped for some improvement, but not for optimal code. The only bad thing that that I don't use Borland any more... except for Boost.Build-related tasks. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] dangerous_cast<>
Hi, Anthony Williams <[EMAIL PROTECTED]> writes: [...] | 3.10p15: | "If a program attempts to access the stored value of an object through an | lvalue of other than one of the following types the behavior is undefined: | | - the dynamic type of the object, | | ... | | - a char or unsigned char type." | | So given a Foo object foo, static_cast(static_cast(&foo)) is | legal, and can be used to access the object representation of the object. There is no question that the above cast is legal. I thin the issue is elsewhere. The key question is whether that may be different from reinterpret_cast(&foo); -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] dangerous_cast<>
Gabriel Dos Reis writes: > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > | From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> > | > David Abrahams <[EMAIL PROTECTED]> writes: > | > > | > | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | > | > | > | > Hmm, I have a couple of questions answers to which will help me > | > | > get your point. > | > | > > | > | > 1) Why can't you do that with reinterpret_cast? > | > | > | > | You can, but the results are non-portable > | > > | > No more non-portable than with dangerous_cast<>. > | > | I think that Dave's point is that in > | > | new(h.storage) Foo; > | > | there is a char* -> void* implicit conversion as placement new takes a > | void*. So the placement new performs char* -> void* -> Foo* (by constructing > | a Foo at (void*)h.storage), which - in theory - might not be the same as > | char* -> Foo*. > > But then, that theoretical implementation can remember the type from > which the conversion to void* was made and may issue an error when an > attempt is made to dereference the pointer obtained by recasting the > result of static_cast(h.storage) to Foo*. > > Practical notes: > Historically, char* was used as the type of "raw memory" until "void*" > was invented. And since then char* and void* continues to have the > same properties as raw-memory issues are concerned. unsigned char* has _additional_ properties to void* --- you can access the object representation of _any_ object through an unsigned char* (and for PODs, you can copy them around using this) 3.9p4: "The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T)." 3.10p15: "If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined: - the dynamic type of the object, ... - a char or unsigned char type." So given a Foo object foo, static_cast(static_cast(&foo)) is legal, and can be used to access the object representation of the object. Also, 3.9.2p4 says: "Objects of cvqualified (3.9.3) or cvunqualified type void* (pointer to void), can be used to point to objects of unknown type. A void* shall be able to hold any object pointer. A cvqualified or cvunqualified (3.9.3) void* shall have the same representation and alignment requirements as a cvqualified or cvunqualified char*." So casting a void* to/from a char* is a no-op. 3.8p1: "The lifetime of an object is a runtime property of the object. The lifetime of an object of type T begins when: - storage with the proper alignment and size for type T is obtained, and - if T is a class type with a nontrivial constructor (12.1), the constructor call has completed." Thus, given that h.storage is properly aligned, (which is the purpose of the other union member), after "new(h.storage) Foo", h.storage contains a Foo object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the dynamic type of the object. The question is: is the Foo* returned by the placement new expression (which is usable) the same as the Foo* returned from static_cast(static_cast(h.storage))? The object representation of the Foo object is the sizeof(T) bytes starting at static_cast(h.storage) (since that is what was passed to placement new), so static_cast(pfoo)==static_cast(h.storage) if pfoo is the value returned from the new expression. Thus static_cast(static_cast(pfoo)) ==static_cast(static_cast(h.storage)) ==pfoo and we're legal. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Call for Volunteers [license review]
Glen Knowles writes: > From: Anthony Williams [mailto:[EMAIL PROTECTED]] > >The SleepyCat license is convered here: > > As a paying licensee of SleepyCat I can atest that it is more unsuitable > then you indicated. The "free" license requires that all the source code of > your program that uses BerkeleyDB be made available. That is what I meant. Your mods make it clearer. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
