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
/library_technical_report.html
Regards,
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
!
Regards,
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
.
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
number of keys and values, if I recall correctly.
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
and report back in a few days.
Nice :-)
Indeed. :)
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
::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 cassert.
Regards,
Dirk Gerrits
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
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
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
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
if it's such a huge advantage over:
template typename T
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
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
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
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
?
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
(). :-)
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
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
outweigh the disadvantages. But
perhaps I'm missing something?
Regards,
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
co
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
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
libraries? (smart_ptr to name one.)
Regards,
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thorsten Ottosen wrote:
Since I'm not English, how should I read wink?
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
?
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
a
scattered hierarchy instead of a linear one.
Regards,
Dirk Gerrits
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
31 matches
Mail list logo
