Re: [boost] int vs int32_t [was: Serialiization Review repost withconsistent quoting]
On Saturday, November 30, 2002, at 02:06 AM, David Abrahams wrote: Matthias Troyer <[EMAIL PROTECTED]> writes: In any case the library user should be reminded that short, int and long are never portable Of course they are perfectly portable! I don't understand how you mean that. If sizeof(long) on one platform id larger than sizeof(long) on another platform, then not all numbers serialized from a long on the one machine can be read on the other. but that by using int*_t and appropriate archive formats one can achieve portable serialization. I think that's a terribly intrusive restriction to place on user code. It seems that most users prefer the "standard " types short, int and long and can live with that decision. Best regards, Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost release compressed by bzip2
> For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed by > bzip2 size is 4 282 kB (down to 81%). tar+ace -> 4 211 kB tar+rar -> 4 138 kB Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] int vs int32_t [was: Serialiization Review repost withconsistent quoting]
Matthias Troyer <[EMAIL PROTECTED]> writes: >> So, while use of them may lead to a MORE portable C++ interface, they won't >directly lead to a >> portable binary serialization format (although you can clearly fix that problem in >platform specific >> byte reordering code). > > Agreed. It would just make the task of implementing a portable binary serialization >easier, since we > know the width of the types. Why is that important? it's easy enough to detect the most significant bit in an integer. We could just use a variable-length representation. > However, we can also do the internal (private) implementation based on > these types and dispatch from operator<<(int) to the appropriate function for >serializing an integer > with sizeof(int) bytes. > > In any case the library user should be reminded that short, int and > long are never portable Of course they are perfectly portable! > but that by using int*_t and appropriate archive formats one can > achieve portable serialization. I think that's a terribly intrusive restriction to place on user code. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: relative/absolute paths in filesystem library
Beman Dawes <[EMAIL PROTECTED]> writes: > >I don't know if it was controversial, but I did bring this up during > >the review and I do think its very important. The basic definition > >of an absolute path should be a path that overrides the base path > >during a resolve. To rephrase, 'foo' is relative because it is an > >adjustment from the current directory, '/foo' on the other hand > >takes precendence over the current path. To re-rephrase, '/foo' is > >relative to the current drive, but not to the current directory. > > That seems like a stretch to me. With your definition, "absolute" > isn't equivalent to "not relative", and that seems counter > intuitive. Maybe, but it does seem to capture reality on Windows. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] FW: Boost.Test and Comeau C++
"John Maddock" <[EMAIL PROTECTED]> writes: >> > I tried to compile Boost.Test using the Comeau C++ compiler version >> > 4.3.0.1 under Linux, and I found several problems that I would like to >> > report. For one, the build process needs the pre-processor define >> >> > _POSIX_SOURCE >> >> > defined when compiling the execution_monitor.cpp module, because >> > otherwise the header (Shouldn't you be using >> > anyway?) does not define the datatype "sigjmp_buf". >> >> I need help from Comeau and/or "Unix" users. >> >> 1. Would it be OK if I switch to csetjmp? Does it correctly supported by > all >> unix compilers? >> 2. Which platforms/compilers require this flag to be set? >> 3. Where would be the best place to set it: in a code or in a Jamfile? > > IMO it's the wrong fix: currently you have: > > // for testing on Win32, GCC thinks it is a unix platform > // TODO: figure out how to tell it is really unix > #elif defined(__unix) && !defined(__GNUC__) > > There are several things wrong with this: > > __unix need not be defined on POSIX conforming systems > __unix may be defined on systems that don't support sigaction etc. > almost all version of __GNUC__ do have sigaction support including cygwin. And don't forget about MinGW. I don't know about its status w.r.t. sigaction. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] implicit_cast
"Paul Mensonides" <[EMAIL PROTECTED]> writes: > - Original Message - > From: "David Abrahams" <[EMAIL PROTECTED]> > >> How is this different from >> >> implicit_cast(f)() >> >> ?? > > It would be no different except that it would be obvious what you are doing > and that you'd be able to enforce the function type. Sorry, I don't think the name "ambiguity_cast" makes anything particularly obvious ;-) -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: assignable()
"David B. Held" <[EMAIL PROTECTED]> writes: >> Also I have concerns about the name "assign()", since >> that is used in the standard library to mean something >> slightly different. > > I don't recall seeing this. Where is it used? In the standard containers, for assignment from an iterator range. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] implicit_cast
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> > How is this different from > > implicit_cast(f)() > > ?? It would be no different except that it would be obvious what you are doing and that you'd be able to enforce the function type. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [MPL + MSVC]
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> > > template
> > > struct get_category
> > > : mpl::if_<
> > > mpl::is_placeholder
> > > , mpl::identity
> > > , get_category_impl
> > > >::type
> > > {
> > > BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
> > > };
> [...]
When is it better to derive from something vs. composing it in a typedef?
Also, we're really close on the smart pointer code. I've checked in the
latest version to the sandbox, applying your changes. However, I still get
14 errors that are all in mpl/identity.hpp. I also got the latest CVS
snapshot.
Here's the errors:
identity.hpp(44) : error C2065: 'void_' : undeclared identifier
identity.hpp(44) : error C2990: 'identity' : non-template class has already
been defined as a template class
identity.hpp(44) : error C2913: explicit specialization;
'struct boost::boost::mpl::lambda boost::boost::mpl::lambda' is not a
class template
etc., ad nauseum. All the errors are on these two lines:
BOOST_MPL_AUX_VOID_SPEC(1, identity)
BOOST_MPL_AUX_VOID_SPEC(1, make_identity)
Now, I notice that I'm supposed to define these for the policies under
bcc. And when I didn't guard them with a macro, VC complained about
them mightily. But when I tried to guard them in identity.hpp, I got about
104 errors, and decided that was Not The Right Thing To Do(R). So
can these safely be used for any compiler? The definition will
automatically
change to the right thing?
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: assignable()
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > When neccessary. It's not as though a "strong guarantee assignment" > is a fundamental operation which people often need. Which is why the swap idiom assign perhaps shouldn't be the default implementation. > [...] > Which type trait name? is_base_and_derived<>. I see that's the actual name. I wasn't sure, because I recalled there being some debate about the name, and didn't know if it had changed until I looked it up in the docs. > > I just added that in for safety. > > Added what? The static assert. > [...] > Don't you want the static assertion in the constructor or in the class > body itself? I guess that makes sense. I obviously didn't think about it too much. > [...] > I'm not sure it's useful enough to warrant putting it in > utility.hpp. Fair enough. > Also I have concerns about the name "assign()", since > that is used in the standard library to mean something > slightly different. I don't recall seeing this. Where is it used? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] get_pointer
Hi, I'm wondering whether the get_pointer function used by mem_fn et al. is really justified. Since you can't invoke a member function on a null pointer anyway, why not simply use &*p for this purpose? -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] assignable()
"David B. Held" <[EMAIL PROTECTED]> writes:
> On c.l.c++.m, I argue that operator=() should not use the swap idiom
> (largely based on comments I've seen Dave Abrahams make), but that a
> named assignment function should instead provide assignment with the
> strong guarantee.
When neccessary. It's not as though a "strong guarantee assignment" is
a fundamental operation which people often need.
> Since this is such a trivial function, I thought
> it would be nice to encapsulate it in a simple class, provided
> below:
>
> template
> struct assignable
> {
> T& assign(T t)
> {
> BOOST_STATIC_ASSERT(is_base_and_derived::value);
> T* const me = static_cast(this);
> me->swap(t);
> return *me;
> }
> };
>
> I'm not sure about the type trait name.
Which type trait name?
> I just added that in for safety.
Added what?
> Of course, this class assumes that T has a non-throwing member
> function named swap(). Obviously, it can be used like so:
>
> class my_class : public assignable
> {
> // ...
> };
Don't you want the static assertion in the constructor or in the class
body itself? Do you want to have to instantiate assign() to find out
you've misused this template?
> void foo(void)
> {
> my_class a, b;
> // ...
> a.assign(b);
> }
>
> The nice thing about this approach, I think, is that if all the data
> members have a basic guarantee assignment, then the default
> operator= works just fine, and now you can add strong guarantee
> assignment with one line (assuming you already had swap, of course).
>
> If people like the idea, perhaps it could go into utility.hpp?
I'm not sure it's useful enough to warrant putting it in
utility.hpp. Also I have concerns about the name "assign()", since
that is used in the standard library to mean something slightly
different.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Boost License Issues
"John Maddock" <[EMAIL PROTECTED]> wrote in message 011f01c2979d$e3c6a020$cb5287d9@1016031671">news:011f01c2979d$e3c6a020$cb5287d9@1016031671... > [...] > Hard to make any patent guarentees I think, as I'm sure the inventors of > the .gif format would attest to. Maybe the Boost moderators could solicit donations from companies with a vested interest in the success of Boost. In particular, it would be interesting if a legal advisory panel/committee or some such could be assembled on a purely voluntary basis to perform patent searches and and give advice on license terms. It seems that if some well-heeled companies gain some benefit from using Boost, this is a reasonably small way they can contribute, with resources that they are already paying for anyway. And if Boost is a legal non-profit organization, then maybe the donations could be tax deductible as well? I have no idea. Also, it would help Boost authors devise licenses that are fair, but perhaps offer a stronger level of protection to potential library users. So it would ultimately benefit those who contribute. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] int vs int32_t [was: Serialiization Review ]
On Friday, November 29, 2002, at 06:32 PM, Robert Ramey wrote: Two suggestions *I think* have been made. 1) that the serialisation library recommends to users who want portable archives, should use the boost::int*_t types instead of short, int, etc. This would only be applicable to binary archives. The only currently implemented binary archive has absolutely no pretense to portability. Should a portable binary archive be submitted, The comments and or documentation might make this recommendation, but its not clear to me that it would be universally preferred. It is also true for your text archives. If you write a 64-bit long on one platform and try to read it on a platform with 32-bit longs you will have problems even for text archives Again, that would be up to the person who submits a portable binary archive. I'll do that once the interface has been finalized Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost release compressed by bzip2
Bandwith and time of those with dialup can be saved by compressing Boost release by BZIP2 compressor (http://sources.redhat.com/bzip2/). For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed by bzip2 size is 4 282 kB (down to 81%). Boost size will grow (Spirit lib has over 600kB) and bzip2 can reduce the growth a bit. Bzip2 is available on many platforms, free to use, stable and quite used. /Pavel _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] implicit_cast
From: "David Abrahams" <[EMAIL PROTECTED]>
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > From: "David Abrahams" <[EMAIL PROTECTED]>
> >>
> >> Here's what I think might be a correct implementation:
> >>
> >> template T implicit_cast(U const& x) { return
x; }
> >> template T implicit_cast(U& x) { return x; }
> >
> > The correct implementation IIRC is
> >
> > template T implicit_cast(typename identity::type x) { return
> > x; }
>
>
> Now I have to put on my inference hat.
>
> ...so the use of identity<> assures that we have a non-deduced
> context, which causes the explicit template parameter to be required?
>
> ...I suppose that T has to be copyable for any of these to work, so
> there's no problem with taking T by-value.
The main reason to prefer this implementation is that it works in contexts
where the conversion is accessible at the point of the implicit_cast call,
but not accessible to the definition of implicit_cast. Here's a test case:
class X
{
};
class Y: private X
{
public:
void f()
{
X * p1 = this;
X * p2 = implicit_cast(this);
}
};
I believe that Darin is the original inventor of this implicit_cast.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: implicit_cast
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Thu, 21 Nov 2002 19:15:21 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Thoughts?
>
>
> This is one... A nice thing about the problem you are talking about is
> that any function having a parameter of type T is in fact a general
> "detector" of convertibility to T (It's also worth noting that it
> detects convertibility of an *expression*, so it is fundamentally
> different from usual templates like is_convertible and the
> like). Well, once you have it it's easy to enforce either
> convertibility _and_ non-convertibility. As an example of the latter,
> this is a trivial way to cause a compile-time error if 'expr' is
> implicitly convertible to the type T.
>
>
> // untested code following
> //
>
> typedef char (&no_type)[1];
> typedef char (&yes_type)[2];
>
> template
> struct identity { typedef T type;};
>
> template
> yes_type implicit_cast (typename identity::type x) {
> return x;
> }
>
> template
> struct check_helper{
> /*
> * empty
> */
> };
>
> template
> struct check_helper {
> typedef T type;
> };
>
>
> template
> no_type implicit_cast (...);
>
> #define EXPLICIT_CAST(dst_type, expr) \
> ( static_cast< check_helper sizeof(implicit_cast(expr)) >\
> :: type>(expr) )
>
Very interesting! Now the macro starts to look useful. However, the
above function shouldn't be called implicit_cast.
OK, here's what I propose:
* implicit_cast as Peter proposed it
* BOOST_IMPLICIT_CAST and BOOST_EXPLICIT_CAST as Gennaro proposed
them.
The latter two can be used in compile-time constant expressions.
> So it looks like we can separate the two 'directions' in which
> static_cast works in two distinct facilities. Maybe this has already
> been discussed here though, I don't know (Actually there's at least
> one limitation: you can't use a local type for T, but... c'est la
> vie!)
>
>
> Also, a static assertion facility (for expressions) can be easily
> implemented:
>
> #define ASSERT_NON_IMPLICITLY_CONVERTIBLE(T, expr) \
> typedef char PASTE (name_, __LINE__) \
> [ \
> sizeof(no_type) == sizeof(implicit_cast(expr)) \
> ];
>
I think we ought to have new traits for implicitly_convertible and
explicitly_convertible. You can always wrap BOOST_STATIC_ASSERT around
that to get the above behavior.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Possible patch to format for Borland BCB5
Samuel Krempp wrote: > Is it really enough to get boost.format to compile with BCB 5 ? OK, finally got the latest version into our builds. Looks good, but I found the following change significantly reduced our number of warnings: boost/format.hpp: was #if !defined(BOOST_MSVC) || BOOST_MSVC > 1300 #define BOOST_OVERLOAD_FOR_NON_CONST #endif now #if !defined( __BORLANDC__ ) && !defined(BOOST_MSVC) || BOOST_MSVC > 1300 #define BOOST_OVERLOAD_FOR_NON_CONST #endif I'm not sure what this code does, as turning it off seems to be an MS-specific hack. What features is this intended for? [With this define enabled, BCB binds all function returns to the non-const version and then complains that it has done so.] -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: implicit_cast
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Fri, 22 Nov 2002 13:48:01 +0200, "Peter Dimov" <[EMAIL PROTECTED]>
> wrote:
>
>>From: "David Abrahams" <[EMAIL PROTECTED]>
>>>
>>> Here's what I think might be a correct implementation:
>>>
>>> template T implicit_cast(U const& x) { return x; }
>>> template T implicit_cast(U& x) { return x; }
>>
>>The correct implementation IIRC is
>>
>>template T implicit_cast(typename identity::type x) { return
>>x; }
>
>
> I do know we all hate macros but this could be taken into
> consideration if we want something usable in constant expressions too.
> The idea is to use a static_cast after checking that the conversion
> could have also been done implicitly:
>
> template
> struct identity { typedef T type;};
>
> template
> T implicit_cast (typename identity::type x) {
> return x;
> }
>
>
> template
> struct check_helper{
> typedef T type;
> };
>
> #define IMPLICIT_CAST(dst_type, expr) \
> ( static_cast< check_helper sizeof(implicit_cast(expr)) >\
> :: type>(expr) )
>
I think I'd prefer to see:
// make sure the static_cast below is a valid expression
BOOST_STATIC_ASSERT(sizeof(implicit_cast(expr)));
... static_cast(expr) ...
I know you have to write expr twice, but it still seems much clearer
to me.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] implicit_cast
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> Thoughts?
>
> We also need this:
>
> template inline func& ambiguity_cast(func& rf) {
> return rf;
> }
>
> ...which casts away ambiguity of a function call--even by return type.
> Maybe add a static assertion to enforce function types.
>
> #include
>
> namespace A {
> int f() {
> std::cout << "int A::f()" << &std::endl;
> return 0;
> }
> }
>
> namespace B {
> double f() {
> std::cout << "double B::f()" << &std::endl;
> return 0.0;
> }
> }
>
> using A::f;
> using B::f;
>
> int main() {
> ambiguity_cast(f)();
> return 0;
> }
How is this different from
implicit_cast(f)()
??
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] implicit_cast
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>>
>> Here's what I think might be a correct implementation:
>>
>> template T implicit_cast(U const& x) { return x; }
>> template T implicit_cast(U& x) { return x; }
>
> The correct implementation IIRC is
>
> template T implicit_cast(typename identity::type x) { return
> x; }
Now I have to put on my inference hat.
...so the use of identity<> assures that we have a non-deduced
context, which causes the explicit template parameter to be required?
...I suppose that T has to be copyable for any of these to work, so
there's no problem with taking T by-value.
OK, I like this implementation. I'm going to add it to cast.hpp unless
there are objections.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: throw_exception missing inline ?
On Fri, 29 Nov 2002 19:20:35 +0200, "Peter Dimov" <[EMAIL PROTECTED]> wrote: > From: "Hugo Duncan" <[EMAIL PROTECTED]> > > I have started getting multiply defined symbols for throw_exception. > > > > Is the template missing an inline modifier ? > > Compiler/platform? Out of line function templates are supposed to generate a > single instantiation. > Bcc 5.6.1 Given the dates on the throw_exception header, I am supprised that I have not seen this before if it were really a problem in bcc. I shall check project files for stray options. Hugo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] int vs int32_t [was: Serialiization Review ]
Date: Thu, 28 Nov 2002 18:42:06 - From: "Iain K.Hanson" <[EMAIL PROTECTED]> >Understood. >But C 99 standardised the int*_t types and in anticipation that C++ 0x >might do the same, boost has them in the integer library ( cstdint.hpp ). I'm am not aware of this. Will these be added to the language as new fundamental types or as a commonly agreed up set of typedefs? If it is the latter (which is what I would expect) then no change is necessary. >Two suggestions *I think* have been made. >1) that the serialisation library recommends to users who want portable >archives, should use the boost::int*_t types instead of short, int, etc. This would only be applicable to binary archives. The only currently implemented binary archive has absolutely no pretense to portability. Should a portable binary archive be submitted, The comments and or documentation might make this recommendation, but its not clear to me that it would be universally preferred. >2) That the serialisation library could detect the size of integral types >being serialised and use the correct int*_t types instead of short, int etc. This would conflict with the basic idea that the archive classes map fundamental types to the storage and/or transmission medium. The mapping is already being done by typedef so no efforts are required in this area. The included native binary archive checks to see that sizes on reading and writing machines are equal and it could check more if someone want's to override the init function and make it more elaborate. Again, that would be up to the person who submits a portable binary archive. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] throw_exception missing inline ?
From: "Hugo Duncan" <[EMAIL PROTECTED]> > I have started getting multiply defined symbols for throw_exception. > > Is the template missing an inline modifier ? Compiler/platform? Out of line function templates are supposed to generate a single instantiation. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HP-UX support
At 06:50 AM 11/29/2002, John Maddock wrote: >> I'm willing to run the regression test regularly but I only have access >to >an >> HPUX 10.20 with aCC version 1.21 installed. But since this compiler >does'nt >> even support the new-style headers I guess it's of little use. >> Next I have trouble finding info on the aCC compilers like the latest >> versions availble, the difference between the aCC compilers on HPUX 10.20 >and >> HPUX 11 etc. It would already be a good start if someone knows all these >> compilers a little better. > >Even an old version would be better than nothing, don't forget we have the >boost std lib compatibility headers in boost/compatibility/cpp_c_headers, >which should fix most of the header problems (ditto STLport if you want to >use that). Yes, it would be great to add regular testing for HPUX and other UNIX platforms. If an older compiler is the only impediment, please contact me privately. Several UNIX compiler vendors have indicated a willingness to contribute a current compiler if that would help. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] throw_exception missing inline ?
I have started getting multiply defined symbols for throw_exception. Is the template missing an inline modifier ? Hugo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] warning with is_polymorphic
"John Maddock" <[EMAIL PROTECTED]> writes: >> I assume the current definition of ~d1() is because some compilers >> generate an implicit destructor with a non-empty >> exception-specification, which then causes an error? I'm wondering if >> we wouldn't be better off just defining ~d1 for those compilers, since >> many other compilers are likely to raise the same warning as above. > > Yep, it's a bit of a mess, but if I remember correctly the explicit > destructor was required VC6/7 and those other compilers that use the same > ABI, in order to ensure that they did the right thing with classes with > virtual bases, but otherwise no virtual functions themselves (the iostream > classes for example). I guess all we can really do is patch this on a case > by case basis depending upon the compilers ABI :-( Sure. But the question is: which should the default be? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HP-UX support
> I'm willing to run the regression test regularly but I only have access to an > HPUX 10.20 with aCC version 1.21 installed. But since this compiler does'nt > even support the new-style headers I guess it's of little use. > Next I have trouble finding info on the aCC compilers like the latest > versions availble, the difference between the aCC compilers on HPUX 10.20 and > HPUX 11 etc. It would already be a good start if someone knows all these > compilers a little better. Even an old version would be better than nothing, don't forget we have the boost std lib compatibility headers in boost/compatibility/cpp_c_headers, which should fix most of the header problems (ditto STLport if you want to use that). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost License Issues
> > I think the problem is that the entire clause can be viewed as disclaiming > > warranties against patent infringement/copyright violation/etc. The > > question is whether it is possible to protect both library authors and > > potential users. I don't see where else the buck can get passed. Perhaps > > a special clause that the software does not infringe on any known > > patents or copyrights, but comes with no other warranties? I have no idea > > what the legal status of such claims are, however. > > > > Dave > > In practice, Boost authors (and reviewers) will have made their best efforts to > ensure that they don't know of any patent infringement and/or copyright > violations. Perhaps we can say this without exposing the authors to too much > risk? (As David rightly observes, I am not worth suing!) > > But ultimately, the user must surely assess and take the risk. However, a > statement "not known to infringe copyright or patent" may help the user assess > the risk. Hard to make any patent guarentees I think, as I'm sure the inventors of the .gif format would attest to. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] warning with is_polymorphic
> I assume the current definition of ~d1() is because some compilers > generate an implicit destructor with a non-empty > exception-specification, which then causes an error? I'm wondering if > we wouldn't be better off just defining ~d1 for those compilers, since > many other compilers are likely to raise the same warning as above. Yep, it's a bit of a mess, but if I remember correctly the explicit destructor was required VC6/7 and those other compilers that use the same ABI, in order to ensure that they did the right thing with classes with virtual bases, but otherwise no virtual functions themselves (the iostream classes for example). I guess all we can really do is patch this on a case by case basis depending upon the compilers ABI :-( John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Socket Multiplexing
"Michel André" <[EMAIL PROTECTED]> wrote in message 0dde01c29700$f6cd7790$a400a8c0@orbit">news:0dde01c29700$f6cd7790$a400a8c0@orbit... > > I have not used async io, so I am a little out of my depth here. If we > > were to create an interface that could be implemented using select or > > aio what design constraints would that impose? > > > > I am guessing the callbacks would be free threaded. Is that right? > [big snip] > Therefore I think that an async io package will be a new addition to the > socket library or a completely new library. I don't even now if its possible > to implement async aio in a consistent manor on all platforms (or at least > sufficient number) that is of interest to boost, but it could be simulated > via another multiplex mechanism and threads I guess. OTOH, if we're discussing i/o in general - there are several platforms that doesn't directly support multiplexing on other devices than sockets, as NT/VMS (and the actual implementation in these cases are beyond my knowledge). Implementing async i/o in terms of multiplexing should be easier than the opposite way around, if the latter is even possible. > > And yes the callbacks should be free threaded, since if several threads is > picking completions of the completion queue notifications will come on any > of those threads. _If_ callbacks are used. Async i/o and callbacks are not necessarily associated with each other (but maybe the discussion was just in the context of callbacks, I came in pretty late). And even if callbacks are used in the library to emulate async i/o, the user needn't be notified in a free-threaded fashion (e.g. the aio_xxx implementation under linux). Just my $0.02. / Johan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
