[boost] Re: 1.31.0 release schedule
Anthony Williams wrote: Will the variant library be part of 1.31.0? Apparently so: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/index.htm Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
E. Gladyshev wrote: IMO, if boost is to become a C++ standard, we'd have to resolve this conflict. Well it is already somewhat standard, since a part of it has been accepted for the library TR (including the smart pointers). See: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/library_technical_report.html Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in FC++?
Brian McNamara wrote: Non-reusable: bind, mem_fn, compose, function, functional, lambda: (It looks like much of compose and functional is subsumed by bind/lambda anyway.) FC++ "indirect functoids" are similar to boost::function objects. fcpp::ptr_to_fun is similar to bind and mem_fn. fcpp::lambda is somewhat similar to boost::lambda. In each of these cases, however, none of the boost stuff can be reused in FC++, as FC++ uses/requires so-called "full functoids" to work. FC++ must necessarily duplicate these, owing to the fundamental differences in the library architecture. That's most unfortunate. Are you sure it's something that can't be worked out? There have been feature requests before. ;) - Naming conventions: FC++ uses a naming convention other than Boost's (including systematically using capital letters in identifiers). From what I have been able to tell in such a short time, the 'camel hump notation' is mostly used in the implementation and only slightely so in the interface. For example, things like Fun0, Fun0Impl, ... are no problem because you want to reuse Boost's facilities for these anyway. And the functiods are already 'properly' named in lowercase. Of course, there is some work to be done here, but I don't think it would be a big problem, do you? It's much more insidious than this. There are a number of types of names which use captial letters visible in the client interface to the FC++ library. Here are the major categories of examples that spring to mind: [snipped] I had noticed these, I had just not fully considered the implications. See below. While some of these names are ones that I have made up, and thus can be changed "on a whim" to lowercase versions, there are still two classes of naming issues which I hesitate to change: Haskell names. Many functoids (like enumFromTo, takeWhile, zipWith, etc.) and datatypes (like Maybe) have the exact same names and behavior as their counterparts in the Haskell programming language. I've named them this way to cater to programmers coming from a Haskell background, and am hesitant to change them. Understandable. Though I find the following more compelling. Functoid types. The obvious alternative to naming the type of a functoid with a leading capital letter (e.g. "compose" has type "Compose") is to add a suffix (e.g. make it so "compose" has type "compose_type"). Functoid type names are used a lot, though, and I am not fond of the idea of making the type names longer than the names of the instances. I see. I've been bitten by this in my personal code from time to time as well. My compromise has been to use the Boost naming convention for functions, variables, and members, and use 'camel hump notation' for types, exactly as you have done apparently. I dunno if either of the examples above constitutes reason enough to bend the rules with regards to naming conventions, but I want to ask. I'm not sure what the official Boost policy is, but the regex lib uses a considerable amount of 'camel hump notation' as well. Perhaps you won't have to change that many names after all. ;) Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in FC++?
Brian McNamara wrote: I would like to see if there is interest in incorporating the FC++ library into Boost. I've glanced over the papers a bit. It seems very, very interesting. See below though. So I am sending this mail to see: (1) If there is still interest in adding FC++ to Boost, and (2) If there is interest, what-all needs to be changed with the FC++ library to make it meet the standards of Boost. With regards to (1), I hope yes, but the Boost Lambda Library has a bit of conceptual overlap with FC++, so I can imagine this issue being potentially contentious. (FC++ and Lambda ostensibly provide much of the same kinds of functionality, but while there is overlap, each library does a lot of "its own thing" too. I (and Jaakko too, probably) can say more about this if necessary.) With regards to (2), I have been reading all the stuff on the Boost web site regarding submissions, and so I am aware of a number of issues, including: - Reuse: FC++ "reinvents" a number of Boost's libraries in its implementation, such as smart pointers and metaprogramming tricks. A Boost version of FC++ should reuse Boost libraries for this. I agree. While FC++ probably would bring in a lot of new stuff, there is *considerable* overlap with Boost's current libraries. On the function side there's: bind, mem_fn, compose, function, functional, and of course lambda. And then there are smart_ptr, mpl, and preprocessor. Reusing will probably make the implementation a lot cleaner, potentially more robust, and ... - Documentation: as of yet, there is no good singular "users guide" for FC++ aimed at the audience of C++ programmers; I'd need to write one. ... you won't have to re-document the things that Boost already provides. ;) - Naming conventions: FC++ uses a naming convention other than Boost's (including systematically using capital letters in identifiers). From what I have been able to tell in such a short time, the 'camel hump notation' is mostly used in the implementation and only slightely so in the interface. For example, things like Fun0, Fun0Impl, ... are no problem because you want to reuse Boost's facilities for these anyway. And the functiods are already 'properly' named in lowercase. Of course, there is some work to be done here, but I don't think it would be a big problem, do you? But at this point I'm probably already getting ahead of myself. So I'll stop talking and ask people to comment with regards to "interest" in FC++. I'd have to look deeper into it, for which I don't have the time at the moment because I'm right in the middle of my exams. But from what I've seen so far, it's pretty cool! Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Bidirectionnal map
Eric Martel wrote: [snip] Nearly 5 months later, did anyone work on this bimap? Will it be included anytime soon in an official distribution of boost? On a related issue: has anyone worked on boost::map? It was supposed to be a generalisation of bimap, being able to work with an arbitrary number of keys and values, if I recall correctly. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Gennaro Prota wrote: On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits <[EMAIL PROTECTED]> wrote: Perhaps I missed a part of the discussion, but what is wrong with Jaap's suggestion: #ifdef BOOST_STATIC_NDEBUG #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true ) #else #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B ) #endif ? Well, considering that what we want is just a no-op, which do you prefer? a) typedef ::boost::static_assert_test< sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( true ) >)> BOOST_JOIN(boost_static_assert_typedef_, __LINE__); (I've just picked up one of the implementations in static_assert.hpp, but the others don't differ too much.) b) typedef void boost_static_assert_typedef; The effect is the same. However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the (potential?) problems you are worrying about. So why do you prefer (b)? Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Gennaro Prota wrote: On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter" <[EMAIL PROTECTED]> wrote: #define BOOST_STATIC_ASSERT(c) \ typedef char boost_static_assert_typedef When using several asserts in the same context some compilers could complain about the duplicate typedef; if so pasting the expansion of __LINE__ shouldn't be that expensive either. That seems indeed the best solution to me (with the __LINE__ included) as most of the time is spend in calculations for the actual expression. In effect I would prefer the one without __LINE__. But if any compiler warns about duplicate typedefs than it's better having a single version, with __LINE__, than #ifs. Also I have a slight preference for using void instead of char, as suggested by Greg: typedef void boost_static_assert_typedef Perhaps I missed a part of the discussion, but what is wrong with Jaap's suggestion: #ifdef BOOST_STATIC_NDEBUG #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true ) #else #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B ) #endif ? But all this conjectures should be backed up by some measurement. Jaap? Agreed. I will do some measurements this week and report back in a few days. Nice :-) Indeed. :) Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Jaap Suter wrote: [snip] #ifdef BOOST_STATIC_NDEBUG #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true ) #else #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B ) #endif Yes much better. I don't see any problems with this, does anyone? Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Dirk Gerrits wrote: > Jaap Suter wrote: > >> Hi, >> >> In my own meta-programming I tend to use a lot of static_asserts and >> concept >> checks. However, these do have a negative impact on my compile-times. >> Take, >> for example, a meta-function that takes a type-list as its parameter. >> Assume >> a pre-condition is that the list may not be empty. What I can do is: >> >> BOOST_STATIC_ASSERT( (mpl::not_< typename mpl::empty< List >::type >> >>> ::type::value) ); >> >> >> >> And while this is a good thing most of the time, sometimes I would >> like to >> disable these checks so my compiles go faster. What is the recommended >> way >> of doing this? >> >> 1. Using a define: >> >> #ifndef UID_DO_CHECKS >> BOOST_STATIC_ASSERT( (mpl::not_< typename mpl::empty< List >::type >> >>> ::type::value) ); >> >> >> #endif >> >> 2. Using a boolean trait or policy, that is passed to a meta-if >> statement: >> >> BOOST_STATIC_ASSERT( ( >> mpl::apply_if< check_policy, >> mpl::not_< typename mpl::empty< List >::type >::type::value, >> true_ >::type::value )); >> >> 3. Other ideas? > > > I'd say something like: > > #ifdef STATIC_NDEBUG > #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e) > #else > #define BOOST_STATIC_ASSERT2(e) (void(e)) > #endif > > Analogous to . Argh, the if and else branches should be reversed of course. You've gotta love negative logic. ;) Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Jaap Suter wrote: Hi, In my own meta-programming I tend to use a lot of static_asserts and concept checks. However, these do have a negative impact on my compile-times. Take, for example, a meta-function that takes a type-list as its parameter. Assume a pre-condition is that the list may not be empty. What I can do is: BOOST_STATIC_ASSERT( (mpl::not_< typename mpl::empty< List >::type ::type::value) ); And while this is a good thing most of the time, sometimes I would like to disable these checks so my compiles go faster. What is the recommended way of doing this? 1. Using a define: #ifndef UID_DO_CHECKS BOOST_STATIC_ASSERT( (mpl::not_< typename mpl::empty< List >::type ::type::value) ); #endif 2. Using a boolean trait or policy, that is passed to a meta-if statement: BOOST_STATIC_ASSERT( ( mpl::apply_if< check_policy, mpl::not_< typename mpl::empty< List >::type >::type::value, true_ >::type::value )); 3. Other ideas? I'd say something like: #ifdef STATIC_NDEBUG #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e) #else #define BOOST_STATIC_ASSERT2(e) (void(e)) #endif Analogous to . Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: strings as template parameters?
Robert Klarer wrote: There was some discussion among the extensions subgroup of the C++ standard committee about the question of how the language might be extended to allow string literals to be used as template arguments. That discussion was inconclusive. It seems to me that the root of the problem is that C-style strings, and hence string literals, are not first-class builtin types in C++. I've been experimenting with one possible solution to that problem: I've (partially) implemented a "static_string" library and uploaded it to the 'Files' section of Boost's Yahoo Group. Here is the abstract from the (also partial) introductory document: "The static_string C++ library is an alternative to both string literals and the standard C++ type const std::basic_string. Any operation that can be performed upon a const std::basic_string object at runtime can be performed by the static_string library. Furthermore, the static_string library implements a number of metafunctions that allow these operations to be performed at program compile time. The static_string library is significantly more efficient in its use of both time and space than const std::basic_string." The static_string library allows strings to be represented by types, so that they can be used as template arguments. The syntax for using static_string is awkward, but a language extension that would make a library like static_string convenient to use might be worth considering as an alternative to the wholesale introduction of string-literals-as-template-arguments to the core language. A woefully incomplete version of the static_string library can be found at: http://groups.yahoo.com/group/boost/files/static_string.zip I guess it's not possible to generate the character sequence out of a string literal with the Boost Preprocessor library? That'd make this a whole lot more convenient to use. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: container algorithms almost complete
Dirk Gerrits wrote: Thorsten Ottosen wrote: I see your point. Does anyone have a nice idea of how to detect when the template argument is an iterator? It's easy with pairs and arrays and the default case is containers. Perhaps you can use Boost's concept check to see if the template argument models the Input Iterator concept? That's the first thing that came to mind, I haven't tried it out or anything. On second thought, that won't work. Concept check causes a compilation error when the argument does not conform to the concept. Perhaps you can do it the other way around? Check for a T::begin member function to see if the type is a container, and assume the type is an iterator in the default case? I'm not sure what that check would look like though. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: container algorithms almost complete
Thorsten Ottosen wrote: I see your point. Does anyone have a nice idea of how to detect when the template argument is an iterator? It's easy with pairs and arrays and the default case is containers. Perhaps you can use Boost's concept check to see if the template argument models the Input Iterator concept? That's the first thing that came to mind, I haven't tried it out or anything. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: strings as template parameters?
Jason House wrote: I'm thinking that it would be nice to be able to us define distinct types based on strings (the fundamental type const char * and not std::string). The intended use is in templates. Well I'm just curious how you would like to accomplish this. String literals as template parameters don't really work all that well, if I recall correctly. Then again, I might be wrong. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to convert a template parameter into a string
Robert Allan Schwartz wrote:
Perhaps my spelling class template could be folded into type_traits?
[code snipped]
Looks interesting, but I'm not sure if it's such a huge advantage over:
template
void foo(T)
{
cout << "T is " << typeid(T).name() << endl;
}
The resulting string of your method is more portable of course, but is
that the only reason?
No. There are other reasons why typeid() is not as "good" as my proposal:
1) You must #include in order to use typeid(). This seems to me
to be unnecessary overhead.
But wouldn't your method need an #include "spelling.hpp"?
2) The following program:
class base { };
class derived : public base { };
int main(void)
{
base * b = new derived;
base const * const b2 = new derived;
foo(b);
foo(*b);
foo(b2);
foo(*b2);
return 0;
}
produces:
T is P4base
T is 4base
T is PC4base
T is 4base
when compiled by g++ and executed in cygwin.
>
As you point out, the string returned by typeid().name() is not specified by
the Standard, so it is not portable, but in this case, it is extremely
difficult to decipher.
Ouch. That looks horrible indeed.
I believe a "standardized" (within Boost), portable, and *readable* text
representation of T makes my proposal better than typeid().
At what cost? The strings you generate are indeed very readable, but
specializing spelling for every type that might be a template parameter
someday seems like too much of a burden to me.
Others might disagree though...
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to convert a template parameter into a string
Robert Allan Schwartz wrote:
The attached document was submitted for publication to C/C++ Users Journal
today, but I thought it might be worth submitting to Boost as well.
Perhaps my spelling class template could be folded into type_traits?
[code snipped]
Looks interesting, but I'm not sure if it's such a huge advantage over:
template
void foo(T)
{
cout << "T is " << typeid(T).name() << endl;
}
The resulting string of your method is more portable of course, but is
that the only reason?
Regards,
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: intrusive tagging allows omision of unneeded headers
Thorsten Ottosen wrote:
- Original Message -
From: "Dirk Gerrits" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 6:15 PM
Subject: [boost] Re: intrusive tagging allows omision of unneeded headers
Thorsten Ottosen wrote:
[snip]
class X
{
public:
class tag {};
typedef tag X_tag;
^
};
class bar
{
public:
class tag {};
typedef tag bar_tag;
^^^
};
Why these typedefs? Why would one write X::X_tag instead of X::tag for
example?
how can we specifiy that we want to specialize for a particular class
otherwise? Only by establising a convetion
that all (involved) classes have a unique typedef can we destinguish the
classes. For example
template< typename C >
void foo_impl( const C& c, typename C::bar_tag )
{
cout << "bar specialised version" << endl;
}
will only be a candidate when C actually has a typedef bar_tag. due to
SFINAE the instantiation is allowed
to fail for classes that does not have a bar_tag typdef. And because the
above foo_impl is more specialized
than
template< typename C, typename Tag >
void foo_impl( const C& c, Tag t )
{
cout << "default version" << endl;
}
the first foo_impl will be chosen as a better match.
Ahh, I guess I didn't fully understand everything that was going on.
This makes sense. Thanks!
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: notation question
Dirk Gerrits wrote:
Vladimir Prus wrote:
David Abrahams wrote:
Vladimir Prus <[EMAIL PROTECTED]> writes:
I'd prefer the latter variant, so that non-broken platforms use more
natural
syntax. Another question is whether we could use only the second
version.
Theoretically, if you call the second version on const string, then
InputT
should be deduced as "const string". You can then write a simple
wrapper to
select const_iterator or iterator.
The only problem is, IIRC, borland drops "const" on template arguments
sometimes, and that's not possible to fix. Also, the "simple wrapper"
requires partial specialization. So, I'm not sure this approach is
viable, either.
There are mostly-transparent solutions. Something like:
// find_first sequence const version
template< typename InputT, typename SearchT >
inline iterator_range< typename InputT::const_iterator >
find_first_impl( const InputT& Input, const SearchT& Search, 0 )
{
...
}
I'm guessing the last parameter should be "int"?
Shouldn't it be long? I think I saw overload pairs in some Boost header
(from Boost Python I believe) where one overload had a dummy int
parameter and one overload had a dummy long parameter.
I assumed it was to workaround the partial ordering bug but I'm not 100%
sure. But Dave's upcoming reply should clarify things. ;)
David Abrahams wrote:
> No, sorry. It should be "..."
Ahh, OK.
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: notation question
Vladimir Prus wrote:
David Abrahams wrote:
Vladimir Prus <[EMAIL PROTECTED]> writes:
I'd prefer the latter variant, so that non-broken platforms use more
natural
syntax. Another question is whether we could use only the second
version.
Theoretically, if you call the second version on const string, then
InputT
should be deduced as "const string". You can then write a simple
wrapper to
select const_iterator or iterator.
The only problem is, IIRC, borland drops "const" on template arguments
sometimes, and that's not possible to fix. Also, the "simple wrapper"
requires partial specialization. So, I'm not sure this approach is
viable, either.
There are mostly-transparent solutions. Something like:
// find_first sequence const version
template< typename InputT, typename SearchT >
inline iterator_range< typename InputT::const_iterator >
find_first_impl( const InputT& Input, const SearchT& Search, 0 )
{
...
}
I'm guessing the last parameter should be "int"?
Shouldn't it be long? I think I saw overload pairs in some Boost header
(from Boost Python I believe) where one overload had a dummy int
parameter and one overload had a dummy long parameter.
I assumed it was to workaround the partial ordering bug but I'm not 100%
sure. But Dave's upcoming reply should clarify things. ;)
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: intrusive tagging allows omision of unneeded headers
Thorsten Ottosen wrote:
[snip]
class X
{
public:
class tag {};
typedef tag X_tag;
^
};
class bar
{
public:
class tag {};
typedef tag bar_tag;
^^^
};
Why these typedefs? Why would one write X::X_tag instead of X::tag for
example?
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: bidirectional pointer proposal
Hi Ulrich, I like the general idea of your bidi_ptr. I haven't really read your implementation yet, but your description sounds promising. I don't really like the name bidi_ptr though. Bidirectional is always spelled out in the Standard library. But bidirectional_ptr is rather long. How about paired_ptr? - using assignment for connecting peers warps the 'normal' modus operandi of assignment, should I rather us an auxillary function ? I think a member function or a free function called connect would be clearer. I'd prefer the free function because I think the fact that connect(a,b) does the same as connect(b,a) is more natural than the fact that a.connect(b) does the same as b.connect(a). But that may just be me. ;) - usually, I would make bidi_ptr a friend of bidi_ptr, because it needs access to its peers internals in order to not work recursively. This doesn't work with my compiler if B is the same as A, the compiler complains that any class is implicitly its own friend. Therefore all data is currently public. You could add a nested class in the private section of bidi_ptr, say prevent_friend_to_self. Then you could declare bidi_ptr to be a friend of: bidi_ptr::type > (That's pseudo-MPL. I don't currently use the MPL well enough to have memorized the correct syntax to do. It should all be in the docs though.) It's a bit of a mess, but it should work. Perhaps some clever Booster will think of a better way. ;) - what should operator-> or * do when there is no peer attached ? Nothing. You could assert that the peer pointer is not null, but don't do anything about it. IMHO. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review: Optional library
Peter Dimov wrote:
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
I don't know of 'standard' examples, but in my code I do that a lot:
class curve
{
shared_ptr acquire_approx() const { return m_approx ; }
shared_ptr m_approx ;
} ;
But this is not a get(). It is an acquire_approx(). :-)
Well at least it showed me the difference between acquire() and
release(). ;)
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review: Optional library
Fernando Cacciola wrote: I'm actually trying to vouch for my peek/acquire idiom here. Essentially, the name 'peek()' is intended to convey the fact that the pointer points to a managed object and that the ownership is not being transfered along with the pointer (as oposed to acquire()). If I manage to make the idiom known enough, the user will know that he can't delete the pointer and that the pointer can be used only as long as the 'source' (the optional<> object in this case) remains alive. I still don't see the difference between peek/acquire and get/release. Care to enlighten me? Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] int vs int32_t [was: Serialiization Review repost with consistentquoting]
Robert Ramey wrote: We should discuss whether to use short, int, long ... as the primitive types or int8_t, int16_t, int32_t, int64_t. The latter makes it easier to write portable archives, the former seems more natural. I can accept both choices but we should not mix the two as is done now. For who would it be less natural to use int32_t, etc instead of int, etc? Not the end user of the archive, right? And I think the writer of the archive would be more concerned with portability. And even he/she is not, the burden is not that great, is it? AFAICT the advantages of int32_t etc outweigh the disadvantages. But perhaps I'm missing something? Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: strict_weak_ordering
David Abrahams wrote: Ben Young writes: >On Mon, 25 Nov 2002, David Abrahams wrote: > > >>Ben Young writes: >> >> >>>Recently at our company we had a couple of bugs relating to people >>>incorrectly writing comparison operators, so I came up with this little >>>helper. It is very trivial, but useful none the less as bogus comparison >>>operators can be the cause of many bugs. >>> >>>Obviously it could be improved to take a predictate of some kind and >>>checged to use the boost pre-processor library, but, otherwise, is anyone >>>interested >> >>Did you ever consider using >> >>make_tuple(x1, y1, z1) < make_tuple(x2, y2, z2) >> >>? > >Yes, but actually I am of the feeling that perhaps the tuple library >should be using the strict_... form rather than the other way around. > >Won't the make_tuple method make a copy of all its arguments? OK: make_tuple(ref(x1), ref(y1), ref(z1)) < ... Isn't this equivalent to tie(x1, y1, z1) < tie(x2, y2, z2) ? Anyway, in the past I have needed/wanted the strict_... function family you propose, but: 1. I would call it lexicographic_ordering I agree. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: offset_cast proposal
Pavol Droba wrote:
Hi,
I have developed a simple cast function which I found very useful.
Here it is:
template< typename T >
inline T offset_cast( void* p, unsigned int offset=0 )
{
return reinterpret_cast< T >( static_cast( p )+offset );
}
template< typename T >
inline T offset_cast( const void* p, unsigned int offset=0 )
{
return reinterpret_cast< T >( static_cast( p )+offset );
}
Why only unsigned offsets?
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Review
Thomas Matelich wrote: "Dirk Gerrits" wrote in message ar37hg$6hm$[EMAIL PROTECTED]">news:ar37hg$6hm$[EMAIL PROTECTED]... >Thomas Matelich wrote: > > >>Anyway, seemed like a nice package for general use. My company is >>currently in love with XML, so I probably wouldn't be using it for our >>commercial products. > >Maybe you missed it due to only skimming the documentation, but it is >possible to write your own archive types for use with the library. An >XML output archive should be pretty easy, and I imagine that given an >XML parser, an input archive should also be quite feasable. I didn't miss it and considered it, but XML usually names its elements. That meta-data is an important part of validation and the free-form lovefest that makes XML popular. There is no way that I saw, given the abstract interface of the archives, to name the string that I put into the archive. Perhaps that could be an extension. Yes, other threads made me realize this. I withdraw my statements. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review Request: class optional<>
Fernando Cacciola wrote: - Original Message - From: "Dirk Gerrits" To: Sent: Friday, November 22, 2002 12:36 PM Subject: [boost] Re: Formal Review Request: class optional<> >[snipped] > >I guess I'd use if (peek(opt) != 0) or something. It's not that !! >is so ugly, but it's not very clear IMHO. > Another supported alternative which I forgot to mention is: if ( initialized(opt) ) ... Ooh. Nice! :) Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review Request: class optional<>
Fernando Cacciola wrote:
"Dirk Gerrits" wrote in message
arjgo5$o25$[EMAIL PROTECTED]">news:arjgo5$o25$[EMAIL PROTECTED]...
>Fernando Cacciola wrote:
>
>[snip]
>
>
>>void recieve_async_message()
>>{
>> optional rcv ;
>> while ( !!(rcv = get_async_input()) && !timeout() )
>>output(*rcv);
>>}
>
>[snip]
>
>Maybe it's a minor point, but I think the !! is really ugly. Have you
>considered the safe_bool idiom that's used in some other Boost
>libraries? (smart_ptr to name one.)
>
Yes, I did.
safe_bool (among other alternatives) was rejected because of the following
(this specific point is explained in detail on the documentation)
Sorry, I only read your post, not the documentation.
void foo()
{
optional opt = get_some();
bool is_it = opt;
}
What is the intention of 'is_it'?
Does it refer to the 'value' of 'opt', or to its initialized state?
Makes sense. Thanks for the explanation.
The problem is that safe_bool allows for a conversion to bool in
certain contexts, but this violates the design premise that there is
no implicit conversion from optional to T for the case when T=bool.
With the current design, the above will fail to compile, requiring the
user to disambiguate the meaning by choosing either:
bool is_it_initialized = !!opt;
bool is_it_true = *opt ;
For similar reasons, the following is not supported either:
if ( opt == 0 ) or if ( opt != 0 )
But if you really dislike the syntax, there is an alternative spelling:
if ( peek(opt) )
peek() returns a pointer to the optional value if it is initialized,
or NULL if it isn't. Such a pointer can be directly used in a boolean
context with the expected meaning.
I guess I'd use if (peek(opt) != 0) or something. It's not that !!
is so ugly, but it's not very clear IMHO.
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review Request: class optional<>
Fernando Cacciola wrote:
[snip]
void recieve_async_message()
{
optional rcv ;
while ( !!(rcv = get_async_input()) && !timeout() )
output(*rcv);
}
[snip]
Maybe it's a minor point, but I think the !! is really ugly. Have you
considered the safe_bool idiom that's used in some other Boost
libraries? (smart_ptr to name one.)
Regards,
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization & XML (was Serialization Library Review)
David Abrahams wrote: Robert, As review manager I'd like you to consider this very carefully. As much as I dislike XML for the hype that surrounds it and for its unweildy syntax, it has become a very important standard for many jobs, especially serialization. I believe your assessment that some data structures can't be represented using XML is incorrect, and that's easy to prove. A serialization library which makes generation of XML output difficult is severely handicapped in the modern world. Robert, there is an xml_pickle module for Python which can serialize any Python object to and from XML. C++ is a whole different language of course, but I do not believe it is unreasonable to assume that similar techniques could be used for C++ data structures. And Dave says it can even be proven. Which one of you is right, I don't know. But if either statement can be proven, I'd say show us some proof. ;) Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Upcoming changes to shared_ptr
David Abrahams wrote: "Peter Dimov" writes: >Fine with me. You are the LWG guy around here. Whatever you say. ;-) http://www.weebl.pwp.blueyonder.co.uk/crab.swf Reminds me of Futurama: "All glory to the hypno-toad!" ;) - Dirk ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL's "round" lambda
Dirk Gerrits wrote: Aleksey Gurtovoy wrote: > If you are tired of angle brackets in your templates (no, it's not a TV > commercial :), may be you'll like this one: [source code snipped] > The above actually compiles on Comeau C/C++ 4.3.0.1 and Intel C++ 6.0 > with > the current MPL sources in the CVS; see > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m > > pl/example/lambda2.cpp for an example. Note that the "factorial" snippet > there doesn't work yet (if you ask 'fact::value', it will blow). Seems very nice. But I feel to see the practical use of it. Is it just syntactic sugar? And if not, could you enlighten me on the practical use? :) feel should be fail, of course. And I hope I didn't sound to negative. Syntactic sugar can be good too. I just like to know if that is all it is. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Named Template Parameters implementation
Gennadiy Rozental wrote: >Even Microsoft will soon be supporting template template parameters and >partial specialization. How long more MSVC6 is going to be actively used, do you think? Is there any date/milestone since when we decide ignore non-supporting compilers for specified features? Well AFAIK it has never been required that Boost libraries support 'backwards' compilers. ISO/IEC 14882 compliant code would be acceptable. However, for usability, I agree that it is in everybody's best interest to support as many compilers as possible, which is what most Boost libraries do. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: minor scoped_ptr/scoped_array feature request
Thorsten Ottosen wrote: Since I'm not English, how should I read ""? I hope this answers your question: http://dictionary.reference.com/search?q=wink Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::noncopyable warning in VC7
Craig Henderson wrote: Hi, I am deriving from boost::noncopyable to prevent copying of my objects. When I compile in VC7 with /W4 (warning level 4), I get a warning C4511 - copy constructor could not be generated Isn't that what boost::noncopyable is supposed to do? The documentation states that: "This warning can be caused by having a copy constructor for the base class that is not accessible by the derived class". As a result, I changed the copy ctor and assignment operator to be protected rather than private to make them visible to the derived class, and all is well. Won't this mean that inside the class, copying will cause a link-time failure, and outside of it a compile-time failure? The mistake of accidentally copying an instance inside the class itself is probably pretty rare, but still, catching errors as early as possible is preferable IMHO. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL's "round" lambda
Aleksey Gurtovoy wrote: If you are tired of angle brackets in your templates (no, it's not a TV commercial :), may be you'll like this one: [source code snipped] The above actually compiles on Comeau C/C++ 4.3.0.1 and Intel C++ 6.0 with the current MPL sources in the CVS; see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m pl/example/lambda2.cpp for an example. Note that the "factorial" snippet there doesn't work yet (if you ask 'fact::value', it will blow). Seems very nice. But I feel to see the practical use of it. Is it just syntactic sugar? And if not, could you enlighten me on the practical use? :) Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL lambda
Mat Marcus wrote: Scatter hierarchies can be achieved by using inherit_linearly together with mpl::inherit. See the second example that Aleksey cited *is* an example of a scatter hierarchy. Forgive me, I hadn't realized this. That's just too cool! :) Thanks. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Review
Thomas Matelich wrote: Anyway, seemed like a nice package for general use. My company is currently in love with XML, so I probably wouldn't be using it for our commercial products. Maybe you missed it due to only skimming the documentation, but it is possible to write your own archive types for use with the library. An XML output archive should be pretty easy, and I imagine that given an XML parser, an input archive should also be quite feasable. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL lambda
Aleksey Gurtovoy wrote: Rozental, Gennadiy wrote: >Also is there gen_scattered/linear_hierarchy implementation >somewhere for MPL sequenses? MPL's 'inherit_linearly' algorithm + 'inherit' metafunction (in the CVS now) cover both of these. Please see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m pl/example/inherit_linearly.cpp and http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m pl/example/inherit_multiply.cpp for the corresponding examples. This is some very cool stuff! However, the way I understand it, inherit_linearly takes a type sequence (like mpl::list) as an argument and inherit takes the types themselves as arguments. I'd like to have an inherit that takes a type sequence as an argument, instead of or in addition to the current inherit. This is because I need to do some Modern-C++-Design-ish stuff which needs a scattered hierarchy instead of a linear one. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
IIRC the old persistance library defined facilities for input and output using the RFC-1014 XDR: External Data Representation Standard. The new serialization library doesn't seem to include such archive classes and leaves it up to the user to write these. Now I don't mean to dispute the decision, but I'd just like to know what the rationale for it was. Secondly, I have a nit about the documentation. In the reference section about the 'Definition of New Archive Formats' it is said that: 'The archive format is specified by implementing the virtual functions of the base class.' I think it would be clearer if the documentation also stated all those virtual functions that one should implement, so that the user wouldn't have to read archive.hpp. Perhaps a simple example should be provided. Say, a rot13 text stream or something. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 'function' idea
Aleksey Gurtovoy wrote:
Dirk Gerrits wrote:
>I still don't get it. Have I used to few widget libraries? ;)
OK, we are drifting from the actual topic here, but I really don't
like the
fact that I can't express myself clearly tonight :). So, here we go:
class widget_model
{
public:
// ...
typedef boost::function bool_arg_t;
self_t& is_enabled(bool_arg_t a_enabled)
{
is_enabled_ = a_enabled;
return *this;
}
boolis_enabled() const
{
return is_enabled_();
}
private:
bool_arg_t is_enabled_;
};
class win32_widget_impl
{
public:
win32_widget_impl( /* ... */)
{
// setup this->on_idle() to be called, well, on idle
}
void on_idle()
{
// sync itself with the model
::EnableWindow(hwnd_, model_->is_enabled());
}
private:
HWND hwnd_;
ref_ptr model_;
};
Since the model is passive here, everything works as per my first example
(given 'widget' -> 'widget_model' substitution).
Ahh, now I understand. Looks cool indeed. However I'm not sure how often
this might be useful. Perhaps smarter people than I can think of more
examples?
Dirk
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 'function' idea
Aleksey Gurtovoy wrote:
So, the corrected example would be:
class widget
{
public:
// ...
typedef boost::function bool_arg_t;
self_t& is_enabled(bool_arg_t a_enabled); // note the
signature!
boolis_enabled() const;
};
int main()
{
widget w;
w.is_enabled(true); // ordinary syntax/semantics
assert(w.is_enabled())
widget w2;
w.is_enabled(boost::bind(&widget::is_enabled, &w2)); // here!
w2.is_enabled(false);
assert(!w.is_enabled()) // !
}
I hope the name change makes the semantics of the above clearer.
I still don't get it. Have I used to few widget libraries? ;)
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: In the Spirit of Challenge
Andrei Alexandrescu wrote: "Paul Mensonides" wrote in message news:001601c286c9$64eedf40$6401a8c0@;c161550b... [about a C++ preprocessor] >This one I'd like to see, but it might be too easy. There isn't much to >Cpp. Explain this to the MSVC and MWCW folks. They both got it wrong. That's the main reason for which I'd like an open-source, good quality C++ preprocessor. And by the way, I understand some preprocessors take a pathologically long time with the Preprocessor Library (something I'm too scared to look at) so if Boost had a preprocessor offering, that would come in handily. Then, users could combine the Boost preprocessor with their compiler. If a Spirit-based C/C++ preprocessor could really be faster with the Boost Preprocessor Library than commercial quality preprocessors 'out there' that would really rock! :D Dirk ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
