headers
Andreas Scherer | 1 Mar 2000 08:16
Picon

Re: Bug in smart_ptr.hpp

beman dawes <bema- <at> esva.net> wrote: 
>
> So it really isn't something we can fix by changes in our files by
> picking one of the native formats and converting everything to that
> format.

The problem is not that <smart_ptr.hpp> (and possibly other files in
the boost archive as well) is in one of the native formats (say Unix
versus Win32); the problem in this particular case is that
<smart_ptr.hpp> is in a _mixed_ file format. The last time I looked
(must have been version 1.11), one line in a multiline macro definition
had the "wrong" eof character(s), so the preprocessor of gcc hickups.
Apart from multiline macros, gcc on Unix/Linux is perfectly happy with
"native Win32" source files, just as, e.g., MSVC deals fine with
"native Unix" source files.

To conclude, let me vote together with all those other gcc hackers to
clean up <smart_ptr.hpp> once and for all. Please.

-- Andreas
Permalink | Reply | 1 comment |
headers
Knut-Håvard Aksnes | 1 Mar 2000 08:47
Picon

Re: Bug in smart_ptr.hpp

Andreas Scherer writes:
 > beman dawes <bema- <at> esva.net> wrote: 
 > >
 > > So it really isn't something we can fix by changes in our files by
 > > picking one of the native formats and converting everything to that
 > > format.
 > 
 > The problem is not that <smart_ptr.hpp> (and possibly other files in
 > the boost archive as well) is in one of the native formats (say Unix
 > versus Win32); the problem in this particular case is that
 > <smart_ptr.hpp> is in a _mixed_ file format. The last time I looked
 > (must have been version 1.11), one line in a multiline macro definition
 > had the "wrong" eof character(s), so the preprocessor of gcc hickups.
 > Apart from multiline macros, gcc on Unix/Linux is perfectly happy with
 > "native Win32" source files, just as, e.g., MSVC deals fine with
 > "native Unix" source files.
 > 
Thats exatly the point, unzip -a usually does a good job in
conversting between Microsoft and unix conventions, in this case I
suspect that the files have been edited on Mac's. The \r endings
persisted after unziping with the -a option.
Permalink | Reply | 0 comments |
headers
Andrew D Jewell | 1 Mar 2000 22:30
Picon

Re: Submission: RunVector

For those who care, a revised version of RunVector can be found at

http://home.cinci.rr.com/dancers/code/

Is this the sort of thing that would belong in boost?

Andy Jewell
Permalink | Reply | 1 comment |
headers
John Maddock | 2 Mar 2000 13:22
Picon

Re: Challenge: pool allocator

Steve,

>These issues are handled.  boost::pool automatically handles alignment
>issues in a portable way, and the free-list overlay is also guaranteed
>to be portable.  (I think -- this is the shakiest part of the whole
>thing).

Aha! someone else who can't resist a challenge :-)

I've only looked *quickly* at your alignment code, however I don't think
that it quite guarentees correct alignment - as I understand it your code
only guarantees alignment on a sizeof(char*) boundary, but there may be
types which require alignment on a larger boundary than that, I figured
that the logic goes like this:

1) we need to store two differnt types T and U in the same memory location
- so that memory must be properly aligned for both T and U - that is the
smallest number A which has both Align(T) and Align(U) as a factor.
2)The memory must be large enough for both T and U, and rounded up to a
multiple of A - the common alignment factor.

The code I put together only deels with (1) - finding the alignment
requirements of any type T, and combining to alignments into a "smallest
common multiple", the rest is somewhat easier (I hope!).

Anyway here is the code with a short test program, the classes alignment_of
and least_common_mult do all the work:

#include <iostream>
#include <set>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stephen Cleary | 2 Mar 2000 18:55

Re: Challenge: pool allocator

john maddock wrote: 
> I've only looked *quickly* at your alignment code, however I don't
think
> that it quite guarentees correct alignment - as I understand it your
code
> only guarantees alignment on a sizeof(char*) boundary, but there may
be
> types which require alignment on a larger boundary than that, I
figured
> that the logic goes like this:

My code required alignment on a multiple of sizeof(char *); however, it
would still break if other alignments are not multiples of sizeof(char
*).  This is because the chunk partition size was min(sizeof(T),
sizeof(char *)), rounded up to the nearest multiple of sizeof(char *). 
However, I've fixed it now -- the chunk partition size is now
lcm(sizeof(T), sizeof(void *)).

The update is in the vault.  While I was there, I also changed some of
the code to be more readable :).  Also, I ran testing on every
alignment BCB supports, but odd alignments like the one below are not
supported.

First, just one comment on the portability of your code:

> 
> ...
> 
> template <typename T>
> struct alignment_of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Braden N. McDaniel | 2 Mar 2000 23:36
Gravatar

Re: Installing Boost Libraries

On 29 Feb 2000, Raja R Harinath wrote:

> Just an example.  Think, instead, of using GNU C++ and SunPro C++ on
> the same machine.  The same logic holds.

Okay, I see what you're saying. However, I'd expect persons with such a
setup to be rather familiar with the steps involved in juggling between
two (or more? yikes) compilers.

--

-- 
Braden N. McDaniel
braden <at> endoframe.com
<URL:http://www.endoframe.com>
Permalink | Reply | 0 comments |
headers
Paul Jensen | 2 Mar 2000 23:30

Re: auto_ptr in collections

Steve Clamage wrote:
> John Nagle wrote:
> >    Did the use of collections with auto_ptr elements ever get fixed,
> > or is that still broken?
> ...
> The various complaints about auto_ptr all boil down to having
> conflicting sets of requirements. They can't all be satisfied
> at once. I think a future C++ standard could have a collection of
> safe-pointer classes, each with different semantics.

I've been trying to find a reasonable safe-pointer representation to hold the
ownership of a class data member - ie, replace class C { TYP *t; ... }; with
class C { class_template<TYP> t; } where the class C is intended to have value
semantics, and the cctor and op= for class_template<TYP> either copy the object
of type TYP, or share it. 

C's members need to change t's value, and that seems to require auto_ptr as the
appropriate argument type for passing the ownership in and out.

auto_ptr<TYP> fails to work unless C's cctor and op= deal with it explicitly.

Boosts shared_ptr<TYP> seems to address the problem, but I've found no way to
modify its value since there is no release() capability. get() followed by
reset() results in a dangling pointer, and swap() just postpones the agony. I
can't seem to convert shared_ptr => auto_ptr.

Since this situation is akin to the problem of a collection of owning pointers,
I thought the solution would be the same. 

I'm attaching a short class declaration to sketch what I'd like.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beman Dawes | 3 Mar 2000 03:40

Re: Submission: RunVector

At 04:30 PM 3/1/00 -0500, Andrew D Jewell wrote:

>For those who care, a revised version of RunVector can be found at
>
>http://home.cinci.rr.com/dancers/code/
>
>Is this the sort of thing that would belong in boost?

My initial reaction is that the range of applications for RunVector
is a bit too narrow to attract a lot of interest from boost members.

On the other hand, there isn't any hard-and-fast rule that says we
won't post something just because it is narrowly focused.  Let's see
it interests other boost members enough to work out technical issues
with you.

--Beman
Permalink | Reply | 0 comments |
headers
Dave Abrahams | 3 Mar 2000 06:11
Picon

Re: Challenge: pool allocator

on 2/29/00 5:08 PM, scleary <at> jerviswebb.com at scleary <at> jerviswebb.com wrote:

> BTW, what is the proposed purpose of 'pool'?  Just a garbage collector?

1. garbage collector
2. Saves on space overhead for dynamic allocation (size labels, internal
fragmentation)
3. Should be faster than almost any variable-size allocator

Steve,
I will have a closer look at your work before Monday. On first inspection,
it is very impressive. I'm a little curious about the
function-object-constructor approach. While perfectly general, it seems a
lot less convenient than the family-of-template-functions strategy. Maybe it
would be best if both were available.

-Dave

[
I'm very glad to see that so much activity on the subject of pool allocators
has gone on in my absence (sorry, my life just got suddenly crazier than
usual for a while)!
]
Permalink | Reply | 1 comment |
headers
Gavin Collings | 3 Mar 2000 14:36
Picon

shared_ptr co-existence with other smart pointers

> 
> Boosts shared_ptr<TYP> seems to address the problem, but I've found no 
> way to modify its value since there is no release() capability. get() 
> followed by reset() results in a dangling pointer, and swap() just 
> postpones the agony. I can't seem to convert shared_ptr => auto_ptr.
> 

The above highlights a need for boost::shared_ptr<> to co-exist with other smart
pointer implementations.  The current 'policy' for boost::shared_ptr<> seems to
be that it will accept ownership from raw pointers or std::auto_ptr<>, but will
never give it back again.  Since boost::shared_ptr<> and its kin only implement
a sub-set of conceivable desired ownership semantics, this seems overly
restrictive.  Presumably, as the trend towards using various smart pointers to
support exception safety continues, this will become increasingly so.  The
options seem to be: -

1) Insist on the current policy, shared_ptr is closed (or at least as closed as
it can be).  Use shared_ptr in cases where auto_ptr would normally be used.

2) Accept the need to open up ownership to other shared_ptr implementations. 
This can be handled fairly neatly by supplying a release() method.  This has
already been proposed for linked_ptr; it could easily be incorporated into
shared_ptr.  I'm still in two minds whether it's best to allow this operation in
situations where more than one smart pointer is involved (probably not).

Supplying explicit methods to convert to other known smart pointers (e.g.
release_as_auto_ptr) would be largely redundant, since most (all?) smart
pointers will have a constructor taking a raw pointer anyway.

Another way of handling this, may be by using a proxy class, along with suitable
(Continue reading)

Permalink | Reply | 1 comment |

Gmane