Hi,
I have been reading the discussiong here about adding the support for unicode.
Maybe there is a solution which would allow to have templated versions of
relevant classes AND static library in one box.
If we decide that specialization for char and wchar_t is sufficient, the headers
can con
Rozental, Gennadiy wrote:
> 1. You store something inside class cmdline
Actually, only arguments, for the benefit of folks which might use 'cmdline'
standalone. Options are not stored there.
> 2. You store strings in options_and_arguments
> 3. You store typed values in variables_map
>
> In my o
> > 1. Static vs Shared
> > I would much prefer header files only instead of a shared library.
Having
> > to deal with shared libraries are a pain on many systems (such as
cygwin).
> > Using a header file is clean and easy -- therefore much preferred by me.
> > One of the biggest benefits to boost
Hi Tanton,
Tanton Gibbs wrote:
> Since there have been a few emails bouncing around, I'd like to chime in
> with my opinions on a few matters.
>
> 1. Static vs Shared
> I would much prefer header files only instead of a shared library. Having
> to deal with shared libraries are a pain on many s
Circular refs are easy to avoid with smart_ptr lib but idiomatically what
you are really looking for is DynObj (and maybe RRef ) in the NoPtr lib
(http://noptrlib.sourceforge.net). Strict ownership is ideal for pimpl and
in particular your example of circular dependency, as supported by the NoPtr
l
>From: "Ian Baxter" <[EMAIL PROTECTED]>
> I wish that the date time library could construct a ptime from it's own
> to_simple_string function.
>
> i.e time = time_from_string( to_simple_string( time ) );
>
> Strange to have library that can construct a time from a string, but not
> from a string i
Chuck Messenger wrote:
> Vladimir Prus wrote:
>> Chuck Messenger wrote:
>>
>>
>>>Vladimir Prus wrote:
>>>
>>>
Yep. This question was raised already. I think that making templates out
of all classes is *a* solution, but I'm not sure it's *the* solution.
The problem is that extensive t
Matthias Troyer wrote:
>
> On Tuesday, May 27, 2003, at 05:44 PM, John Torjo wrote:
>
- does not work for wchar_t. While this might seem silly, it's not,
>> since
VC allows for a TCHAR* command line string.
>>>
>>> I have to consider this. An obvious approach would be to add template
>
I wish that the date time library could construct a ptime from it's own
to_simple_string function.
i.e time = time_from_string( to_simple_string( time ) );
Strange to have library that can construct a time from a string, but not
from a string it itself has produced.
Also, with MSVC 7.0, the date
Since there have been a few emails bouncing around, I'd like to chime in
with my opinions on a few matters.
1. Static vs Shared
I would much prefer header files only instead of a shared library. Having
to deal with shared libraries are a pain on many systems (such as cygwin).
Using a header file
Peter Dimov wrote:
Chuck Messenger wrote:
Consider that A and B may implement various "interfaces" (i.e. inherit
from 1+ abstract base classes w/o member variables). I can't just use
multiple inheritance (i.e. AB inherits from each interface that
either A
or B needs), because, for one thing, ther
> It isn't clear from you post if you are aware of all the work (including a
> formal review) that has already gone into persistence and/or serialization
> at Boost. See the archives at
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost
>
Sheesh. A lot of work has been done. A comparati
The documentation at
http://www.boost.org/libs/conversion/lexical_cast.htm
appears to make no mention of the whitespace-handling, or the fact
that it can't handle things like lexical_cast("0x16"). It would be
appreciated if these restrictions could be made clear.
regards,
john
__
Hi, I'm new to this list and I'm writing here just to suggest to you a different
implementation for lexical_cast.
Actually lexical_cast doesn't make easy to add possibilities for new casts, and
for example if I have to cast from
IpAddress class to an int it wouldn't be easy. (even casting IpAddress
> It isn't clear from you post if you are aware of all the work (including a
> formal review) that has already gone into persistence and/or serialization
> at Boost. See the archives at
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost
>
> In particular, are you aware of Robert Ramey's
David Pearce <[EMAIL PROTECTED]> writes:
> David,
>
>> I think I had the same problems when I implemented the reverse_graph
>> adaptor, and never found a good answer :(
>
> Thanks for the reply. Looking at the reverse_graph_adaptor, I notice
> that you achieve what I want using the
> "reverse_grap
> > The ability to create flexible offsets from a given date are extremely
> > useful, especially when the units involved are mixed (days, weeks,
months,
> > years). The ability of the Date-Time library to handle situations like
this
> > has really impressed me so far, but situations where the of
Chuck Messenger wrote:
[snip[
Thanks -- it looks very interesting.
I did some googling, to see what its status is. Seems it hasn't been
mentioned much since the flurry of activity in Jan-May 2001. Pity,
since if it works "as advertised", it seems pretty useful.
I implemented Lin's local mark
Larry Evans wrote:
Chuck Messenger wrote:
[snip]
In general, the abstraction is: you have a group of intra-referential
objects. When any of the group is constructed, they are all
constructed (so that the master count is temporarily > 1), and the
master count is reset to 1. When the master coun
Take a look at the new version of
http://boost.sourceforge.net/regression-logs/. I think the meaning of the
percentages is much clearer now.
Thanks to those who provided suggestions, and to Rene Rivera for the
implementation.
--Beman
___
Unsubscribe
At 11:44 AM 5/27/2003, Peter Dimov wrote:
>Chuck Messenger wrote:
>> For convenience, logical continuity, and consistency with other Boost
>> libraries, you should be able to include all the smart_ptr pieces with
>>
>> #include
>>
>> Currently, only 4 are included:
>>
>> #include
>>
Chuck Messenger wrote:
>
> Consider that A and B may implement various "interfaces" (i.e. inherit
> from 1+ abstract base classes w/o member variables). I can't just use
> multiple inheritance (i.e. AB inherits from each interface that
> either A
> or B needs), because, for one thing, there can be
Chuck Messenger wrote:
[snip]
In general, the abstraction is: you have a group of intra-referential
objects. When any of the group is constructed, they are all constructed
(so that the master count is temporarily > 1), and the master count is
reset to 1. When the master count goes to 0, the gr
Peter Dimov wrote:
Chuck Messenger wrote:
In general, the abstraction is: you have a group of intra-referential
objects. When any of the group is constructed, they are all
constructed (so that the master count is temporarily > 1), and the
master count is
reset to 1. When the master count goes to
>> > 2. Layered design.
> > IMO All of my
> > concerns are unfortunate consequences of the way you designed your
> > library. IMO there should be one typed storage for the parsed
> arguments
> > (instead of 3 like you have) linked with formal parameters
description.
> You are not correct. There
I have a suggestion for two new member functions for shared_ptr .
Both give useful information that is currently available, but in non-obvious
or potentially inefficient ways.
1) bool empty() const
returns true if the shared_ptr does not own an object, and false if
it does own an object
Chuck Messenger wrote:
>
> Suppose I have a cyclic dependency between A and B, which are
> implemented with the pimpl idiom:
>
> #include
> #include
>
> using namespace boost;
> using namespace std;
>
>
> struct B_impl;
>
> struct B {
> shared_ptr pimpl_;
>
Peter Dimov wrote:
Chuck Messenger wrote:
For convenience, logical continuity, and consistency with other Boost
libraries, you should be able to include all the smart_ptr pieces with
#include
Currently, only 4 are included:
#include
#include
#include
#include
Missing are
On Tuesday, May 27, 2003, at 05:44 PM, John Torjo wrote:
- does not work for wchar_t. While this might seem silly, it's not,
since
VC allows for a TCHAR* command line string.
I have to consider this. An obvious approach would be to add template
parameter to every class, telling which char type to
Peter Dimov wrote:
Chuck Messenger wrote:
Suppose you have this:
struct X {
shared_ptr y;
...
};
struct Y {
X x;
};
struct Z {
Z() : pimpl_(new Y()) { pimpl_->x.y = pimpl_; }
shared_ptr pimpl_;
...
};
I'm using t
At 07:04 PM 5/25/2003, Scott Woods wrote:
>Is anyone interested in a persistence mechanism?
It isn't clear from you post if you are aware of all the work (including a
formal review) that has already gone into persistence and/or serialization
at Boost. See the archives at
http://aspn.activestat
> > - does not work for wchar_t. While this might seem silly, it's not,
since
> > VC allows for a TCHAR* command line string.
>
> I have to consider this. An obvious approach would be to add template
> parameter to every class, telling which char type to use. So investigation
> is needed to find al
- Original Message -
From: "Reece Dunn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 27, 2003 1:57 PM
Subject: Re: [boost] Re: Enum operators
> I have adopted a Java-style approach to enumerated-style values (don't
know
> if this is the best approach, just the way that
I take back this suggestion -- intrusive_ptr<> does what I want.
- Chuck
Chuck Messenger wrote:
Suppose you have this:
struct X {
shared_ptr y;
...
};
struct Y {
X x;
};
struct Z {
Z() : pimpl_(new Y()) { pimpl_->x.y = pimpl_;
Alexander Terekhov wrote:
> Peter Dimov wrote:
>>
>> Trevor Taylor wrote:
>>>
>>> Why wait? With so many people contributing to boost, why not
>>> introduce a pthread_refcount_t into into boost threads (or is there
>>> one already?), provide a default implementation equivalent to what
>>> shared_p
Chuck Messenger wrote:
> Suppose you have this:
>
> struct X {
> shared_ptr y;
> ...
> };
>
> struct Y {
> X x;
>
> };
>
> struct Z {
> Z() : pimpl_(new Y()) { pimpl_->x.y = pimpl_; }
> shared_ptr pimpl_;
>
Chuck Messenger wrote:
> For convenience, logical continuity, and consistency with other Boost
> libraries, you should be able to include all the smart_ptr pieces with
>
> #include
>
> Currently, only 4 are included:
>
> #include
> #include
> #include
> #include
>
> Mi
37 matches
Mail list logo
