"Jaap Suter" <[EMAIL PROTECTED]> writes:
> Thanks! All of the code from my original message is now turned into:
>
> // \brief Meta function, returns the number of bits equal to 1 in a given number.
> // \param N Some number. Concept: boost::mpl::integral_c
> // \retval ::type boost::mpl::integral_
> Be sure to check John Maddock's "Coding Guidelines for
> Integral Constant Expressions"
> (http://www.boost.org/more/int_const_guidelines.htm), as well
Thanks for that. I've seen it a long time ago (hence I was using
BOOST_STATIC_CONSTANT already), but some of the tips there I forgot.
For exampl
>From: "Thomas Witt" <[EMAIL PROTECTED]>
> Kevlin Henney wrote:
> >>
> >>This is the philosophy that Kevlin and I agreed on when lexical_cast
> >>was first introduced. However, I don't think it has stood the test of
> >>time with real users, and it would be stupid to ignore that. I
>
> Agreed. I
>From: "Early Ehlinger" <[EMAIL PROTECTED]>
> This is an interesting argument. In other words, lexical_cast is, by
> definition, conversion through a stream. Therefore, one cannot expect a
> string with whitespace to exit as it went in.
Not a string that uses whitespace as termination, no. Howe
>From: "Thomas Witt" <[EMAIL PROTECTED]>
> On Sunday 29 December 2002 01:29, Terje Slettebø wrote:
> > > there...) Anyway, the surprising result of this was that the space in
> > > "Hello there" caused the interpreter.eof() check in lexical_cast to
fail.
> > > So if that check were not present, d
Doesn't MSVC support pre-compiled headers? This will speed up compilation
much more than '#pragma once'. Try creating a common header file which
includes all of your project's header files, and have all source files
include the common header, and compare compile times.
> "#pragma once" is just an
At 11:38 AM 12/30/2002, Toon Knapen wrote:
>On Sunday 22 December 2002 20:09, David Abrahams wrote:
>> Alkis Evlogimenos <[EMAIL PROTECTED]> writes:
>> For those running regression tests (and most Boost.Build users), I
>> really recommend setting ALL_LOCATE_TARGET so that the products of
>> your b
At 11:43 AM 12/29/2002, Douglas Gregor wrote:
>Where in the Boost tree should we put generated documentation?
We need to move carefully, and make sure we deal with the needs of several
different constituents:
* Those who access docs directly via the web site.
The need here is to continue to ha
Hi.
With recent CVS, code using tokenizer > fails to
compile for me (MSVC 6.5) unless I include the following specialisation:
namespace boost { namespace detail {
template <>
struct iterator_traits : ptr_iter_traits
{
};
}}
It complains that value_type is not a member of base at line 382.
(I tr
Kevlin Henney wrote:
This is the philosophy that Kevlin and I agreed on when lexical_cast
was first introduced. However, I don't think it has stood the test of
time with real users, and it would be stupid to ignore that. I
Agreed. I see the problem, I am just unsure with regard to the solutio
In message <[EMAIL PROTECTED]>, David Abrahams
<[EMAIL PROTECTED]> writes
>"Early Ehlinger" <[EMAIL PROTECTED]> writes:
>
>> [Sorry for the top-posted reply... OE is giving me fits...]
>>
>> This is an interesting argument. In other words, lexical_cast is,
>> by definition, conversion through a st
On Mon, 30 Dec 2002 11:18:41 +0100, Alberto Barbati
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota wrote:
>> Hmm... frankly I haven't used it anymore. I'm under the impression
>> they have fixed it now, but last time I checked it had a lot of bugs.
>> It was easy, for instance, to end up including the
On Mon, 30 Dec 2002 00:07:19 -0800, "Paul Mensonides"
<[EMAIL PROTECTED]> wrote:
>Do you mean that the actual headers must be structured in such a way as to
>only get included once? In other words, to have a inclusion tree that is
>invariant? Or do you mean that the compiler should only process
"Maxim Litvinov" <[EMAIL PROTECTED]> writes:
> Hi all.
> Is there any way to determine type of expression statically?
Short answer: no. Some compilers implement typeof(), though not the
one we really want, and there exist several elaborate schemes which
attempt to simulate this capability in por
Toon Knapen <[EMAIL PROTECTED]> writes:
> On Sunday 22 December 2002 20:09, David Abrahams wrote:
>> Alkis Evlogimenos <[EMAIL PROTECTED]> writes:
>> For those running regression tests (and most Boost.Build users), I
>> really recommend setting ALL_LOCATE_TARGET so that the products of
>> your bui
"Jaap Suter" <[EMAIL PROTECTED]> writes:
> Anyway, any hints for the above would be appreciated, but the actual
> question is: is it worth it spending a lot of time on an MSVC7 port, or is
> this an effort doomed to fail from the start?
Everything I've done with MPL so far has worked beautifully
Hi all.
Is there any way to determine type of expression statically?
Not just string representation or ID (like typeid() does), but type itself.
So I could create objects of the same type.
It could be useful, when result of expression is not clear to programmer.
For example, to save result of expre
Jaap Suter wrote:
> what's the current status on using MPL on different
> compilers? I have looked
> at http://www.mywikinet.com/mpl/log.html but it seems not all
> meta-functions are listed there.
I would say that currently the tests cover about 80% of library
functionality, so the aforemention
On Sunday 22 December 2002 20:09, David Abrahams wrote:
> Alkis Evlogimenos <[EMAIL PROTECTED]> writes:
> For those running regression tests (and most Boost.Build users), I
> really recommend setting ALL_LOCATE_TARGET so that the products of
> your build all go into a single directory tree that's n
Gennaro Prota wrote:
Hmm... frankly I haven't used it anymore. I'm under the impression
they have fixed it now, but last time I checked it had a lot of bugs.
It was easy, for instance, to end up including the same file twice if
it was reached through different paths (e.g.: #include "subdir/file.h"
- Original Message -
From: "Glen Knowles" <[EMAIL PROTECTED]>
> From: Alberto Barbati
> > Yet I'm stuck with MSVC anyway, as many other programmers out there,
> > and #pragma once may have a significant effect on compilation time on
> > that compiler.
>
> You may want to check this hypoth
21 matches
Mail list logo
