[boost] Re: [variant] 2 or more types requirement
Ronald Garcia wrote: > In reading through the variant docs, I noticed a requirement that at least > two types must be supported by the variant. Is this meant for ease of > library implementation, or is this a means of protecting programmers from > themselves? :-) [snip] In addition to the comments offered by Itay, the original idea was that one parameter would be reserved exclusively for the variant syntax. With the advent of mpl::is_sequence, however, this is no longer necessary IMO. Now, particularly after proposals for the idea of variant containing an empty 'void' type, I am in favor of eliminating the parameter count requirement altogether. In other words, variant<> would be shorthand for variant, which would be always empty but still conformant with the variant interface. Thanks for your comments. Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shared_ptr extension with counter in object header
The weather kept me at home today, so I had time to hack in
a new constructor for shared_ptr that keeps the count in a
header which is allocated along with the counted object.
Like intrusive_ptr, but intrusive in a different way. If
anyone has time to apply the patches and see if it is as
fast as it should be I would most grateful.
The new public constructor goes inside shared_ptr in
shared_ptr.hpp:
template
explicit shared_ptr(Y * p,const detail::counted_header_tag&)
: px(p), pn(detail::new_counted_base_in_object_header(p)) // Y must be complete
{
}
To make it easier to get the tags right I added a few
helper functions, which made me wish again for type-safe
variadic functions. They go in the boost namespace in
shared_ptr.hpp:
template
inline shared_ptr new_counted() {
detail::counted_header_tag counted;
return shared_ptr(new(counted) T(),counted);
}
template
inline shared_ptr new_counted(const P1& p1) {
detail::counted_header_tag counted;
return shared_ptr(new(counted) T(p1),counted);
}
template
inline shared_ptr new_counted(const P1& p1,const P2& p2) {
detail::counted_header_tag counted;
return shared_ptr(new(counted) T(p1,p2),counted);
}
template
inline shared_ptr new_counted(const P1& p1,const P2& p2,const P3& p3) {
detail::counted_header_tag counted;
return shared_ptr(new(counted) T(p1,p2,p3),counted);
}
// ... repeat above with more args until bored
The guts of the change go near the end of shared_count.hpp:
namespace boost {
namespace detail {
template class counted_base_header_impl: public counted_base
{
private:
P ptr; // copy constructor must not throw
D del; // copy constructor must not throw
counted_base_header_impl(counted_base_header_impl const &);
counted_base_header_impl & operator= (counted_base_header_impl const &);
public:
// pre: initial_use_count <= initial_weak_count, d(p) must not throw
counted_base_header_impl(P p, D d, long initial_use_count, long
initial_weak_count):
counted_base(initial_use_count, initial_weak_count), ptr(p), del(d)
{
}
virtual void destruct() // nothrow
{
}
virtual void dispose() // nothrow
{
del(ptr);
}
};
template struct object_with_counted_header {
char header[sizeof(counted_base_header_impl >)];
char object[sizeof(T)];
};
template inline void* get_counted_object_header(T* p) {
return (char*)p - offsetof(object_with_counted_header,object);
}
template struct checked_counted_header_deleter
{
typedef void result_type;
typedef T* argument_type;
void operator()(T* p)
{
typedef char type_must_be_complete[sizeof(T)];
::operator delete(get_counted_object_header(p));
}
};
template
inline counted_base* new_counted_base_in_object_header(T* p) {
return new (get_counted_object_header(p))
counted_base_header_impl >
(p,checked_counted_header_deleter(),1,1);
}
template struct counted_header_tag {};
} // namespace detail
} // namespace boost
template
inline void* operator new(size_t n,const boost::detail::counted_header_tag&) {
assert(n == sizeof(T));
return (char*)::operator
new(sizeof(boost::detail::object_with_counted_header))
+ offsetof(boost::detail::object_with_counted_header,object);
}
I haven't bothered with an array version yet, and have tested
only with GCC on Cygwin.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost Crashes after Compiling with Mingw?
"Chris S" <[EMAIL PROTECTED]> writes: > It seems my problem was embarrassingly simple. I forgot to give mingw > the -mthreads switch. Everything seems to run smoothly now. In my defense, I > checked mingw.org for the appropriate documentation regarding threads but > didn't find any info on its command line switches. This is one reason to use Boost.Build. In v2, library specifications can include what are known as "propagated attributes". In other words, you will have threads enabled automatically just by virtue of linking with Boost.Threads. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible love
"Rani Sharoni" <[EMAIL PROTECTED]> writes: > The above code compiled fine with VC7.1 beta but failed to compile using EDG > and GCC. > Here is an explanation for why I think that it's compliant: > > The form of the ctor of ctor_tester is the same as its member t (12.8/5). In > case the ctor argument has const qualifier then both check functions has an > exact match (13.3.3.1.1/3), the first check using Lvalue-transformation and > the second using identity. The ambiguity buster in this case is the > non-template function. > In case that the ctor is not const then the first version is viable using > user defined conversion sequence (like auto_ptr: ctor_tester -> B) and the > second is still identity. > > Overloading is so complex that I have doubts and I'll be happy to ear a > second opinion. Very interesting; I think your explanation is reasonable. Unfortunately, cwpro8.3 also disagrees with you. I spent several hours hacking around with this to make various compilers other than vc7.1 accept it, and failed. Thanks for trying, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible love
"Rani Sharoni" <[EMAIL PROTECTED]> writes: > The above code compiled fine with VC7.1 beta but failed to compile using EDG > and GCC. > Here is an explanation for why I think that it's compliant: > > The form of the ctor of ctor_tester is the same as its member t (12.8/5). In > case the ctor argument has const qualifier then both check functions has an > exact match (13.3.3.1.1/3), the first check using Lvalue-transformation and > the second using identity. The ambiguity buster in this case is the > non-template function. > In case that the ctor is not const then the first version is viable using > user defined conversion sequence (like auto_ptr: ctor_tester -> B) and the > second is still identity. > > Overloading is so complex that I have doubts and I'll be happy to ear a > second opinion. Very interesting; I think your explanation is reasonable. Unfortunately, cwpro8.3 also disagrees with you. I spent several hours hacking around with this to make various compilers other than vc7.1 accept it, and failed. Thanks for trying, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost Crashes after Compiling with Mingw?
It seems my problem was embarrassingly simple. I forgot to give mingw the -mthreads switch. Everything seems to run smoothly now. In my defense, I checked mingw.org for the appropriate documentation regarding threads but didn't find any info on its command line switches. -Chris- - Original Message - From: "William E. Kempf" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.lib.boost.devel Sent: Friday, February 21, 2003 10:05 AM Subject: Re: Boost Crashes after Compiling with Mingw? > > Chris S said: > > I've installed boost's threading library following the build > > instructions in the documentation. I was unable to get bjam to work. No > > matter what I tried it won't accept my include or library paths for > > mingw. However, using Dev-C++, I set up projects using the appropriate > > include and library directories and successfully built both > > libboostthread.a and > > boostthreadmon.dll. > > > > All seemed well until I tried to run the libs/thread/example/thread.cpp > > example. It compiled wonderfully and without error, but segfaults for > > the lines: > > > > boost::thread thrd(alarm); > > thrd.join(); > > > > I'm assuming, while I believe I followed the build instructions > > correctly and received no compilation or linking errors, that the boost > > threading library is not at fault. If so, what might I have done, or not > > done, to cause this problem? > > Actually, I'm fighting GCC/Win32 issues. Cygwin uses POSIX threads, and > the timing facilities seem to be broken. Cygwin with -mno-cygwin and > MinGW use the native Win32 C RTL, but there's issues with TSS not working > which *appears* to stem from the STL libraries not being thread safe (and > I've not had the time to get STLPort to work with the Cygwin/-mno-cygwin > combination that I use). The specific problem you're describing is not > one I've seen, so I'll look into it shortly, but don't be too quick to > assume it's not a fault in Boost.Threads. If anyone can help in solving > these portability issues, I'd appreciate it. > > -- > 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
Re: [boost] Re: [variant] Compiling issues
On Fri, 21 Feb 2003, Eric Friedman wrote: > Ronald Garcia wrote: > > In addition, compiling with Intel C++ 7.0 under strict ansi compliance > > (-ansi) revealed the following nits as well: > [snip] > > I've enclosed patches (unified diffs) for these. > > Are any of these errors severe, hindering you (or others) from review? Or > can fixes wait? > These fixes can wait for me. It appears that most compilers aren't affected (EDG-based compilers only seem to complain in strict moce). Cheers, Ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comeau with Borland backend
"Peter Dimov" <[EMAIL PROTECTED]> writes: > Some Boost libraries test for __BORLANDC__ defined and proceed to use > illegal constructs under the asumption that the compiler is Borland 5.x. > This is wrong. Comeau C++, when using Borland as backend, also defines > __BORLANDC__ (currently as 0x540). > > I have fixed is_pointer and is_reference since they prevented me from > compiling shared_ptr_alloc_test.cpp, but please review your code for other > hidden __BORLANDC__ assumptions. Gack! Do we need a BOOST_BORLAND #define to go with our BOOST_MSVC? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [config] BOOST_NO_AUTO_PTR and msvc6
Beman Dawes <[EMAIL PROTECTED]> writes: > Yes, the problem isn't really "no auto_ptr" but a very specific set of > problems. Maybe you should just say BOOST_OLD_MSVC_AUTO_PTR. > > Anyhow, please add whatever you decide to the docs. For now I'm just relying on BOOST_MSVC_STD_ITERATOR plus a comment. There really doesn't seem much point in littering the config with macros which mean the same thing :-/ -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comeau with Borland backend
Some Boost libraries test for __BORLANDC__ defined and proceed to use illegal constructs under the asumption that the compiler is Borland 5.x. This is wrong. Comeau C++, when using Borland as backend, also defines __BORLANDC__ (currently as 0x540). I have fixed is_pointer and is_reference since they prevented me from compiling shared_ptr_alloc_test.cpp, but please review your code for other hidden __BORLANDC__ assumptions. -- Peter Dimov http://www.pdimov.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] type traits proposal
John Maddock wrote: > > >I think it is much more useful to provide is_class and treat unions as > >classes in this case. Optionally we could add 'is_class_or_union' as > >most compilers are able to implement this even when they cannot provide > >is_class and is_union - and it would IMHO be a shame not to have this > >trait. > > Remember that this is a *temporary* latitude that has been granted - there > is already one compiler (Metrowerks) that does the right thing, and gcc is > likely to follow suite soon, no doubt others will as well. IMO it is better > to have the semantics we want to specified even if it means that we have to > wait a while for it. Which means that you go for compiler-specific stuff to implement it? Or is there some clever standard-conformant way I missed? Anyway, I agree that it's best to get the correct behaviour and to encourage compiler vendors to provide the necessary functionality. > The reason for wanting is_class > to exclude union types is simply that 90%+ of it's usage is to determine > whether a type can be used as a base class or not - and unions can not. Then I'm in the <10% party :) But even if only 10% would need the distinction, that's far to much to justify that is_class would also detect unions. Thus I think the proposal is best as it is now. Regards, Daniel PS: I guess your time is limited - as it seems to be for most people :) - but I just want to make sure you haven't missed it: Somewhere at the end of the ( heated :-9 ) discussion of is_class I proposed a small patch which removes the warnings from the regression tests for the GCC - at least it works for me :). Please consider applying it when you find the time, thanks. -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [config] BOOST_NO_AUTO_PTR and msvc6
At 09:04 PM 2/21/2003, David Abrahams wrote: >David Abrahams <[EMAIL PROTECTED]> writes: > >> The config docs say: >> >>BOOST_NO_AUTO_PTR >> >>Standard library >> >>If the compiler / library supplies non-standard or broken >>std::auto_ptr. >> >> Yet BOOST_NO_AUTO_PTR is not set for MSVC with its standard library, >> in which auto_ptr does not support converting constructors, among >> other major problems. >> >> I'm going to add BOOST_NO_AUTO_PTR for the old dinkumware library; >> Please don't hesitate to let me know if there's a problem with this >> change. > >Argh, that's going to break shared_ptr for a number of users; I think >we need a new config macro (BOOST_BROKEN_AUTO_PTR or something) :-( Yes, the problem isn't really "no auto_ptr" but a very specific set of problems. Maybe you should just say BOOST_OLD_MSVC_AUTO_PTR. Anyhow, please add whatever you decide to the docs. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] type traits proposal
>Looks very good, especially given the fact that compile-failures are >replaced by returning the unmodified type (IIUC :) One thing that may >lead to a slight problem is in the last part: Thanks. >"If there is no means by which the implentation can differentiate >between class and union types, then the class templates is_class and >is_union need not be provided." > >I think it is much more useful to provide is_class and treat unions as >classes in this case. Optionally we could add 'is_class_or_union' as >most compilers are able to implement this even when they cannot provide >is_class and is_union - and it would IMHO be a shame not to have this >trait. Remember that this is a *temporary* latitude that has been granted - there is already one compiler (Metrowerks) that does the right thing, and gcc is likely to follow suite soon, no doubt others will as well. IMO it is better to have the semantics we want to specified even if it means that we have to wait a while for it. Users can always add their own is_class_or_union as a negation of all the other primary traits. The reason for wanting is_class to exclude union types is simply that 90%+ of it's usage is to determine whether a type can be used as a base class or not - and unions can not. >And for the unimportant part: Is "boolian" correct or should it be >"boolean"? Yes it should, thanks. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [variant] 2 or more types requirement
"Ronald Garcia" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hi, > > In reading through the variant docs, I noticed a requirement that at least > two types must be supported by the variant. Is this meant for ease of > library implementation, or is this a means of protecting programmers from > themselves? :-) > The latter: The rationale was that a developer is better off with handling a single value directly, rather than wrapping it inside a variant. > It may not make sense for a human programmer to instantiate a variant > with one value in it, but I can picture situations where a code generator > might create a variant of only one type. Handling this as a > special case can be tedious -- I have had related problems in the past > generating structs of zero elements in C. Even when a human programmer is > involved, one might prefer the clarity of a consistent implementation > style over the performance gain of special casing. These situations might > be worth considering. > I agree with you. This is all about sound "code engineering": A mechanism may start with a single type but may need to support more and more types as time go by. As it stands now, you will have to start with two types. This is a good point. Thanks. -- Itay Maman [EMAIL PROTECTED] [EMAIL PROTECTED] This message expresses my personal opinion. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
