[boost] Re: Boost.dynamic_any vs Boost.Function
Douglas Paul Gregor wrote: On Tue, 18 Feb 2003, Alexander Nasonov wrote: With a help of boost::dynamic_any::call operation (not yet implemented) it's possible to use boost::dynamic_any::any instead of Boost.Function. Though this new solution is less specialized and probably slower then Boost.Function it has one advantage demonstrated in the example below: typedef boost::dynamic_any boost::mpl::list boost::dynamic_any::callvoid (int ), boost::dynamic_any::callvoid (double ) flexible_function; // 2 in 1! That's great! 'Tis a good week for dynamic polymorphism. There is the same code bloat problem as in early Boost.Function release. Unfortunately, I have to use polymorphic classes to store a value because they are essential parts of extraction mechanism. So, I can only recommend to use this feature only when it's _really_ necessary. -- Alexander Nasonov Remove - m y c o p from my e-mail address for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Peter Dimov wrote:
The other option is to support a dynamic_cast-style extract:
T * p = extractT*(var);
T r = extractT(var);
but it would likely require partial ordering/specialization.
I don't have access to a compiler with broken partial
ordering/specialization but I tried to keep it in mind when I implemented
extraction for dynamic_any. This code fragment is taken from
dynamic_any/any.hpp. Start reading from the bottom.
// T is not a class.
templateclass T
const T * extract_const_ptr(const placeholder * p, bool_idfalse)
{
if(p == 0 || p-type(sig()) != typeid(T))
return 0;
typedef const nonclass_holderT holder_type;
holder_type * ptr = static_castholder_type *(p);
return ptr-value;
}
// T is a class.
templateclass T
const T * extract_const_ptr(const placeholder * p, bool_idtrue)
{
return dynamic_castconst T *(p);
}
templateclass T
const T * extract_const_ptr(const placeholder * p, type_idconst T)
{
bool_id ::boost::is_classT::value id;
return extract_const_ptrT(p, id);
}
// T is not a class.
templateclass T
T * extract_nonconst_ptr(placeholder * p, bool_idfalse)
{
if(p == 0 || p-type(sig()) != typeid(T))
return 0;
typedef nonclass_holderT holder_type;
holder_type * ptr = static_castholder_type *(p);
return ptr-value;
}
// T is a class.
templateclass T
T * extract_nonconst_ptr(placeholder * p, bool_idtrue)
{
return dynamic_castT *(p);
}
templateclass T
T * extract_nonconst_ptr(placeholder * p, type_idT)
{
bool_id ::boost::is_classT::value id;
return extract_nonconst_ptrT(p, id);
}
// T is const.
templateclass T
T * extract_ptr(const placeholder * p, bool_idtrue)
{
return extract_const_ptr(p, type_idT());
}
// T is not const.
templateclass T
T * extract_ptr(placeholder * p, bool_idfalse)
{
return extract_nonconst_ptr(p, type_idT());
}
// Placeholder is 'placeholder' or 'const placeholder'.
templateclass T, class Placeholder
T * extract_ptr(Placeholder * p)
{
bool_id ::boost::is_constT::value id;
// Note to users: if you get compile error here then you are trying
// to extract non-const pointer or reference from const 'any'.
return extract_ptrT(p, id);
}
templateclass T, class Placeholder
T extract_ref(Placeholder * p, type_idT )
{
if(T * ptr = extract_ptrT(p))
return *ptr;
throw bad_extract();
}
// T is a reference.
templateclass T, class Placeholder
T extract(Placeholder * p, bool_idtrue)
{
return extract_ref(p, type_idT());
}
// T is not a reference.
templateclass T, class Placeholder
T extract(Placeholder * p, bool_idfalse)
{
return extract_ref(p, type_idconst T ());
}
templateclass T, class Placeholder
T extract(Placeholder * p)
{
bool_id ::boost::is_referenceT::value id;
return extractT(p, id);
}
--
Alexander Nasonov
Remove -mycop from my e-mail address for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Encapsulate boost::bind in a template method
Hi
It won't compile because you're trying to bind a (CButton::*)() function to
CWindow*. See bjarne 15.5.1
Change the line marked to
boost::functionlong EventFunction = boost::bind(Function,
static_castT*(this));
Or you could use dynamic_cast to check that the cast is valid:
if (T* that = dynamic_castT*(this))
{
boost::functionlong EventFunction = boost::bind(Function, that);
}
Though you can make this less of a problem if you declare your handler
functions private, so that you are less likely to be able to pass duff
member function pointers. e.g.
class CWindow
{
// as before
};
class CWindowA : public CWindow
{
private:
long OnPaint();
};
class CWindowB : public CWindow
{
public:
CWindowB()
{
SetEventHandler(CWindowA::OnPaint); // won't compile now, as
CWindowA::OnPaint is inaccessible
}
private:
long OnPaint();
};
I think I would then be happy to use boost::polymorphic_downcast
(http://www.boost.org/libs/conversion/cast.htm)
HTH
Sam
PS I havn't checked the code, so apologies for any typos
- Original Message -
From: Matthias Hoffrichter
To: [EMAIL PROTECTED]
Sent: Wednesday, February 19, 2003 3:56 AM
Subject: [boost] Encapsulate boost::bind in a template method
Hi,
I want to encapsulate boost::find in a template method in a base class for
easier use.
Here is some code:
#include boost/function.hpp
#include boost/bind.hpp
class CWindow {
public:
CWindow() {
SetEventHandler(CWindow::OnCreate); // this call works
}
long OnCreate() {
return 0;
}
templatetypename T void SetEventHandler(long (T::*Function)()) {
**
boost::functionlong EventFunction = boost::bind(Function, this);
// ...
// Add EventFunction into a std::map
}
};
class CButton : public CWindow {
public:
CButton() {
SetEventHandler(CButton::OnPaint); // this call doesn't compile
}
long OnPaint() {
return 0;
}
};
int main() {
return 0;
}
The SetEventHandler call in the CButton's constructor generates 2 errors on
VC++ 7.0:
mem_fn_template.hpp(37): error C2440: 'newline' : 'CWindow *' can't be
converted in 'CButton *'
mem_fn_template.hpp(37): error C2647: '-*' : 'const
boost::_mfi::mf0R,T::F' can't be dereferenced in '$T'
It also doesn't compile on g++ 3.2.
If I copy paste the template method in every derived class the code
compiles well, but this can't be a good soluation. :(
And if i outcomment boost::functionlong EventFunction it also works, but
of course I need to work with boost::bind's return value. ;-)
Is there a way to solve this problem?
cu,
Matthias
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: datetime and long long
David Abrahams wrote:
Jeff Garland [EMAIL PROTECTED] writes:
Many of the regression tests for the date time library are
failing currently because the library relies on std::abslong
long being available. AKAIK, the C++ standard doesn't require
this so the library shouldn't make use of it.
Maybe datetime should specify it's own version of abs like
this:
#include cstdlib
#include stdlib.h
template typename T T abs(T i) { return std::abs(i); }
template long long abs(long long i) {return ::llabs(i); }
Take a look at bosot/date_time/compiler_config.hpp which does
something similar. All we need to do to fix these regressions is
add the compiler to the list of those that don't have std::abs at
line 34. Turns out that some compilers that support long long do
define a version of abs for long long. (I'm sure you also know
that some compilers don't call it the type long long either which
is why we have boost::int64_t).
Just as an aside, at some point this logic should likely move out
of date_time and into the general config somewhere so that others
can access std::abs on these types if they need.
AFAICT the logic is backwards: you should assume there's no
std::abs which works on long long and use your own function by
default, only using std::abs if the compiler is *known* to support
that extension... if it's even worth the trouble (it'll be less
code to just do the whole thing yourself).
Looks like there a two cases which would need two macros.
- BOOST_NO_STD_ABS identifies that no std::abs is available.
- BOOST_HAS_STD_ABS_LONG_LONG identifies that the compiler provides a
long long overload for std::abs.
Those macro names follow the general macro naming convention, I think.
The easiest thing would probably be to just say
namespace whatever { inline template class T T abs(T) { ... } }
and use this, as Dave suggested.
Markus
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Gennadiy Rozental wrote: Mutex locking is a simple example of resource management idiom. All flavors of resource management are easily implemented in terms of policy based smart pointers (don't allow name to confuse you). In this particular case most probably all that you need is a custom StoragePolicy. Now you can enjoy all the variety of ownership policies supplied with smart_ptr or design your own for very specific needs. To use an old English idiom, I think you are putting the cart before the horse [as did Modern C++ Design, IMNSHO] Resource protection is a useful concept, and pointers are simply another resource that needs protecting. It makes little sense to dereference a mutex, for instance. This is one of the defining concepts of a pointer. Rather, I think if we seek a generic implementation the 'base' concept is resource protection, and smart pointers are a refinement of this concept. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Mutex locking is a simple example of resource management idiom. All flavors of resource management are easily implemented in terms of policy based smart pointers (don't allow name to confuse you). In this particular case most probably all that you need is a custom StoragePolicy. Now you can enjoy all the variety of ownership policies supplied with smart_ptr or design your own for very specific needs. To use an old English idiom, I think you are putting the cart before the horse [as did Modern C++ Design, IMNSHO] Resource protection is a useful concept, and pointers are simply another resource that needs protecting. It makes little sense to dereference a mutex, for instance. This is one of the defining concepts of a pointer. Rather, I think if we seek a generic implementation the 'base' concept is resource protection, and smart pointers are a refinement of this concept. First of all let me emphasize that it seems that we agree that this kind of task require some generic component based implementation. Now about the order. smart_ptr checking policy allows prohibit at compile time using of operator* or operator-, effectively removing them from public interface on the resource manager class. On the other hand in some cases we need to provide an access to managed resource (for example to call methods of it). Aforementioned operators could be very handy in this case. So I don't think that smart_ptr interface does not fit for the purpose of generic resource manager. In any case it's details of implementation, that we may discuss during pbsp review. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Lock Classes: Does anyone care.
In that fashion it makes sense. But the only smart_ptr that will make any sense is scoped_ptr. Which will only implement idea #1. As I said my classes offer far more. Under smart_ptr I meant policy pased smart pointer, that supply a wide variaty of ownership policies and allow you to write custom one. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread-Local Storage (TLS) and templates
From: Steve Clamage [EMAIL PROTECTED] To: C++ core language mailing list Message c++std-core-9820 Some compilers implement thread-local storage (TLS) for what would otherwise be global variables. The compiler and runtime system arrange for each thread to see its own copy of a global variable. As I understand it, TLS on Windows is just a fancy wrapper around a pointer. The thread-local slots are addressed relative to some register that the OS sets up for each thread. So in... extern int k; int i = k; ...if k is thread-local, k is an offset that must be dereferenced with respect to the current thread. I see a fairly good analogy with pointers to members. extern int __thread_context::* pmk; // a TLS variable int i = __thread-*pmk; The only differences are that you don't need to write __thread-* and that TLS variables are pointers to references. In implementation terms, pmk is a compile-time constant, so I think it could be an acceptable template parameter. On the other hand, the code required to extract the integer value is different from the code required to dereference a normal variable. On the third hand, compilers supporting TLS already face this problem when I write... __declspec(thread) int k; int* pk = k; ...and I don't think being a template parameter adds anything new. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Repost: Borland related patches
Beman Dawes wrote: In the meantime, for people who submitted patches in the last couple of weeks, you might want to check that the patches were either made or rejected, rather than just missed in the last minute rush. Please post a reminder if they appear to have been forgotten. I submitted the following patches over the last few weeks that may have been lost: [Note: I am now using a proposed new defect-detection macro, BOOST_NO_STATIC_CONST_AS_TEMPLATE_PARAM, currently only defined for borland =0x0570] cvs diff borland.hpp (in directory C:\Projects\3rdParty\boost\boost\config\compiler\) Index: borland.hpp === RCS file: /cvsroot/boost/boost/boost/config/compiler/borland.hpp,v retrieving revision 1.17 diff -r1.17 borland.hpp 34a35 # define BOOST_NO_STATIC_CONST_AS_TEMPLATE_PARAM Random library [also fixes Graph library test] cvs diff uniform_smallint.hpp Index: uniform_smallint.hpp === RCS file: /cvsroot/boost/boost/boost/random/uniform_smallint.hpp,v retrieving revision 1.20 diff -r1.20 uniform_smallint.hpp 190a191,192 #elif defined( BOOST_NO_STATIC_CONST_AS_TEMPLATE_PARAM ) typedef typename detail::uniform_smallint boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; cvs diff uniform_int.hpp Index: uniform_int.hpp === RCS file: /cvsroot/boost/boost/boost/random/uniform_int.hpp,v retrieving revision 1.21 diff -r1.21 uniform_int.hpp 208a209,210 #elif defined( BOOST_NO_STATIC_CONST_AS_TEMPLATE_PARAM ) typedef typename detail::uniform_int boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; Fix for tuple_io test: [I am proposing a more general boost-config workaround for this and related borland bugs, but no defect-detection macro yet] cvs diff tuple_io.hpp (in directory C:\Projects\3rdParty\boost\boost\tuple\) Index: tuple_io.hpp === RCS file: /cvsroot/boost/boost/boost/tuple/tuple_io.hpp,v retrieving revision 1.7 diff -r1.7 tuple_io.hpp 440a441,442 #elif defined ( __BORLANDC__ ) const bool is_delimiter = !std::use_facet std::ctype CharType ( is.getloc() ).is( std::ctype_base::space, d); 442c444 const bool is_delimiter = (!std::isspace(d, is.getloc()) ); --- const bool is_delimiter = (!std::isspace(d, is.getloc()) ); I have applied BOOST_NO_STATIC_CONST_AS_TEMPLATE_PARAM in several other places, but at the moment this only shows up 'the next error'. I am holding further investigations back until after release 1.30. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Repost: Borland related patches
Alisdair Meredith wrote: [Note: I am now using a proposed new defect-detection macro, BOOST_NO_STATIC_CONST_AS_TEMPLATE_PARAM, currently only defined for borland =0x0570] Did you try to define BOOST_NO_INCLASS_MEMBER_INITIALIZATION for borland? This will toggle BOOST_STATIC_CONSTANT to use the enum workaround and might fix most of the problems you are having with BCC not allowing static constant members as integral constant expressions in template parameters. This trick is used in the Visual Age toolset. Markus ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Tue, 18 Feb 2003 19:14:50 +0200, Rani Sharoni
[EMAIL PROTECTED] wrote:
This is very nice technique. Just notice that you also need to handle void,
functions and arrays types.
Abstract classes, functions and array types will fail the completion on the
burn conversion operator since they are not allowed as returns types.
Yeah. The code was just to give the idea, which I could have expressed
in English if it wasn't that my English is even worse than my C++ :-)
IMHO the main achievement of your technique is that, unlike techniques that
use conversion constructor to burn user defined conversion, its works for
incomplete classes (EDG and GCC complain when trying to pass lvalue of
incomplete class to function that take ellipsis as an argument).
Yes. Attempting lvalue-to-rvalue conversion of an expression of
incomplete type makes the program ill-formed.
Here is a possible is_enum implementation using your technique:
templatetypename T struct convertible { operator T() const; };
templatetypename T
struct is_enum2
{
static yes test(int);
static no test(...);
struct not_enum {};
typedef typename select_type is_fundamentalT::value ||
is_referenceT::value, not_enum, convertibleT ::type T2;
static T2 make();
};
templatetypename T
struct is_enum
{
enum { value = sizeof(is_enum2T::test(is_enum2T::make())) ==
sizeof(yes) } ;
};
Nice :-) BTW, you can avoid the select_type machinery:
template typename T
struct Burn {
operator T() const;
};
// fire-prevention
template typename T
BurnT ref(T*);
template typename T
char* ref(...);
// outside the is_enum template
// to help gcc
//
yes is_enum_checker (unsigned long);
no is_enum_checker (...);
template typename T
struct is_enum {
static const bool value =
!is_integralT::value
!is_floatingT::value
sizeof(yes) == sizeof( is_enum_checker (refT(0)) );
};
But this simple stuff is already enough to knock out a lot of
compilers :-/
BTW, I've seen how complex boost::is_reference is. Why so? What
compiler(s) cause(s) most problems?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Lock Classes: Does anyone care.
Are you, or are you not interested in my Lock Classes. The messages I got from you is that you are only interested in my lock classes if 1) It is reproposed as an extension to the locking mechanism in Boost thread. and/or 2) It is reworked to somehow be an extension of the smart pointer concept, even though it has very little relation to smart pointers. I have got very little indication that you actually looked at what my classes are offering. I am not trying to be sarcastic here. I generally don't know what your intentions are. -- http://kevin.atkinson.dhs.org ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: datetime and long long
Dave A. wrote:
AFAICT the logic is backwards: you should assume there's no
std::abs which works on long long and use your own function by
default, only using std::abs if the compiler is *known* to support
that extension... if it's even worth the trouble (it'll be less
code to just do the whole thing yourself).
Point taken.
Markus S. wrote:
Looks like there a two cases which would need two macros.
- BOOST_NO_STD_ABS identifies that no std::abs is available.
- BOOST_HAS_STD_ABS_LONG_LONG identifies that the compiler provides a
long long overload for std::abs.
Those macro names follow the general macro naming convention, I think.
The easiest thing would probably be to just say
namespace whatever { inline template class T T abs(T) { ... } }
and use this, as Dave suggested.
I think I'm inclined to take Dave's last suggestion, rename
the template function and remove all the macros.
Jeff
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for dynamic_bitset
On Tue, 18 Feb 2003 12:06:51 +0100, Markus Schöpflin [EMAIL PROTECTED] wrote: Hi there, currently, dynamic bitset tests fail for VA6 because the library doesn't correctly detect that a standard compliant allocator is available. Therefore I propose the attached patch to be applied to boost/detail/dynamic_bitset.hpp. The patch uses BOOST_NO_STD_ALLOCATOR to check if a workaround is needed. It only tries to use the workaround if BOOST_NO_STD_ALLOCATOR is defined. Seems like the main branch hasn't been updated: the 1.29.0 version doesn't have the #if anymore. BTW, the error messages at http://boost.sourceforge.net/regression-logs/cs-AIX-links.html clearly show that a candidate with two parameters does exist. Is it really an allocator conformance issue or rather a compiler bug? Does this allocate(calc_num_blocks(num_bits), static_castconst Block *(0)) compile? Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Kevin Atkinson wrote:
[...]
I have got very little indication that you actually looked at what my
classes are offering.
Uhmm. Original-To aside, your Mutex class offers undefined behavior;
you really can NOT replicate a {pthread_mutex_t} mutex. I'm not sure
about the rest of your classes, though. Well, but you might want to
take a look at:
http://groups.google.com/groups?selm=3D6CC476.634175AB%40web.de
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Lock Classes: Does anyone care.
Gennadiy Rozental [EMAIL PROTECTED] wrote in message b2v2p5$6ad$[EMAIL PROTECTED]">news:b2v2p5$6ad$[EMAIL PROTECTED]... 1. Does not Boost.Thread already have locking mechanisms The only thing boost threads offer is #1 on my list, that is The ability to acquire a lock and release it when the object goes out of scope effectively implemented the Monitor concept. Implementing this idea is rather easy and obvious. It is the other things my classes offer that make it interesting. The differences should be obvious. In any case it should be part of Boost.Thread IMO. You may propose your classes as an extension to existent Boost.Thread functionality. I think the question that needs to be answered is if locking mechanisms have any use outside of threading models. If so, a library of locking mechanisms should be separated from the thread library although the thread library certainly can use it. If not, then locking functionality should be folded into the thread library. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
I have got very little indication that you actually looked at what my
classes are offering.
Uhmm. Original-To aside,
What does that mean?
your Mutex class offers undefined behavior;
you really can NOT replicate a {pthread_mutex_t} mutex.
Where do I replicate a mutex? I maintain a *pointer* to the Mutex class
which holds the actual Mutex, which can not be copied.
--
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman wrote: Peter Dimov wrote: [...] template class T, ... T extract(variant... operand); template class T, ... T const extract(variant... const operand); template class T, ... T * extract(variant... * operand); template class T, ... T const * extract(variant... const * operand); it's no longer ambiguous. I believe it is. The following (admittedly silly) example fails to compile under Comeau: // -- BEGIN CODE EXAMPLE -- template class T, class Extractable T extract(Extractable operand); template class T, class Extractable T const extract(Extractable const operand); template class T, class Extractable T * extract(Extractable * operand); template class T, class Extractable T const * extract(Extractable const * operand); This is not what I wrote above. The other option is to support a dynamic_cast-style extract: T * p = extractT*(var); T r = extractT(var); but it would likely require partial ordering/specialization. I've thought about this, but I think it would introduce significant confusion among users. For instance: variantchar, char* v; char c = extractchar(v); // ok... check for and either throw or extract char char* c = extractchar*(v); // check for and either return null or extract: char? or char*? Compile-time error, pointer syntax needs a pointer to the variant, consistent with dynamic_cast and any_cast: char* c = extractchar*(v); Even though the statement is well-defined (extract char) under your proposed syntax, I imagine many nonetheless would read the second line as extraction of char* from v. (While in fact it would extract char from v.) Yes, it's possible to misread it. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
I have got very little indication that you actually looked at what my
classes are offering.
Uhmm. Original-To aside,
What does that mean?
your Mutex class offers undefined behavior;
you really can NOT replicate a {pthread_mutex_t} mutex.
Where do I replicate a mutex? I maintain a *pointer* to the Mutex class
which holds the actual Mutex, which can not be copied.
I'm sorry. It turns out that I neglected to make the actual Mutex
uncopyable. However, that does not change the fact that I never actually
make a copy of pthread_mutex_t. To make sure I just made the Mutex
uncopyable and recompiled the example with out any errors.
--
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread-Local Storage (TLS) and templates
Ken Hagan wrote: [...] In implementation terms, pmk is a compile-time constant, so I think it could be an acceptable template parameter. On the other hand, the code required to extract the integer value is different from the code required to dereference a normal variable. On the third hand, compilers supporting TLS already face this problem when I write... __declspec(thread) int k; int* pk = k; ...and I don't think being a template parameter adds anything new. k does not exist yet at compile-time (in a pointer to int form), when templates are instantiated. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review or Variant Library (Ed B.)
Peter Dimov [EMAIL PROTECTED] writes: Joel de Guzman wrote: David Abrahams wrote: BTW, I just realized that a conversion from variantT to optionalT could be used to do extraction as well. Maybe it would be better to ditch extract altogether and just use optional? I think this makes sense. The disadvantage is the overhead of optional just to do extraction. That means an extra copy Really? You can't convert to an optionalT? and inability to change that data held in the variant using non-const extract. Same question applies. If we really need to go that route, it's probably better to just make extract return a value. I'm confused. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: datetime and long long
Thanks Jeff. All tests but one now pass for VA! testmicrosec_time_clock fails for VA6 with one single failure out of 150. It works ok for VA5, though... It might be a spurious failure. As you can imagine testing clock measurements is a bit dicey. That particular test takes a bunch of measurements from the clock and makes sure that they progessively increase -- it is possible that the one failure is ok. I'll look when you post the results. Anyway, this high resolution clock is still an experimental feature until I'm happy with the portability, so the real news is that the library should be good to go on VA now :-) Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Thread-Local Storage (TLS) and templates
Peter Dimov wrote: k does not exist yet at compile-time (in a pointer to int form), when templates are instantiated. It doesn't have to. We're instantiating a template, not calling a function, so if k has the type pointer to thread-local int then the compiler knows that and can instantiate the appropriate code. One might insist that the addresses of TLS data be qualified (like __near and __far on the old 8086 boxen) and template authors would have to declare up front which type of pointer they were expecting. This would be a break with existing practice and the only benefit would be that one could declare functions (not templates) that expected a thread-relative pointer. I don't think this is worth it. Twenty years ago, being able to declare a DS-relative pointer *was* worth it, since the speed-up outweighed the inconvenience of all those qualifiers. For TLS, unless we go mad and make most of our application data thread-local (!), the convenience of mixing and matching is more valuable than the expressiveness. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Encapsulate boost::bind in a template method
Matthias Hoffrichter wrote:
Hi,
I want to encapsulate boost::find in a template method in a base
class for easier use.
Here is some code:
#include boost/function.hpp
#include boost/bind.hpp
class CWindow {
public:
CWindow() {
SetEventHandler(CWindow::OnCreate); // this call works
}
long OnCreate() {
return 0;
}
templatetypename T void SetEventHandler(long (T::*Function)()) {
boost::functionlong EventFunction = boost::bind(Function, this);
// ...
// Add EventFunction into a std::map
}
};
class CButton : public CWindow {
public:
CButton() {
SetEventHandler(CButton::OnPaint); // this call doesn't compile
}
long OnPaint() {
return 0;
}
};
In CWindow::SetEventHandlerCButton, 'this' is a CWindow*. You can't invoke
CButton::OnPaint using a pointer to CWindow.
The easiest solution is probably to make SetEventHandler a free function:
templateclass F, class T void setEventHandler(F f, T * p)
{
boost::functionlong EventFunction = boost::bind(f, p);
// ...
// Add EventFunction into a std::map
}
and then simply use setEventHandler(CButton::OnPaint, this) in
CButton::CButton().
You'll soon find that this is not _that_ easier to use compared to
setEventHandler(bind(CButton::OnPaint, this));
and the latter is much more flexible:
setEventHandler(bind(CButton::OnMessage, this, WM_PAINT));
but that's another story. :-)
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Peter Dimov [EMAIL PROTECTED] wrote in message 00d901c2d820$bd2225c0$1d00a8c0@pdimov2">news:00d901c2d820$bd2225c0$1d00a8c0@pdimov2... David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: Joel de Guzman wrote: David Abrahams wrote: BTW, I just realized that a conversion from variantT to optionalT could be used to do extraction as well. Maybe it -^ would be better to ditch extract altogether and just use optional? I think this makes sense. The disadvantage is the overhead of optional just to do extraction. That means an extra copy Really? You can't convert to an optionalT? You said optionalT above. It may be possible to use optionalT (is it supported?) No, it isn't. And I don't think it ever will. optionalX intends to represent a value of type X wich is possiblly uninitialized. But you can't have X=T since you can't have an uninitialized reference. Of course, optionalT could have a special meaning, but I can't see what would it be. What's the meaning of an optional reference? I think there cannot be such a thing. or optional reference_wrapperT but this looks like an obfuscated C++ entry to me compared to T*. What's wrong with it? What does optionalT add? Exactly. An optional reference is almost like a possibly null pointer, except that references must be bounded. If given a particular design you would need optionalT, then you definitely need T* instead. -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review or Variant Library (Ed B.)
Peter Dimov [EMAIL PROTECTED] writes: You said optionalT above. Do what I mean, not what I say ;-) It may be possible to use optionalT (is it supported?) or optional reference_wrapperT but this looks like an obfuscated C++ entry to me compared to T*. Good point. What's wrong with it? What does optionalT add? Suppose you have a variantmpl::listint, std::string How do you check to see if it contains an int? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
I have got very little indication that you actually looked at what my
^^^
classes are offering.
Uhmm. Original-To aside,
What does that mean?
That means that I've figured out whom do you mean...
Original-To: Gennadiy Rozental [EMAIL PROTECTED]
...from the Original-To-in-the-headers-to-your-posting-here.
your Mutex class offers undefined behavior;
you really can NOT replicate a {pthread_mutex_t} mutex.
Where do I replicate a mutex?
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
class Mutex {
pthread_mutex_t l_;
public:
Mutex() : l_(MUTEX_INIT) {}
^^
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Thread-Local Storage (TLS) and templates
Ken Hagan wrote:
Peter Dimov wrote:
k does not exist yet at compile-time (in a pointer to int form),
when templates are instantiated.
It doesn't have to. We're instantiating a template, not calling a
function, so if k has the type pointer to thread-local int then
the compiler knows that and can instantiate the appropriate code.
Indeed it can, and it (MSVC 7.1b) even does. I stand corrected.
#include iostream
#include typeinfo
#include windows.h
#include process.h
#include boost/detail/lightweight_mutex.hpp
typedef boost::detail::lightweight_mutex mutex_type;
mutex_type m;
templateuintptr_t * p struct C
{
void f()
{
std::cout p: p : *p std::endl;
}
};
__declspec(thread) uintptr_t k = 0;
unsigned __stdcall f(void * pt)
{
k = *(uintptr_t *)pt;
mutex_type::scoped_lock lock(m);
Ck ck;
ck.f();
std::cout k: k : k std::endl;
return 0;
}
int main()
{
uintptr_t t1 = _beginthreadex(0, 0, f, t1, 0, 0);
uintptr_t t2 = _beginthreadex(0, 0, f, t2, 0, 0);
uintptr_t t3 = _beginthreadex(0, 0, f, t3, 0, 0);
::Sleep(250);
::CloseHandle((HANDLE)t1);
::CloseHandle((HANDLE)t2);
::CloseHandle((HANDLE)t3);
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review or Variant Library (Ed B.)
Eric Friedman wrote:
Ed Brey wrote:
Please consider incorporating a blank type. This idea
would be to allow the equivalent of void to be added to the
type list. boost::blank (or whatever it would be called)
would be meet BoundedType concept, but otherwise do nothing.
The empty function would return true if a blank is currently stored.
This is an interesting idea. It may even be possible to implement
variant to detect a void type so that the following would be allowed:
variant T1, ... void, ... Tn
In the case of a variant containing void, empty() would return true,
and visitation would be undefined.
I'd be interested if others have opinions on this issue.
Supporting void as the first argument would also allow variants where none
of the types is DefaultConstructible. It is possible to fake that with
struct void_t {}; of course, but special-casing void may be clearer.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Suppose you have a variantmpl::listint, std::string AFAICT references are not supported by variant either. But if it were.. How do you check to see if it contains an int? But extracting (or accessing, or peeking) (int)*. Generally speaking, having a way to get a T* which can possibly be NULL. (T in this case is int) -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal review or Variant Library (Ed B.)
Fernando Cacciola [EMAIL PROTECTED] writes: Peter Dimov [EMAIL PROTECTED] wrote in message 00d901c2d820$bd2225c0$1d00a8c0@pdimov2">news:00d901c2d820$bd2225c0$1d00a8c0@pdimov2... David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: Joel de Guzman wrote: David Abrahams wrote: BTW, I just realized that a conversion from variantT to optionalT could be used to do extraction as well. Maybe it -^ would be better to ditch extract altogether and just use optional? I think this makes sense. The disadvantage is the overhead of optional just to do extraction. That means an extra copy Really? You can't convert to an optionalT? You said optionalT above. It may be possible to use optionalT (is it supported?) No, it isn't. And I don't think it ever will. optionalX intends to represent a value of type X wich is possiblly uninitialized. But you can't have X=T since you can't have an uninitialized reference. Sorry, that's a broken analogy. You also can't have an uninitialized object of non-POD class type U, but you allow optionalU. Of course, optionalT could have a special meaning, but I can't see what would it be. What's the meaning of an optional reference? I think there cannot be such a thing. The same as an optional std::string. Either you have one, or you don't. or optional reference_wrapperT but this looks like an obfuscated C++ entry to me compared to T*. What's wrong with it? What does optionalT add? Exactly. An optional reference is almost like a possibly null pointer, except that references must be bounded. If given a particular design you would need optionalT, then you definitely need T* instead. I've my doubts. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any, Function, and Signals documentation
Beman Dawes said: At 11:56 AM 2/18/2003, William E. Kempf wrote: Well, I'm in favor of that, since we're moving at least some of the documentation to Boost.Book with this release (or so I gathered). So what's the group opinion on this one? I'd like to hold off as many changes as possible until after the release. I don't have time to think clearly about the problems involved, and I'd like to actually try out some of the software too. The final day or two before a branch-for-release isn't a good time for this important discussion. Sorry, I do agree strongly with this and didn't mean to imply we should rush moving the tools in before this release. But since some of the documentation for this release will be (it seems) generated documentation, I think we should move the tools in very shortly after release. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for dynamic_bitset
On Wed, 19 Feb 2003 14:33:31 +0100, Markus Schöpflin [EMAIL PROTECTED] wrote: You are right, it's a conformance problem with VA6, at least on my installation. But the fix on the 1.29.0 branch should work. Could you please merge it to the main trunk? Well, I think that's up to Jeremy or Chuck who are the authors of the library. Anyhow, I'm not sure we have understood each other (maybe party the fact I talked about main branch instead of main trunk, sorry): the version shipped with boost 1.29.0 has no conditionals around the calls to allocate(): it simply passes the second argument explicitly. It was a deliberate goal to have a version that did work _and_ didn't have #if-s (I would have eliminated the #if-s that were there before, even if they weren't incorrect: too annoying when reading the code, in any case). Visual Age 6 doesn't like that either, but of course I would still prefer keeping the code without the conditionals. That's why I asked if changing the type of the second argument with: allocate(calc_num_blocks(num_bits), static_castconst Block *(0)) fixes the problem. Otherwise I think I will use some helper macro, like: #if ... #define BOOST_STD_ALLOCATOR_DEFAULT_HINT\ static_castconst void*(0) #else... #define BOOST_STD_ALLOCATOR_DEFAULT_HINT /**/ #endif in a config file. Anyway, all this just refers to the sandbox (where there's by the way a much newer version of dynamic_bitset): changes to the main cvs repository, especially those going into a release, better have the authors' approval. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Encapsulate boost::bind in a template method
On Wednesday 19 February 2003 09:37 am, Peter Dimov wrote:
You'll soon find that this is not _that_ easier to use compared to
setEventHandler(bind(CButton::OnPaint, this));
and the latter is much more flexible:
setEventHandler(bind(CButton::OnMessage, this, WM_PAINT));
but that's another story. :-)
... and if you decide to go down that road, you'll likely want to write
setEventHandler like this:
void setEventHandler(const boost::function0long handler)
{
// add event handler to std::map
}
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
That means that I've figured out whom do you mean...
Original-To: Gennadiy Rozental [EMAIL PROTECTED]
...from the Original-To-in-the-headers-to-your-posting-here.
Oh sorry. I really hate forced reply-to. The message was directed at
Gennadiy Rozental but I CCed it to the boost mailing list.
Kevin Atkinson wrote:
your Mutex class offers undefined behavior;
you really can NOT replicate a {pthread_mutex_t} mutex.
Where do I replicate a mutex?
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
class Mutex {
pthread_mutex_t l_;
public:
Mutex() : l_(MUTEX_INIT) {}
^^
I believe this behavior is well defined. PTHREAD_MUTEX_INITIALIZE is a
const initializer. Unfortunately for Linux threads it is defined as a
traditional C struct initializer, { ... }. So
l_(PTHREAD_MUTEX_INITIALIZER) will not work. Thus I simply make a copy of
it in MUTEX_INIT and use that constant to initialize l_. If it is not
specifically allowed in the POSIX standard it should be. I can not think
of a situation where this will cause a problem. If i was assigning
MUTEX_INIT to an active mutex then yes that would be bad, but I am not
here as I am simply initializing it.
If it bothers you I can use a less efficient initializer:
Mutex() {pthread_mutex_init(l_, 0);}
But this may involve a function call.
---
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Edward Diener wrote: I think the question that needs to be answered is if locking mechanisms have any use outside of threading models. Yes they do. For example when accessing memory shared between separate process. Also, locks can also be used when accessing files. In fact I believe Win32 always uses read/write locks when opening files, on POSIX systems the locks are completely optional but still there. Basically locks can be used when ever accessing a shared resource. If so, a library of locking mechanisms should be separated from the thread library although the thread library certainly can use it. If not, then locking functionality should be folded into the thread library. My classes can be implemented on top of any basic locking primitives, no matter what type of lock or what it is locking. Although it will generally be used for in multi-threaded applications, I am sure someone will find a way to use them for other types of locks. --- http://kevin.atkinson.dhs.org ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Thread-Local Storage (TLS) and templates
Ken Hagan [EMAIL PROTECTED] writes: | Peter Dimov wrote: | | k does not exist yet at compile-time (in a pointer to int form), when | templates are instantiated. | | It doesn't have to. We're instantiating a template, not calling a | function, so if k has the type pointer to thread-local int then | the compiler knows that and can instantiate the appropriate code. The issue here is the *value* k, not the type of that expression. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Sunpro compilation problems with current main CVS snapshot.
I have terrible experiences from the release 1.29.0
version of Boost and the Sun 5.3 compiler. It seems that the Sun compiler has
problems compiling most of the boost libraries even with all the available public
patches. Since the release of 1.29.0 of Boost a lot has happened in the cvs repository,
so it seems. I decided therefore to take a snapshot of the current state of the
main branch of Boost. To my satisfaction quite a lot of the error and
compilation problems I had earlier encountered were gone. Good going guys!
The problem I am encountering now with the current snapshot
is a template relative problem in type_traits/is_based_and_derived.hpp. The
compiler asserts; probably because of a template argument matching problem that
the preprocessor has. Im not sure, but I would like to find out how to
work around this problem.
The compiler asserts;
template typename B, typename D
struct bd_helper
{
template typename T //ß cant handle the template function with another specified template arg.
static type_traits::yes_type check(D const
volatile *, T);
static type_traits::no_type check(B const
volatile *, int);
}
I was wondering if anyone could assist me to get
around this problem.
danielk
Re: [boost] Re: Formal review or Variant Library (Ed B.)
Fernando Cacciola [EMAIL PROTECTED] writes: Suppose you have a variantmpl::listint, std::string AFAICT references are not supported by variant either. But if it were.. How do you check to see if it contains an int? But extracting (or accessing, or peeking) (int)*. Pointers to references are illegal. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, William E. Kempf wrote: First off, just in case you didn't realize it, this message was directed at one person not the group in general. I cced it to the list. I *hate* forced reply-to. Are you, or are you not interested in my Lock Classes. The messages I got from you is that you are only interested in my lock classes if I haven't had a chance to really evaluate anything here. You'll have to give me some more time. No problem. 1) It is reproposed as an extension to the locking mechanism in Boost thread. and/or I'd say it would at least have to play nice with Boost.Threads. If *I* find the idea interesting, I'd personally lean towards making it part of Boost.Threads. But technically that wouldn't be an absolute requirement for it being considered by Boost at large (even if I'd suspect you'd find many people interested only if it were part of Boost.Threads). Well as I said in a previous email my Lock Classes can be used on top of any locking mechanism. I used POSIX locks since that I what I used in my project. But by Mutex class can be substituted by any class that offers a lock() and unlock() methods or the equivalent of them. 2) It is reworked to somehow be an extension of the smart pointer concept, even though it has very little relation to smart pointers. I haven't looked at this at all, so I can't comment too much. But there's a lot to be said for having a locking_ptr concept, which may be why people are advocating it here. Well as I said before, as far as I know, the only type of pointer like management that will make sense for a Mutex is a scoped_ptr. This concept is already implemented in Boost.Thread and not very interesting. and since we're in a crunch time, like Beman and others have pointed out, you'll not get that kind of feedback, pro or con, at this point in time. No problem. I will repost latter if I don't get any serious interest now. -- http://kevin.atkinson.dhs.org ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Thread-Local Storage (TLS) and templates
Gabriel Dos Reis [EMAIL PROTECTED] writes: Ken Hagan [EMAIL PROTECTED] writes: | Peter Dimov wrote: | | k does not exist yet at compile-time (in a pointer to int form), when | templates are instantiated. | | It doesn't have to. We're instantiating a template, not calling a | function, so if k has the type pointer to thread-local int then | the compiler knows that and can instantiate the appropriate code. The issue here is the *value* k, not the type of that expression. Let me reiterate, just in case somebody missed it: this is a similar problem to that of using a pointer/reference-to-data-member as a template paramter. You can think of each thread-local global variable as a data member in a big struct, of which there's a single instance per thread. The address of this global variable is just as much a constant as the address of a data member. There's no problem here, AFAICT. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal review or Variant Library (Ed B.)
Fernando Cacciola [EMAIL PROTECTED] writes: All right. Now that we've settled on the conceptual validity of optionalT... Can we have it? I don't see why not. Any idea about what to do with reference to reference problem? What's the problem? I have to look at reference_wrapper() yet... What was the idea of: optional exactlyT ? It's an ambiguity breaker: a way of specifying, when constructed with a variantT,T, that you want to get the T and not the T. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Formal review or Variant Library (Ed B.)
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Fernando Cacciola [EMAIL PROTECTED] writes: Any idea about what to do with reference to reference problem? What's the problem? Currently, optionalY has: explicit optional ( T const val ) T* get(); T* operator-() ; T operator *(); those are all illegal if T is a reference type. What was the idea of: optional exactlyT ? It's an ambiguity breaker: a way of specifying, when constructed with a variantT,T, that you want to get the T and not the T. hmmm, shouldn't 'exactly' appear along with extract then? What's the meaning of optional exactlyT by itself, without variantT,T in the scene? -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread-Local Storage (TLS) and templates
Peter Dimov wrote: [...] I must admit that I didn't expect even for p to be different across threads. Not doing so would probably violate a rather nice axiom stated in the 1.7/1. ``Every byte has a unique address.'' ;-) Seriously, TLS shall not be private; similar to automatic storage duration, an object with thread-local storage duration shall be accessible by all threads... after the *owner* thread has published its address. And, BTW, lazy-vs-eager allocation/creation is another rather interesting issue... regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_convertible love
I'm in love with the new is_convertible; I can now detect move-copy
types like auto_ptr! Could the old is_convertible do this?
#include boost/type_traits/is_convertible.hpp
#include boost/static_assert.hpp
#include memory
int main()
{
BOOST_STATIC_ASSERT(
(boost::is_convertible
std::auto_ptrint, std::auto_ptrint
::value));
BOOST_STATIC_ASSERT(
(boost::is_convertible
std::auto_ptrint, std::auto_ptrint
::value));
BOOST_STATIC_ASSERT(
(!boost::is_convertible
std::auto_ptrint const, std::auto_ptrint
::value));
BOOST_STATIC_ASSERT(
(!boost::is_convertible
std::auto_ptrint const, std::auto_ptrint
::value));
}
-Dave
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman wrote:
The area would be helped by renaming extract to access.
I tend to agree the name is confusing. So shall we call it
boost::access? Input?
Dave A.'s comment that access is confusing because it is a noun and a verb is well
taken. Of course, the same can be said for extract. ;-) Who designed English anyway,
and how did it ever get ratified? The suggestion to use the verbs (or are they
nouns?) view and proxy do a good job reinforcing that you don't have a separate copy.
They are a step in the right direction.
I don't think a member function really will solve the problem, but I do
agree the whole extract facility can be improved.
I agree the issues goes beyond member vs. free. By the way, what is the motivation
for using free over a member function? Part of my motivation is because this
following usage came to mind as a solution to the extract confusion:
T value = var.contentT(); // Throws on type mismatch
T ref = var.contentT(); // Throws on type mismatch
T* ptr = var.contentT*(); // Returns null on type mismatch
The name content seems more nature here as a member function than it would as a free
function. Also, regardless of free or member, does such a syntax avoid ambiguity?
Finally, it wasn't clear to me why the return type for
which() wasn't unsigned.
It's not? I see that which() returns an unsigned int, which I believe is
the same as unsigned. (Am I wrong?)
The documentation in reference.html shows that which() returns int. (I didn't check
whether the code matched up.)
The destroyer class contains a function with an unreferenced
formal parameter, which triggers a warning under VC7. Since
this a useful warning, all unreferenced formal parameters
should be removed (or commented out).
I'm not sure what parameter you're referring to. The only function in
destroyer class is...
template typename T
void operator()(const T operand) const
{
operand.~T();
}
...but certainly all formal parameters (i.e., operand) are referrenced
in the function body.
What sort of warning are you getting from VC7?
You're right. I didn't look carefully enough before to notice that this is clearly a
bug in VC7. It is reporting warning C4100 for the operator() function you mention
above, if compiling at warning level 4. I'll email this to Jason. If you want to
work around the bug, you can put the push, disable, pop pramgas around the function.
I checked that this works.
The copyright notice doesn't make clear that the copyright
notice need appear only in source code copies.
I'm not sure what you mean. Could you please explain?
One of the boost license requirements is this: Must not require that the license
appear with executables or other binary uses of the library.
The copyright notice contains this clause: provided that the above copyright notice
appears in all copies.
To make it clear that a compiled program uses this library need not include the
copyright notice, it would be good to change copies to source code copies.
P.S. I just looked content up in the dictionary: it's a noun, verb, and adjective.
Sometimes you just can't win! :-)
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Formal review or Variant Library (Ed B.)
Fernando Cacciola [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Fernando Cacciola [EMAIL PROTECTED] writes: Any idea about what to do with reference to reference problem? What's the problem? Currently, optionalY has: explicit optional ( T const val ) T* get(); T* operator-() ; T operator *(); those are all illegal if T is a reference type. explicit optional ( typename add_referencetypename add_constT::type::type val ) typename add_pointertypename remove_referenceT::type::type get(); typename add_pointertypename remove_referenceT::type::type operator-() ; typename add_referenceT::type operator *(); What was the idea of: optional exactlyT ? It's an ambiguity breaker: a way of specifying, when constructed with a variantT,T, that you want to get the T and not the T. hmmm, shouldn't 'exactly' appear along with extract then? What's the meaning of optional exactlyT by itself, without variantT,T in the scene? I dunno, maybe nothing; we were talking about optional as a replacement for extract. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
class Mutex {
pthread_mutex_t l_;
public:
Mutex() : l_(MUTEX_INIT) {}
^^
I believe this behavior is well defined.
Only /mutex/ itself may be used for performing synchronization.
The result of referring to copies of /mutex/ in calls to snip
is undefined.
End of story.
You ignored the rest of my argument. Neither the right hand side or the
left hand side of the assignment involve a mutex that has ever been used
in any way by any function. It may be technically undefined by the POSIX
standard however I can not see any way that this can do any harm. I
challenge you to find an implementation in which what I did will cause a
problem, or for that matter an hypothetical implementation.
---
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal review or Variant Library (Ed B.)
Ed Brey [EMAIL PROTECTED] writes: Eric Friedman wrote: The area would be helped by renaming extract to access. I tend to agree the name is confusing. So shall we call it boost::access? Input? Dave A.'s comment that access is confusing because it is a noun and a verb is well taken. Of course, the same can be said for extract. ;-) But not as plausibly, IMO. I agree the issues goes beyond member vs. free. By the way, what is the motivation for using free over a member function? For one thing, the lovely template keyword: var.template extractT(); ^ For another, syntax compatibility with Boost.Python. Incidentally, no Boost.Python user has reported confusion about extract, and they tend to be slightly more naive than the average Boost user. Part of my motivation is because this following usage came to mind as a solution to the extract confusion: T value = var.contentT(); // Throws on type mismatch T ref = var.contentT(); // Throws on type mismatch T* ptr = var.contentT*(); // Returns null on type mismatch All missing template in a dependent context. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
class Mutex {
pthread_mutex_t l_;
public:
Mutex() : l_(MUTEX_INIT) {}
^^
I believe this behavior is well defined.
Only /mutex/ itself may be used for performing synchronization.
The result of referring to copies of /mutex/ in calls to snip
is undefined.
End of story.
You ignored the rest of my argument. Neither the right hand side or the
left hand side of the assignment involve a mutex that has ever been used
in any way by any function. It may be technically undefined by the POSIX
standard however I can not see any way that this can do any harm. I
challenge you to find an implementation in which what I did will cause a
problem, or for that matter an hypothetical implementation.
Alright after reading the standard a bit closer on the behavior
PTHREAD_MUTEX_INITIALIZER. It says it can be used to statically
initialize a mutex and implies it may only be used in the form of
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER. However I do not see
how:
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mutex = MUTEX_INIT.
is functionally different than the form it gives.
--
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Formal review or Variant Library (Ed B.)
David Abrahams wrote: Ed Brey [EMAIL PROTECTED] writes: Eric Friedman wrote: The area would be helped by renaming extract to access. I tend to agree the name is confusing. So shall we call it boost::access? Input? Dave A.'s comment that access is confusing because it is a noun and a verb is well taken. Of course, the same can be said for extract. ;-) But not as plausibly, IMO. Agreed. My comment about extract also being a noun was a joke. Technicalities aside, it is not subject to part of speech confusion the way access is. Semantic confusion still seems like a problem, however. Incidentally, no Boost.Python user has reported confusion about extract, and they tend to be slightly more naive than the average Boost user. Unfortunately, that data point is of limited use, since Python has a lot of names leaving something to be desired (generally those borrowed from C and Unix). When I was a Python newby, insetad of complaining, I just got used to looking up functions in the docs to be sure I knew what they did. I agree the issues goes beyond member vs. free. By the way, what is the motivation for using free over a member function? For one thing, the lovely template keyword: var.template extractT(); ^ Let me make sure I undestand the context here: the template keyword is used iff var is a template parameter, right? That seems like a minor use case to me. It doesn't make sense to give up the strong OO correlation that a member function provides just because of a keyword in a minor use case. This is especially true considering that a free function could be provided in addition for the template case. I know the strong OO correlation phrase can launch into the debate over whether member functions really make for better OO, which I don't want to go into. I'm just looking at existing practice with the standard library container classes. If you want to get a piece of the contents of those containers, you use a member function. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Lock Classes: Does anyone care.
Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
Kevin Atkinson wrote:
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
class Mutex {
pthread_mutex_t l_;
public:
Mutex() : l_(MUTEX_INIT) {}
^^
I believe this behavior is well defined.
Only /mutex/ itself may be used for performing synchronization.
The result of referring to copies of /mutex/ in calls to snip
is undefined.
End of story.
You ignored the rest of my argument. Neither the right hand side or the
left hand side of the assignment involve a mutex that has ever been used
in any way by any function. It may be technically undefined by the POSIX
standard however I can not see any way that this can do any harm. I
challenge you to find an implementation in which what I did will cause a
problem, or for that matter an hypothetical implementation.
struct pthread_mutex_t_ {
/* ... */
#ifdef __cplusplus
__copy_ctor(const pthread_mutex_t_) {
throw Don't do this!;
}
#endif
};
typedef struct pthread_mutex_t_ pthread_mutex_t;
regards,
alexander.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_convertible love
David Abrahams [EMAIL PROTECTED] writes:
I'm in love with the new is_convertible; I can now detect move-copy
types like auto_ptr! Could the old is_convertible do this?
#include boost/type_traits/is_convertible.hpp
#include boost/static_assert.hpp
#include memory
int main()
{
BOOST_STATIC_ASSERT(
(boost::is_convertible
std::auto_ptrint, std::auto_ptrint
::value));
BOOST_STATIC_ASSERT(
(boost::is_convertible
std::auto_ptrint, std::auto_ptrint
::value));
BOOST_STATIC_ASSERT(
(!boost::is_convertible
std::auto_ptrint const, std::auto_ptrint
::value));
BOOST_STATIC_ASSERT(
(!boost::is_convertible
std::auto_ptrint const, std::auto_ptrint
::value));
}
OK, I give up. This doesn't work for GCC. Does anybody have a clever
route to detecting types whose copy ctor have a non-const RHS? It's
fine to assume that an accessible copy ctor exists.
TIA,
Dave
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal review or Variant Library (Ed B.)
Ed Brey [EMAIL PROTECTED] writes:
Incidentally, no Boost.Python user has reported confusion about
extract, and they tend to be slightly more naive than the average
Boost user.
Unfortunately, that data point is of limited use, since Python has a
lot of names leaving something to be desired (generally those borrowed
from C and Unix). When I was a Python newby, insetad of complaining,
I just got used to looking up functions in the docs to be sure I knew
what they did.
Are you kidding? Python users (almost) never read docs!
{sorry all you other Python users out there; it's just my impression}.
I agree the issues goes beyond member vs. free. By the way, what
is the motivation for using free over a member function?
For one thing, the lovely template keyword:
var.template extractT(); ^
Let me make sure I undestand the context here: the template keyword is
used iff var is a template parameter, right?
No, iff it's a template parameter or dependent on one.
That seems like a minor use case to me.
Not to me. I'll probably only use variant in a dependent context.
It doesn't make sense to give up the strong OO correlation that a
member function provides just because of a keyword in a minor use
case. This is especially true considering that a free function
could be provided in addition for the template case.
I know the strong OO correlation phrase can launch into the debate
over whether member functions really make for better OO, which I don't
want to go into. I'm just looking at existing practice with the
standard library container classes. If you want to get a piece of the
contents of those containers, you use a member function.
It's easy to make this case if you assume dependent variants are an
edge case.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
David B. Held wrote: So those arrays never get resized? No, but if they did, I could use the swap function to move the pointers from the old array to the new one. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Regression progress; Win32
I think this is just a mistake in Gennadiy's build for Win32. On Win32, a DLL (boost_prg_exec_monitor.dll) cannot link to a symbol in an executable, period. To make this work, the user has to supply a DLL containing cpp_main. Shared libraries build indeed does not work on win32 platform yet. But, to my knowledge it never requested during regresion test build. How would it work for Beman in other case? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman wrote: The area would be helped by renaming extract to access. I tend to agree the name is confusing. So shall we call it boost::access? Input? what about get_value? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Formal review or Variant Library (Ed B.)
David Abrahams wrote:
Ed Brey [EMAIL PROTECTED] writes:
Unfortunately, that data point is of limited use, since Python has a
lot of names leaving something to be desired (generally those
borrowed from C and Unix). When I was a Python newby, insetad of
complaining, I just got used to looking up functions in the docs to
be sure I knew what they did.
Are you kidding? Python users (almost) never read docs!
{sorry all you other Python users out there; it's just my impression}.
Nope. I'm serious. I use the ActiveState distribution, and since it's convenient to
look up a module in the index, and since the documentation is nice and brief, I always
give a quick glance through the docs on a module that is new to me before using it.
And in the case of some of the more cryptic modules, like shutil, I look up functions
even after they're not so new to me, especially if it's been a while.
[Use of a member function instead of a free function.]
It's easy to make this case if you assume dependent variants are an
edge case.
Let's assume that dependent variants are not an edge case. Would you say that the
advantages of tight binding for non-template cases and prettier syntax for dependent
variants are each strong enough to justify a dual interface, i.e. free and member?
Interestingly, of the two, I'd say that member is most natural and free is pragmatic,
working around the compiler's lack of omnicience.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Wed, 19 Feb 2003 16:09:26 +0200, Rani Sharoni
[EMAIL PROTECTED] wrote:
// fire-prevention
template typename T
BurnT ref(T*);
You can improve it to deal with qualified function types (you can't have
pointers or references for such types):
Right. However the version with the (pointer to) array
BurnT ref(T(*)[1]);
requires a compiler which doesn't give an error for abstract classes
(as settled by core 337). If one doesn't have it then it's probably
better giving up qualified function types than abstract classes, being
the latter more common than the former.
[...]
BTW, I've seen how complex boost::is_reference is. Why so? What
compiler(s) cause(s) most problems?
VC6 is problematic since the usual techniques to simulate partial
specialization ICEd it.
I remember that I came up with the same VC6 trick before I saw it in boost
and I wonder who invented it.
Hmm... Why I'm not surprised it was VC? Just to do a little
experimenting a gave it a try, and I'm posting here some discoveries
so that this waste of time can be useful for someone else too :-)
Well, at the first shot, I wrote this:
template typename U
no check_is_reference (U*); // VC++ fails in some cases with this.
// (yeah, it's able to form pointers
// to references!!!)
template typename U
yes check_is_reference (...);
template typename T
struct is_reference {
BOOST_STATIC_CONSTANT(bool, value =
sizeof(yes) == sizeof (::check_is_referenceT( 0 ))
);
};
but as you can see from the comments VC++ is able to break it :-) As
I've seen, it can easily form pointers to references. For instance:
template typename T
void f(T* p) {
}
fint(0); // -- works!
The problem arises when you try to use the pointer, of course.
Example:
template typename T
T f(T* p) {
return *p; // (1)
}
fint(0);
Here the line marked with (1) gives:
cannot convert from 'int *' to 'int '
which shows that in this context our pointer to reference is actually
a pointer to pointer (at least if the error message is reliable). And
that's already nice to know for those who must cope with VC++.
On second try, I slightly modified the is_enum code to:
template typename U
no check_is_reference (U*);
template typename U
yes check_is_reference (...);
template typename T
struct is_reference {
static T t;
BOOST_STATIC_CONSTANT(bool, value =
sizeof(yes) == sizeof (::check_is_referenceT( t ))
);
};
In this case it seems to work. Of course it is a mystery why now it
doesn't form pointers to references anymore. Furthermore, it now even
seems to work too much! :-) That is, instead of failing for abstract
classes and function types it kindly fails on the former only :-) What
a strange world...
BTW, under VC++ the boost version (release 1.29.0) of is_reference
gives false positives with function types.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Ed Brey wrote: [snip] The documentation in reference.html shows that which() returns int. (I didn't check whether the code matched up.) OK, I didn't realize you were talking about the docs. I'll note this to fix. The copyright notice doesn't make clear that the copyright notice need appear only in source code copies. I'm not sure what you mean. Could you please explain? One of the boost license requirements is this: Must not require that the license appear with executables or other binary uses of the library. The copyright notice contains this clause: provided that the above copyright notice appears in all copies. To make it clear that a compiled program uses this library need not include the copyright notice, it would be good to change copies to source code copies. I lifted the copyright notice from other Boost libraries (see MPL and Boost.Threads). I am happy to change the notice if necessary, but should these other libraries follow suit? Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal review or Variant Library (Ed B.)
David Abrahams said:
Ed Brey [EMAIL PROTECTED] writes:
Incidentally, no Boost.Python user has reported confusion about
extract, and they tend to be slightly more naive than the average
Boost user.
Unfortunately, that data point is of limited use, since Python has a
lot of names leaving something to be desired (generally those borrowed
from C and Unix). When I was a Python newby, insetad of complaining,
I just got used to looking up functions in the docs to be sure I knew
what they did.
Are you kidding? Python users (almost) never read docs!
{sorry all you other Python users out there; it's just my impression}.
No? I thought this sort of thing was done all the time:
import os
help(os)
help(os.path)
I know I do it a lot.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Formal review or Variant Library (Ed B.)
Ed Brey wrote: [Use of a member function instead of a free function.] It's easy to make this case if you assume dependent variants are an edge case. Let's assume that dependent variants are not an edge case. Would you say that the advantages of tight binding for non-template cases and prettier syntax for dependent variants are each strong enough to justify a dual interface, i.e. free and member? Interestingly, of the two, I'd say that member is most natural and free is pragmatic, working around the compiler's lack of omnicience. I'll also be needing variant a lot from inside template code. I dislike the template keyword that gets in the way. IMO, the way to go is the C++ cast style syntax: extractT(v). There should only be one way to do this. Not two. And FWIW, there's a precedent. Although currently, boost::tuples has two ways to access its elements getN(t) and t.getN(), the TR (and the one that will be a part of the standard) for tuples does not have the member get anymore. IMO, this is a strong case *for* the free cast style and *against* the member function style. The variant and optional should strive to follow tuple's lead. In fact, come to think of it, why not just: getT(v) ??? -- Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Lock Classes: Does anyone care.
Kevin Atkinson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, 19 Feb 2003, Edward Diener wrote: I think the question that needs to be answered is if locking mechanisms have any use outside of threading models. Yes they do. For example when accessing memory shared between separate process. Also, locks can also be used when accessing files. In fact I believe Win32 always uses read/write locks when opening files, on POSIX systems the locks are completely optional but still there. Basically locks can be used when ever accessing a shared resource. I think you have made a good case for a separate library for locking mechanisms. Whether that will be your library in some form or some other one or some mix of implementations, is for the general Boost community to decide. But I believe, given your argument above, that a locking library should not be only folded into the threading implementation which already exists. Of course the implementor of the threading library may feel that his own internal locking mechanisms are sufficient for what he wants to do in his library, but that shouldn't inhibit a separate locking library if the functionality is found useful for other Boost programmers. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal review or Variant Library (Ed B.)
Eric Friedman wrote: I lifted the copyright notice from other Boost libraries (see MPL and Boost.Threads). I am happy to change the notice if necessary, but should these other libraries follow suit? Yes, they should, and there was another thread out there at one time discussing the details. Perhaps it is waiting for input from lawyers. Does anyone know the status? Regardless of that effort, it probably wouldn't hurt for new libraries to be expressly clear on the issue (copyright notice not needed in binaries) from the beginning. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Slow CVS got you down?
I've been noticing that CVS updates on the Boost tree were painfully slow recently; especially the CVS you get with Cygwin behaves this way, barely using any CPU cycles or network bandwidth and taking correspondingly long to get anything done. I just got the latest from http://ccvs.cvshome.org/servlets/ProjectDownloadList and it's *much* better. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Formal review or Variant Library (Ed B.)
Joel de Guzman [EMAIL PROTECTED] writes: In fact, come to think of it, why not just: getT(v) That settles it; Joel is now my official name-meister! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
struct pthread_mutex_t_ {
/* ... */
#ifdef __cplusplus
__copy_ctor(const pthread_mutex_t_) {
throw Don't do this!;
}
#endif
};
typedef struct pthread_mutex_t_ pthread_mutex_t;
I do not know where it is implemented, it is not on my system, this way
but I think what I did should be perfectly legal as I am merely initializing
the class. In fact having ANY constructor will prevent the statement
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER from working on my
system and probably others which IS legal. This is because if you have ANY
contractor defined and PTHREAD_MUTEX_INITIALIZER is a macro which uses the
{...} form you will get something like this ...must be initialized by
constructor, not by `{...}'.
I have changed the definition to:
#ifdef FAST_MUTEX_INIT_DESTROY
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
#endif
class Mutex {
pthread_mutex_t l_;
private:
Mutex(const Mutex );
void operator=(const Mutex );
public:
#ifdef FAST_MUTEX_INIT_DESTROY
Mutex() : l_(MUTEX_INIT) {}
#else
Mutex() {pthread_mutex_init(l_, 0);}
~Mutex() {pthread_mutex_destroy($l_);}
#endif
void lock() {pthread_mutex_lock(l_);}
void unlock() {pthread_mutex_unlock(l_);}
};
I hope your happy now. So stupid systems that have pthread_mutex_t
defined that way will work.
Anyway. My locking primitives are designed to be on top of any locking
mechanism, so this is a minor issue.
---
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Formal review or Variant Library (Ed B.)
Gennadiy Rozental wrote: Eric Friedman wrote: The area would be helped by renaming extract to access. I tend to agree the name is confusing. So shall we call it boost::access? Input? what about get_value? If extract returned a value, I don't think we'd be having this conversation. If anything, your proposal should be to call it get_reference, but I personally find that neither attractive nor particularly clear. Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Formal review or Variant Library (Ed B.)
Peter Dimov wrote: Eric Friedman wrote: Peter Dimov wrote: [...] template class T, ... T extract(variant... operand); template class T, ... T const extract(variant... const operand); template class T, ... T * extract(variant... * operand); template class T, ... T const * extract(variant... const * operand); it's no longer ambiguous. I believe it is. The following (admittedly silly) example fails to compile under Comeau: // -- BEGIN CODE EXAMPLE -- template class T, class Extractable T extract(Extractable operand); template class T, class Extractable T const extract(Extractable const operand); template class T, class Extractable T * extract(Extractable * operand); template class T, class Extractable T const * extract(Extractable const * operand); This is not what I wrote above. OK, I believe I see what you're saying. Problem is that I was trying to design a general boost::extract facility, one that needs not be specialized for each type. (Indeed, with my design, visitable types need not be cognizant of the facility at all.) Is this impossible? Or am I in fact misunderstanding what you're trying to say? Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Formal review or Variant Library (Ed B.)
David Abrahams wrote:
Joel de Guzman [EMAIL PROTECTED] writes:
In fact, come to think of it, why not just:
getT(v)
That settles it; Joel is now my official name-meister!
Seems OK to me, too.
Some questions though:
1) Semantics of get are to fail at compile-time for tuples. Not so for
variant, any, etc. Is this a problem? Also, what about a nothrow version
of get?
2) Do most compilers allow overloads to be chosen by explicit template
instantiation arguments alone? That is,
template typename T, typename U void f(U operand);
template unsigned I, typename U void f(U operand);
int main() {
int i;
fdouble(i);
f3(i);
}
3) More minor: What should I rename boost::extractable and
boost::extractable_traits? boost::gettable is just so damn ugly g.
Thanks,
Eric
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, Kevin Atkinson wrote:
On Wed, 19 Feb 2003, Alexander Terekhov wrote:
struct pthread_mutex_t_ {
/* ... */
#ifdef __cplusplus
__copy_ctor(const pthread_mutex_t_) {
throw Don't do this!;
}
#endif
};
typedef struct pthread_mutex_t_ pthread_mutex_t;
I do not know where it is implemented, it is not on my system, this way
but I think what I did should be perfectly legal as I am merely initializing
the class. In fact having ANY constructor will prevent the statement
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER from working on my
system and probably others which IS legal. This is because if you have ANY
contractor defined and PTHREAD_MUTEX_INITIALIZER is a macro which uses the
{...} form you will get something like this ...must be initialized by
constructor, not by `{...}'.
I have changed the definition to:
#ifdef FAST_MUTEX_INIT_DESTROY
static const pthread_mutex_t MUTEX_INIT = PTHREAD_MUTEX_INITIALIZER;
#endif
class Mutex {
pthread_mutex_t l_;
private:
Mutex(const Mutex );
void operator=(const Mutex );
public:
#ifdef FAST_MUTEX_INIT_DESTROY
Mutex() : l_(MUTEX_INIT) {}
#else
Mutex() {pthread_mutex_init(l_, 0);}
~Mutex() {pthread_mutex_destroy($l_);}
That '$' should be a ''. Sorry I didn't actually try to compile it.
#endif
void lock() {pthread_mutex_lock(l_);}
void unlock() {pthread_mutex_unlock(l_);}
};
I hope your happy now. So stupid systems that have pthread_mutex_t
defined that way will work.
Anyway. My locking primitives are designed to be on top of any locking
mechanism, so this is a minor issue.
--
http://kevin.atkinson.dhs.org
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shared_from_this overload suggestion
I miss a custom destructor version of shared_from_this. The only one
function just accepts a pointer and construct a shared_ptr from it. Should
shared_from_this also match shared_ptr's constructor that takes a pointer
and it's destructor function object, or the lack of it is a design decision?
I need the following (something like it):
struct drawobj_deleter
{
void operator()(const CDrawObj* pObj) const
{
DeleteDrawObj(pObj);
}
};
main()
{
shared_ptrCDrawObj pObj = shared_from_this(new CDrawObj,
drawobj_deleter());
}
I know I could use de constructor directly, but I prefer using
shared_from_this because this way it's more explicit that we're crossing
the boundary between raw pointer and smart_pointer.
rod.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal review or Variant Library (Ed B.)
William E. Kempf [EMAIL PROTECTED] writes:
David Abrahams said:
Are you kidding? Python users (almost) never read docs!
{sorry all you other Python users out there; it's just my impression}.
No? I thought this sort of thing was done all the time:
import os
help(os)
help(os.path)
I know I do it a lot.
OK, I'm just gonna back out of this one as delicately as possible,
because I can see a giant chasm opening up in front of me. :-)
So, will you forget I ever said it? I know that the mail archives
never will ;-)
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
