Hi, I have just build the filesystem for the first time from the current CVS
state and I notice that the filesystem library is called "libfs.lib" on
windows. Judging by the naming convention used by the other current boost
libraries, shouldn't this library be called "libboost_filesystem.lib"?
___
Hi,
The sequence data structure is very nice. One of the advantages is that it
makes it possible to reduce syntactic clutter considerably compared to
lists.
Unfortunately, due to preprocessor limitations, one is limited to
parenthesized expressions that do not contain top-level commas. For exa
David Abrahams:
Vesa Karvonen:
> BTW, the same "acceleration" technique can be used with templates to
> overcome template recursion depth limitations. Probably most people
> know about it already, though I haven't explicitly checked. > (Plain
unrolling is not as effective: Theta(k*n) < Theta(pow(
"Vesa Karvonen" <[EMAIL PROTECTED]> writes:
> David Abrahams:
>>Vesa Karvonen:
>> > BTW, the same "acceleration" technique can be used with templates to
>> > overcome template recursion depth limitations. Probably most people
>> > know about it already, though I haven't explicitly checked. > (Plai
Joel de Guzman wrote:
- Original Message -
From: <[EMAIL PROTECTED]>
Hi,
I was talking to you on the boost newsgroup about spirit being slow to compile
Here is a standalone section of code, it'll compile but you can't do anything with it
The compile takes about 15 mins on my machine
(
From: "William E. Kempf" <[EMAIL PROTECTED]>
> Peter Dimov said:
> >
> > The fact that who() returns a function name is not important; it is not
> > a "mini call stack". A function name is used as a token that identifies
> > the point of failure. What failed? An attempt to open a file? An attempt
>
From: "David Abrahams" <[EMAIL PROTECTED]>
>
> So what about as_shared or to_shared?
These are cast names. I'll think about it for a while.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From: "Nicola Musatti" <[EMAIL PROTECTED]>
> David Abrahams wrote:
> > "Peter Dimov" <[EMAIL PROTECTED]> writes:
> [...]
> >>Of course you could do that as well, but my point is that the primary
> >>purpose of make_* functions is argument deduction, and the primary
purpose
> >>of make_shared/get_sh
From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
> Greeting everyone,
>
> It seems placement operator new (size_t, ...) would extend a lot
garbage
> collection possibilities. Why don't we define a set of rules for each tag
> this overloaded placed operator would use:
>
> shared_ptr(new int());
Hi,
The following is an example of using "superlinear unrolling". It compiles
with
gcc version 2.95.4 20011002 (Debian prerelease)
using the default settings (max template recursion depth should be 17). The
example code essentially applies the inc template 262 times. The example
code uses pa
"Vesa Karvonen" <[EMAIL PROTECTED]> writes:
> It seems to be quite tricky to reach maximal iteration counts using
> this technique. I think that others might have more insight into how
> to tune the code for maximal iteration counts.
What do you mean by "maximal iteration counts?"
If you mean, "t
David Abrahams:
Vesa Karvonen:
> It seems to be quite tricky to reach maximal iteration counts using
> this technique. I think that others might have more insight into how
> to tune the code for maximal iteration counts.
What do you mean by "maximal iteration counts?"
If you mean, "the maximum po
"Vesa Karvonen" <[EMAIL PROTECTED]> writes:
>>What do you mean by "maximal iteration counts?"
>>If you mean, "the maximum possible under a given depth limitation",
>>then clearly there's no such number because you can always do more
>>unrolling... so obviously you don't mean that. ;-)
>
> Well, on
Gennadiy,
About month ago, while working on Boost.Test issues I was faced with the
need for the more or less full featured command line argument parser. I
recall that you were working on one and took a look on some of your
preliminary code in vault area.
What code, specifically? The only think
Hi Boosters,
I was wondering if it would be possible to implement a wrapper around
built-in types to provide automatic detection of conversion
problems:
template< typename T >
class safe_numeric : boost::operators< safe_numeric >
{
public:
typedef boost::detail::fixed_numeric_limits result_t
On the Win32 random_test regression test, gcc is chewing up 1.2 gigs of
virtual memory, then dying. See below.
I'd appreciate it if one of the gcc experts who reads this list would
report the problem to the gcc folks in the appropriate form.
Also, random_test is failing other compilers, too. I
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
00bc01c2bc89$d77fe5e0$1d00a8c0@pdimov2">news:00bc01c2bc89$d77fe5e0$1d00a8c0@pdimov2...
> From: "Philippe A. Bouchard" <[EMAIL PROTECTED]>
> > Greeting everyone,
> >
> > It seems placement operator new (size_t, ...) would extend a lot
> garbage
> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]]
>
> Hi Boosters,
>
> I was wondering if it would be possible to implement a wrapper around
> built-in types to provide automatic detection of conversion
> problems:
[snip]
What would the advantage be over using boost::numeric_cast directly, an
"David B. Held" <[EMAIL PROTECTED]> wrote in message
b02kh4$7tp$[EMAIL PROTECTED]">news:b02kh4$7tp$[EMAIL PROTECTED]...
> "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
> b02f0c$o1d$[EMAIL PROTECTED]">news:b02f0c$o1d$[EMAIL PROTECTED]...
> >
> > It seems placement operator new (si
At 04:25 AM 1/15/2003, Steven Kirk wrote:
>Hi, I have just build the filesystem for the first time from the current
>CVS
>state and I notice that the filesystem library is called "libfs.lib" on
>windows. Judging by the naming convention used by the other current boost
>libraries, shouldn't this li
"Vladimir Prus" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Gennadiy,
>
> > About month ago, while working on Boost.Test issues I was faced with the
> > need for the more or less full featured command line argument parser. I
> > recall that you were working
Vesa Karvonen wrote:
> Hi,
Hi Vesa,
>
> The following is an example of using "superlinear unrolling".
> It compiles with
>
> gcc version 2.95.4 20011002 (Debian prerelease)
>
> using the default settings (max template recursion depth should be
> 17). The example code essentially applies th
Gennadiy Rozental wrote:
your submission: a) None of 5 compiler configurations installed on my XP
could not compile it.
:-(
I've made some corrections recently. Did anything improve?
I've tried version you announced yesteday.
Hmm... can you provide error messages?
Is it possible to take a
It is time to start talking about the 1.30.0 release.
I'd like to suggest that new libraries be committed (or merged) into the
main CVS branch by the end of January, with the actual release two or three
weeks later.
How does that sound?
--Beman
___
<[EMAIL PROTECTED]> wrote in message
3D8559AE95B4D611B02C0002557C6C8B3C45BF@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45BF@STH-EXCH...
> > From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]]
> >
> > Hi Boosters,
> >
> > I was wondering if it would be possible to implement a wrapper around
> >
Beman Dawes <[EMAIL PROTECTED]> writes:
> On the Win32 random_test regression test, gcc is chewing up 1.2 gigs
> of virtual memory, then dying. See below.
FWIW, it chews memory on every compiler. The test is just too big and
needs to be split up. Trying to find workarounds for compiler
problems
Vincent Finn wrote:
> >>I was talking to you on the boost newsgroup about spirit
> being slow to
> >>compile Here is a standalone section of code, it'll compile but you
> >>can't do anything with it The compile takes about 15 mins on my
> >>machine (We are using spirit for a second file but that i
Sorry, I've missed an important detail (see below):
> Vincent Finn wrote:
>
> > >>I was talking to you on the boost newsgroup about spirit
> > being slow to
> > >>compile Here is a standalone section of code, it'll
> compile but you
> > >>can't do anything with it The compile takes about 15 mins o
> There are only syntactic differences with
>
> http://zigzag.cs.msu.su:7813/program_options/html/variables_map.html
No. I don't think so. You present fixed rigid interface. In my case almost
everything is optional. You don't have parameter description - you don't
provide one.
On the other han
> Hmm... can you provide error messages?
Will do later today.
> I would say that it's a big question how much flexibility is
> needed. My
> position is that the command line should not go beyond
> existing styles.
Could you list all existent styles? Does your parser supported all of them?
>
Now about config file feature.
I have 2 major issues with your design.
1. You again placed 2 eggs into same basket.
There are 2 levels of configuration file reading
a) level that is responsible for comments lines, empty lines, continued
lines, include, ifdef, defines and so on
b) level
I have failed twice to get access via the CVS web browser, and also via command
line, though I can log into sourceforge itself.
Suggestions?
Thanks
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mail
[2003-01-15] Paul A. Bristow wrote:
>I have failed twice to get access via the CVS web browser, and also via
command
>line, though I can log into sourceforge itself.
>
>Suggestions?
Wait for SourceForge to fix their problems ;-) They seem to be having heavy
packet loss to cvs.sourceforge.net, in
"Rene Rivera" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> Wait for SourceForge to fix their problems ;-) They seem to be having
> heavy packet loss to cvs.sourceforge.net, in the range of 60% and more.
Probably Microsoft is launching a DDOS attack to
At 02:17 PM 1/15/2003, Paul A. Bristow wrote:
>I have failed twice to get access via the CVS web browser, and also via
>command line, though I can log into sourceforge itself.
>
>Suggestions?
They have been having trouble for several days. The CVS status reports:
Developer (SSH) CVS access onlin
> If you are interested, please comment on it. I would especially like to
> know if the benefits of an Acceptor/Connector pattern would outweigh the
> additional complexity involved (specifically, how much more complicated
> the sample test.cpp file would get). Thanks!
Basically the beginning woul
- Original Message -
From: "Vesa Karvonen" <[EMAIL PROTECTED]>
Hi Vesa,
> The implementation of RELATION_TO_SEQ() should not be very difficult, but
> there is a quick incomplete implementation in this post, that can give
some
> ideas. A more generic "token sequence" to sequence conversion
Thanks for this. I will try again later. Paul
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Beman Dawes
> Sent: Wednesday, January 15, 2003 8:26 PM
> To: Boost mailing list; Boost
> Subject: Re: [boost] Web Browser CVS access
>
>
> At 02:17 PM 1/
I have renamed placed_ptr<> to shifted_ptr<> and added a placed operator new
(size_t, gc) that can be used with shared_ptr<>:
http://groups.yahoo.com/group/boost/files/shifted_ptr/
I agree that shifted_ptr<> makes more sense. Thanks Dave.
Philippe A. Bouchard
__
I've modified any_cast to work properly with references.
In the boos 1.29 implementation, a code like this:
{
any x=5;
++any_cast(x);
}
doesn't compile because any_cast tries to instantiate a pointer to int
&. With the attached patch (which uses ::boost::remove_reference in
boost/type_trai
any_cast, as is implemented in boost 1.29, has one weakness; it doesn't
allow to compile this piece of code:
any x=int(5);
++any_cast(x);
because any_cast tries to instanciate a pointer to int&. The attached
patch solved this problem using boost::remove_reference from
boost/type_traits.hpp
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
b04jar$uv4$[EMAIL PROTECTED]">news:b04jar$uv4$[EMAIL PROTECTED]...
> I have renamed placed_ptr<> to shifted_ptr<> and added a placed
> operator new (size_t, gc) that can be used with shared_ptr<>:
> http://groups.yahoo.com/group/boost/file
Hi Paul,
Paul Mensonides:
> TOKEN_SEQ_TO_SEQ(FIRST, REST, IS_LAST, B o o s t SPACE 1 3 1)
> ==> (B)(o)(o)(s)(t)(SPACE)(1)(3)(1)
I already have something almost exactly like this in the high-precision
arithmetic that haven't committed yet. Of course, you'd have to have a
macro for every l
At 10:43 AM 1/15/2003, Vladimir Prus wrote:
>I don't know how to compare number of people who need command line to the
>number of people who *also* need config file. I suppose that as your
>program grows bigger, you're likely to need config file too. The
transition
>should be simple.
I run int
> That's a long way of supporting Vladimir's views above. People first need
> just command line arguments, then later realize a config file would be
> nice. And yes, the transition should be simple and transparent.
>
> --Beman
I do not argue that an ability to support other configuration means co
"David B. Held" <[EMAIL PROTECTED]> wrote in message
b04n9f$ik2$[EMAIL PROTECTED]">news:b04n9f$ik2$[EMAIL PROTECTED]...
> [...] I don't see any documentation, except for what few
> comments exist in the source. It isn't clear where you expect people to
> use your pointer, or if there are usages
> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]]
> > What would the advantage be over using boost::numeric_cast
> directly, and
> > thus explicitly?
>
> you would't have to worry about if you forgot a numeric_cast
> somewhere in
> your code
> or if you compiled on a platform with different r
47 matches
Mail list logo
