[boost] Re: Re: dynamic_void_cast
"Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
at76e1$2ro$[EMAIL PROTECTED]">news:at76e1$2ro$[EMAIL PROTECTED]...
>
> "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
> at542o$2hq$[EMAIL PROTECTED]">news:at542o$2hq$[EMAIL PROTECTED]...
> >
> > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
> > at52vi$si6$[EMAIL PROTECTED]">news:at52vi$si6$[EMAIL PROTECTED]...
> > [snip]
> >
> > > I'd like to be able to store references to objects of arbitrary types
in
> a
> > > homogenous collection, not requiring them to be derived from a common
> base
> > > class. For COM users, that would be something like an "IUnknown in the
> > > context of standard C++". I suspect that boost::any might be something
> > > similar to what I need, but I just got that idea using void pointers.
> > >
> >
> > What's the point of that? I mean, with no interface to the types, you
> can't
> > do anything with these objects you're storing, not even delete them.
> >
>
> If I can dynamically cast a void pointer to a polymorphic type, I can do
> whatever I want to do.
>
> > You could also do:
> >
> > struct IHolder {
> > virtual ~IHolder () {}
> > };
> >
> > template
> > class holder : public IHolder{
> > public:
> > holder (Object* const object);
> > ~holder ();
> > };
> >
> > It's always better to try and look for a real (type safe) solution than
> > playing around with type casting. It still depends on what you want to
> _do_
> > with theses objects behind this common, empty interface. I suspect
> problems
> > with your design if you have been led down this path.
> >
>
> I _am_ looking for a type safe solution, I was simply playing around
trying
> to find one that would fit my needs.
>
> I'm actually experimenting with a kind of 'generic' object factory with
the
> following characteristics:
>
Well then void* is not what you need. Especially in your design, you may
later decide that need to not only delete these objects in the factory, but
do other things with them as well.
I think you need to reanalyze what your needs are and the important roles in
this system. It seems to be that there is more than one class necessary
here.
Anyhow, in my opinion, dynamic_void_cast is completely unnecessary and takes
casts away the intent that it is _supposed_ to be a two step and very ugly
process--the signifier that you have a not-so-good design on your hands.
Stop trying to code a new messenger.
[snip]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: Re: dynamic_void_cast
Oh. Yes, on that particular machine I was using 1.27. Thanks. "Peter Dimov" <[EMAIL PROTECTED]> wrote in message 00c301c2a07d$d1d09860$1d00a8c0@pdimov2">news:00c301c2a07d$d1d09860$1d00a8c0@pdimov2... > From: "Eric Woodruff" <[EMAIL PROTECTED]> > > Ok, it works with the "correct" usage. That usage is a little unwieldy, > and > > I didn't find any specific documentation about it using the search > mechanism > > on www.boost.org (the site or on the list). > > You didn't answer the important question about the version of Boost you are > using. The site reflects the current release, 1.29. > > > Can improper usage such as mine be disabled? > > Not in 1.27, as this would mean going backwards in time. It is a proper > usage in 1.28, 1.29, and the current CVS version. > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: dynamic_void_cast
Ok, it works with the "correct" usage. That usage is a little unwieldy, and
I didn't find any specific documentation about it using the search mechanism
on www.boost.org (the site or on the list).
Can improper usage such as mine be disabled?
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
005d01c2a073$546e1960$1d00a8c0@pdimov2">news:005d01c2a073$546e1960$1d00a8c0@pdimov2...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> >
> > Doesn't make any difference with the outcome in theory or in my test as
I
> > just tried it.
> >
> > int main () {
> > boost::shared_ptr p (new Object);
> > }
> >
> > No destructor printed.
>
> Sorry, I can't reproduce this with any compiler. Are you using Boost
1.28+?
> In 1.27 the correct way to do the above is
>
> boost::shared_ptr p = boost::shared_ptr(new Object);
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: dynamic_void_cast
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
003f01c2a06f$2c4f6550$1d00a8c0@pdimov2">news:003f01c2a06f$2c4f6550$1d00a8c0@pdimov2...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> > Using g++ 2.95.4,
> >
> > #include
> > #include
>
> Changed to .
>
Mistyped in the message, but was correct in the code.
> > struct Object {
> >~Object () {
> >std::cout << "byebye" << std::endl;
> > }
> > };
> >
> > int main () {
> > Object o; // destructs
> > boost::shared_ptr (new Object); // does not destruct, however
> > apprears to delete
> > std::cout << "done." << std::endl;
> > }
>
> C:\Documents and Settings\pdimov\My
Documents\Projects\testbed>g++ --version
> 2.95.3-6
>
> C:\Documents and Settings\pdimov\My Documents\Projects\testbed>g++
> testbed.cpp
>
> C:\Documents and Settings\pdimov\My Documents\Projects\testbed>a
> byebye
> done.
> byebye
>
> Note that you are constructing an unnamed temporary shared_ptr,
which
> is why it destructs before "done." is printed.
Doesn't make any difference with the outcome in theory or in my test as I
just tried it.
int main () {
boost::shared_ptr p (new Object);
}
No destructor printed.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: dynamic_void_cast
Using g++ 2.95.4,
#include
#include
struct Object {
~Object () {
std::cout << "byebye" << std::endl;
}
};
int main () {
Object o; // destructs
boost::shared_ptr (new Object); // does not destruct, however
apprears to delete
std::cout << "done." << std::endl;
}
I didn't find any special documentation explaining special use of
boost::shared_ptr.
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
002b01c2a06b$2388ade0$1d00a8c0@pdimov2">news:002b01c2a06b$2388ade0$1d00a8c0@pdimov2...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> > I tested a shared_ptr and while it seems to be invalidating the
> memory
> > of the pointer (implying that it is deleted), the proper destructor is
> never
> > called.
>
> Please post a test case that fails.
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: dynamic_void_cast
I tested a shared_ptr and while it seems to be invalidating the memory of the pointer (implying that it is deleted), the proper destructor is never called. "Peter Dimov" <[EMAIL PROTECTED]> wrote in message 000701c2a066$b1a8e720$1d00a8c0@pdimov2">news:000701c2a066$b1a8e720$1d00a8c0@pdimov2... > From: "Johan Nilsson" <[EMAIL PROTECTED]> > > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > Incidentally, shared_ptr may allow you the kind of type erasure > > > you want. Just a thought... > > > > I' afraid I don't really follow you. Wouldn't shared_ptr choke on > > trying to delete through a void pointer? > > No. > > shared_ptr pv(new X); > pv.reset(); // calls X::~X() > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dynamic_void_cast
"Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
at52vi$si6$[EMAIL PROTECTED]">news:at52vi$si6$[EMAIL PROTECTED]...
[snip]
> I'd like to be able to store references to objects of arbitrary types in a
> homogenous collection, not requiring them to be derived from a common base
> class. For COM users, that would be something like an "IUnknown in the
> context of standard C++". I suspect that boost::any might be something
> similar to what I need, but I just got that idea using void pointers.
>
What's the point of that? I mean, with no interface to the types, you can't
do anything with these objects you're storing, not even delete them.
You could also do:
struct IHolder {
virtual ~IHolder () {}
};
template
class holder : public IHolder{
public:
holder (Object* const object);
~holder ();
};
It's always better to try and look for a real (type safe) solution than
playing around with type casting. It still depends on what you want to _do_
with theses objects behind this common, empty interface. I suspect problems
with your design if you have been led down this path.
[snip]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Status of dangerous_cast<>
I don't think that anyone is going to find a new quote from the standard that will end the discussion on reinterpret_cast. Even and email from Bjarne okayed by three major platform compiler developers probably wouldn't suffice anymore. I had pointed out that instead of using any cast, one can just use a placed_new<> template that returns the correct object. I guess that isn't always useful since there are other needs besides creation (unless the object in h.storage was self-deleting and never accessed through h.storage again). Here's a question: Since h.storage is _meant_ to be accessed by those that do not know the type of the object inside, shouldn't it have been designed as a void* in the first place? This has two benefits (and I've recently had the epiphany of why void* is ok): 1) A void* makes it more convenient for the user of the class to access the object via static_cast. static_cast is just as dangerous as reinterpret_cast when you have a void* typelessObject; 2) A void* abstracts out the manor in which h.storage was allocated, which hides more implementation details. Unfortunatly, it probably takes more memory and requires use of the heap. Can someone tell me the destruction semantics in this scenerio? How does the object in h.storage get destroyed? It seems like the object that used the placed new cannot have its destructor called. Anyhow, that was just one example given to work with. I think that with a combination of static_casts there is no run-time overhead, so what wrong with just using dangerous_cast? It could maybe use a better name. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dangerous_cast<>
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Eric Woodruff" <[EMAIL PROTECTED]> writes: > > [...] > > | > Thus, given that h.storage is properly aligned, (which is the purpose of > | the > | > other union member), after "new(h.storage) Foo", h.storage contains a Foo > | > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the > | > dynamic type of the object. > | > > | > | This is precisely my reasoning why reinterpret_cast<> is _not_ > | implementation defined. > | > | It must be the case that it is equal to the situation of having > | > | Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object. > > > After giving more thoughts to the analysis given by Anthony and > 5.2.10/1, I think I agree with you're right. > Well, for a reinterpret_cast to be valid, it must be used to cast away from the type, and return to it. In my example, I was only returning to it. I question the validity of that. If new (p) Object; takes a void* and does an implicit cast, I don't think there is any reinterpret_casting taking place on the inside. However, I think there must be some kind of cast to char* to allocate the memory in number of bytes, but I'm not sure. The size of char is not necessarily 1 byte, correct? So either way, this allocation implementation defines what happens. Again, however, I mentioned in a different post that we could always force a reinterpret_cast<> via new (reinterpret_cast (h.storage)) Object, but if an implementation remembers that h.storage is an unsigned char*, or even if it doesn't, I think reinterpret_cast may only be valid to cast void* h.storage to unsigned char* h.storage. This is, of course, because of the wording of the standard. In reality, reinterpret_cast<> most likely has the expected result on all platforms. > -- Gaby > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] placed_new <>, was Re: dangerous_cast<>
Is my previous statement only valid if placement new used a reinterpret_cast
on it's implementation? Or if h.storage was reinterpret_cast-ed to a void*
when it was passed in? Well, if reinterpret_cast remembered the type, it
would know it wasn't what we were trying to cast it to.
Also, instead of a placement_cast, why not write a placed_new<> template (as
someone said, offset_cast is only used in this situation):
template
Object* const placed_new (Storage* const storage) {
new (storage) Object;
return ...;
}
// .. support construction with (1, 2, 3, ...) parameters as well
"Eric Woodruff" <[EMAIL PROTECTED]> wrote in message
aso09f$akc$[EMAIL PROTECTED]">news:aso09f$akc$[EMAIL PROTECTED]...
>
> "Anthony Williams" <[EMAIL PROTECTED]> wrote in
> message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Eric Woodruff writes:
> > > "Anthony Williams" <[EMAIL PROTECTED]> wrote in
> > > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > > Thus, given that h.storage is properly aligned, (which is the
purpose
> of
> > > the
> > > > other union member), after "new(h.storage) Foo", h.storage contains
a
> Foo
> > > > object. Thus accessing it through a pointer-to-Foo is legal, as Foo
> is the
> > > > dynamic type of the object.
> > > >
> > >
> > > This is precisely my reasoning why reinterpret_cast<> is _not_
> > > implementation defined.
> > >
> > > It must be the case that it is equal to the situation of having
> > >
> > > Foo* -> char */void* -> Foo* if Foo is the dynamic type of the
object.
> >
> > Nowhere do I see a requirement that supports your deductions. Indeed
there
> are
> > very few requirements on reinterpret_cast<>, other than the fact that
what
> it
> > does must be defined by the implementation. For pointers to objects,
these
> > amount to:
> >
> > * T1* can be converted to T2* and back again unchanged (unless T2 has
> stricter
> > alignment requirements).
>
> Precisely, T1 is Foo in this case as you have already pointed out. This is
> simply the identity conversion T1 -> T2 -> T1, which is pretty much the
only
> thing reinterpret_cast can do portably.
>
[snip]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Anthony Williams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Eric Woodruff writes: > > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > > message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Thus, given that h.storage is properly aligned, (which is the purpose of > > the > > > other union member), after "new(h.storage) Foo", h.storage contains a Foo > > > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the > > > dynamic type of the object. > > > > > > > This is precisely my reasoning why reinterpret_cast<> is _not_ > > implementation defined. > > > > It must be the case that it is equal to the situation of having > > > > Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object. > > Nowhere do I see a requirement that supports your deductions. Indeed there are > very few requirements on reinterpret_cast<>, other than the fact that what it > does must be defined by the implementation. For pointers to objects, these > amount to: > > * T1* can be converted to T2* and back again unchanged (unless T2 has stricter > alignment requirements). Precisely, T1 is Foo in this case as you have already pointed out. This is simply the identity conversion T1 -> T2 -> T1, which is pretty much the only thing reinterpret_cast can do portably. > > * You can convert a pointer to the first member of a POD struct to a pointer > to the struct, and vice-versa. > > * A Null pointer of any type can be cast to a null pointer of any other type. > > Anthony > -- > Anthony Williams > Senior Software Engineer, Beran Instruments Ltd. > Remove NOSPAM when replying, for timely response. > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
(inline) "Anthony Williams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [snip] > Gabriel Dos Reis writes: > unsigned char* has _additional_ properties to void* --- you can access the > object representation of _any_ object through an unsigned char* (and for PODs, > you can copy them around using this) > > 3.9p4: > "The object representation of an object of type T is the sequence of N > unsigned char objects taken up by the object of type T, where N equals > sizeof(T)." > > 3.10p15: > "If a program attempts to access the stored value of an object through an > lvalue of other than one of the following types the behavior is undefined: > > - the dynamic type of the object, > > ... > > - a char or unsigned char type." > [snip] > Thus, given that h.storage is properly aligned, (which is the purpose of the > other union member), after "new(h.storage) Foo", h.storage contains a Foo > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is the > dynamic type of the object. > This is precisely my reasoning why reinterpret_cast<> is _not_ implementation defined. It must be the case that it is equal to the situation of having Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object. [snip] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dangerous_cast<>
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > > > Thanks for your patience. > > > > Now, imagine an implementation where the original type is remembered, > > then dereferencing the pointer obtained from > > > >char* -> void* -> T* > > > > may just eject you into the outer space. > > Is remembering the original type _of_ _the_ _pointer_ actually legal? > Can you quote chapter and verse on this? I thought the implementation > was only permitted to eject you if you use a pointer where the actual > type _of_ _the_ _pointee_ is wrong. > I was under the impression that the pointee was not actually a T (thus making the use of reinterpret_cast char* -> T* implementation defined). Does this mean that the ability to dereference is equally as non-portable as reinterpret_cast<>ing? > -- >David Abrahams >[EMAIL PROTECTED] * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"David B. Held" <[EMAIL PROTECTED]> wrote in message aslftb$cr2$[EMAIL PROTECTED]">news:aslftb$cr2$[EMAIL PROTECTED]... > "Eric Woodruff" <[EMAIL PROTECTED]> wrote in message > aslbsn$nt3$[EMAIL PROTECTED]">news:aslbsn$nt3$[EMAIL PROTECTED]... > > [snip] > > > > > holder h; > > > new (h.storage) Foo; > > > > What is the meaning of that syntax? > > This is placement new syntax. It means construct a Foo at the address > h.storage, without allocating any memory. > So the type really is of Foo, which has to mean that casting h.storage back to a Foo* using reinterpret_cast is covered by the standard. > > >... > > > T* u = dangerous_cast(h.storage); // can't do this with > > > reinterpret_cast > > > > Why would you want to do that in the first place. > > Because you want to get at the T in h in a portable way. Which brings > me to my next point. Since it seems this is the only context in which this > cast is guaranteed to give a meaningful result, maybe it should be called > placement_cast<>? > > Dave > > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
"Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "David B. Held" <[EMAIL PROTECTED]> writes:
>
> | Does this have any merit whatsoever?
> |
> | template
> | T* dangerous_cast(U* p)
> | {
> | return static_cast(static_cast(p));
> | }
>
> Is it any different from reinterpret_cast(p) ?
no because either way, the only thing you can do with that T* result is cast
it back to its original type before using it, which is the very you do with
reinterpret_cast.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: dangerous_cast<>
[snip] > holder h; > new (h.storage) Foo; What is the meaning of that syntax? >... > T* u = dangerous_cast(h.storage); // can't do this with reinterpret_cast Why would you want to do that in the first place. > > HTH, > -- >David Abrahams >[EMAIL PROTECTED] * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Sockets
In my experience in attempting to develop an over-general sockets abstraction, it is next to impossible to contrive a perfect generalization of the many different socket types. A good sockets implementation will at a minimum: * Use polymorphism on a well-defined socket interface. This will allow code to be written that is protocol neutral and easy to maintain. This is also a better choice over attempting to create an overly complex do-all 'socket' class that takes an enum to try and determine the protocol desired--I think everyone will agree that attempting to use GP and Policies will be just as messy here. The implementation will be much cleaner when small, specialized implementations are allowed. This approach will also trivially allow extensibility (even by the boost::end.user) to support other implementations that can be submitted without affecting existing implementations. Also, specific protocols should get their own sub-namespace. * Separate Reading/Writing versus Connecting or Accepting connections. There are a few ways to do this, either by having a pure interface that defines reading or writing and an object (kind of factory?) that will accept connections or create new ones. This seems like a good approach because it distills functionality between the two main needs of sockets. It also may ease development because in general, on a given platform, I/O on a socket is usually identical and not dependent on the protocol, where connecting is. However, this may go against the desired user convention, which needs to be decided over and before any implementation convenience. It may be decided that sockets have a constructor that take an (protocol-specific) address class (implicitly constructible by a char const*) for opening connections, and there is only a listening service type class that takes in new connections and returns a socket that is already connected. * Support for Event-Driven and Blocking sockets This one should go without saying. The event-driven support can trivially be provided in the pure socket interface and easily created using tools like boost::signals or boost::function. ** Thread Pool For event-driven sockets, a thread per socket can sometimes be wasteful, so there may be support for using a thread pool that monitors for events on the sockets in an application. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Illegal Friend?
According to g++ and comeau, the following is illegal: (The commented line
allows the code to compile.)
class A {
public:
A () {}
~A () {}
private:
class Nested;
//friend class B;
};
class B {
public:
B () {}
~B () {}
private:
friend class A::Nested;
};
Here's why:
"7 A name nominated by a friend declaration shall be accessible in the scope
of the class containing the friend declaration."
It is ridiculous that I can't give access to an inaccessible class. You have
to have access to be able to give it? What is the justification for this?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re:Re:reinterpret_cast&>[wasRe:const-correctnessas functionargument]
"Rob Stewart" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > From: "Eric Woodruff" <[EMAIL PROTECTED]> > > > > Every reference I can find excludes pointer conversions from being > > implementation defined. They all (even the standard) specifically treat > > pointer conversions differently (clause 7) than pointer->integer->pointer > > conversions. This is because creating an integer requires mapping the bits > > to a temporary, converting pointers does not require this because pointers > > share the same underlying representation, and it is done in compile time so > > there is no possibility of translation occuring. > > > > "reinterpret_cast treats all pointers exactly as traditional type-casting > > operators do. " [snip] > So, 5.2.10/7 plainly states that there's only one thing you can > do portably with reintrepret_cast on pointers: convert from one > type to another and back again. Everything else is unspecified, > so you can't even count on finding the result documented on each > platform of interest. This means that your references and > understanding are wrong if they lead you to conclude that one-way > pointer conversions are anything other than unspecified. > [snip] The context surrounding converting a pointer "back again" is kind of subjective. In the context of this original discussion, it was in converting a pointer of an object to a char const* const for use with serialization. This data is eventually deserialized and, thus, converted "back again." In that context, do you find it to be unspecified? In my opinion, as long as the bit representation remains the same [as in, the character bits are not fiddled with during the time they are archived], it falls under the category of converting a pointer to another pointer and then to the original type. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Upcoming changes to shared_ptr
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > From: "Eric Woodruff" <[EMAIL PROTECTED]> > >> > >> "David Abrahams" <[EMAIL PROTECTED]> wrote in message > >> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > "Peter Dimov" <[EMAIL PROTECTED]> writes: > >> > [snip] > >> Alternatively, it could be named boost_dynamic_cast > >> and put in the global namespace, where it can be overloaded as needed by > >> boost. > > > > This doesn't look too good if you consider the possible boost->std > > transition. :-) > > But "sp" does? > >How about dynamic_pointer_cast(x)? Why not polymorphic_cast<>? > > Of course, we can make it work for regular pointers, too. > > -- >David Abrahams >[EMAIL PROTECTED] * http://www.boost-consulting.com > Boost support, enhancements, training, and commercial distribution > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Upcoming changes to shared_ptr
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > * shared_*_cast will be renamed to sp_*_cast. > > Why? Without rationale, this seems like a gratuitous change, > especailly since "sp" doesn't mean much to me. > Agreed. "sp" is so wonderfully expressive. Actually, I was going to voice a complaint of that, but the ideal would overload dynamic_cast, but since it is a language keyword, that can't happen. So I can kind of see sp_ as a work-around for that. Alternatively, it could be named boost_dynamic_cast and put in the global namespace, where it can be overloaded as needed by boost. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposed Boost Assert -- once again
In my opinion, assertions indicate enfrorcement of pre/post conditions, that are separate from the algorithmic logic of a function. What happens from the result of the assertion, an exception or an abort is a separate issue. Consider (if assert takes a boost::function0): assert (!harddrive.isFragmented (), boost::bind (&HardDrive::defrag, &harddrive)); In this case, it there is a simple remedy to the failed pre-condition. The alternative is: assert (!harddrive.isFragmented (), std::abort); ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
type_info is not portable in the slightest. "Vahan Margaryan" <[EMAIL PROTECTED]> wrote in message news:003401c28bee$7fbc4f40$4f09a8c0@;lan.mosaic.am... - Original Message - From: "Robert Ramey" <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 5:45 PM Subject: Re: [boost] Serialization Submission version 6 > > > register_cross_program_class_identifier(const char *id="T") > > This would be invoked for each class declaration. Now we have > a portable id associated with each class - exactly what we need. > Polymorphic pointers would archive this tag and use it > to determine the proper class to construct on loading. > > The default class identifier would be the text representation of the class name. > (note: in general not necessarily the same as type_info.name() ) > which is going to be sufficent for almost all cases. The problem that usually arises from this is having to make up class ids for template classes. type_info does this for you. Regards, -Vahan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: function queue
Yeah, it's the same concept. I had failed to distinguish thread_pool versus thread_group. Hopefully, adding the timeout and growing logic does not sacrifice the efficiency of the pool when it is full/has plenty to work on. "William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:3599.167.16.75.51.1037037372.squirrel@;frodo.kempf-ville.com... > > Eric Woodruff said: > > William, > > > > I'm not sure. I haven't been following the development branch, and don't > > know exactly how to access it. > > $> cvs co -r thread_development boost > would check out the thread_development branch. Tweak as needed for your > environment. > > > I called this class a function queue > > based on what I saw of the currently released boost::thread::thread_pool > > which was merely a collection of various threads that provided a grouped > > join. > > I think you're talking about boost::thread::thread_group here. The > boost::thread::thread_pool in the thread_development branch sounds like > your "function queue", unless I'm misunderstanding something from your > short description. > > > I needed to be abstracted from the thread itself. Thus, thread was > > not a good choice in the class's name. > > I'm not sure I follow this, but here's a short example of using a > thread_pool. > > int min_threads=3; > int max_threads=10; > int timeout=10; // seconds > boost::thread_pool pool(max_threads, min_threads, timeout); > pool.add(some_function_object); > pool.add(some_function_object); > pool.add(some_function_object); > pool.add(some_function_object); > pool.add(some_function_object); > > The number of threads that will be used to dispatch the queued function > objects will expand and contract between min_threads and max_threads, with > idle threads waiting for the specified timeout before terminating if there > are more than min_threads available. > > The user never directly accesses a thread in a thread_pool. He only adds > function objects to a queue on which the pooled threads will work. > > -- > William E. Kempf > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposed Boost Assert -- once again
I've always used the examples out of TC++PL of some assertions:
template
assertion (bool const condition) {
if (!condition) {
throw Exception ();
}
}
template
assertion (bool const condition, Exception const& exception) {
if (!condition) {
throw exception;
}
}
What about having a function-class based assertion that worked like:
assertion (!Sanity::invalidArgument || 0 != p, Throw (invalid_argument
("must not be zero")));
assertion (2 > x, Abort ());
or maybe even
assertion (2 > x, DontCompile ());
implementation ---
template
assertion (bool const condition, Function const& f) {
if (!condition) {
f ();
}
}
It looks very idiomatic to me.
I've also found things like this useful:
template
Condition const& assertNonZero (Condition const& condition) {
if (0 == condition) {
throw Exception ();
}
return condition;
}
Consider:
return x / assertNonZero (b - a);
"Kevin S. Van Horn" <[EMAIL PROTECTED]> wrote in message
news:Pine.LNX.4.44.020833530.25298-10@;speech.cs.ndsu.nodak.edu...
> It's been six days since I posted this, without a single response, so I'm
> going to try again. Based on earlier discussions, I thought there might
> be some interest in this. Does anyone have any problems with the proposed
> interface? Should I turn this into a formal proposal for submission to
> Boost? Peter, how does this compare with the changes to
> you were planning to do / are doing?
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: function queue
William, I'm not sure. I haven't been following the development branch, and don't know exactly how to access it. I called this class a function queue based on what I saw of the currently released boost::thread::thread_pool which was merely a collection of various threads that provided a grouped join. I needed to be abstracted from the thread itself. Thus, thread was not a good choice in the class's name. eric "William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:3666.167.16.75.51.1037032721.squirrel@;frodo.kempf-ville.com... > > Eric Woodruff said: > > Is there any interest in a threaded function queue? I ran into a problem > > where I needed to asynchronously run methods but I didn't want to (or > > actually couldn't easlily) maintain threads to run them in. So I created > > a function queue where I could control the number of threads that were > > used to execute the (Boost.Function) functions. There is a lot of room > > for customization like specifying policies for controlling how/if the > > processing thread collection can grow. > > Unless I'm not understanding precisely what you mean, it sounds like your > talking about a "thread_pool", as implemented in the thread_development > branch. Could you compare contrast what you have in mind with what's > available there? > > -- > William E. Kempf > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] function queue
Is there any interest in a threaded function queue? I ran into a problem where I needed to asynchronously run methods but I didn't want to (or actually couldn't easlily) maintain threads to run them in. So I created a function queue where I could control the number of threads that were used to execute the (Boost.Function) functions. There is a lot of room for customization like specifying policies for controlling how/if the processing thread collection can grow. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
