Re: [boost] Re: Draft of new Boost Software License
Alisdair Meredith wrote: Gregory Colvin wrote: It seems that doing it by reference to a web page amounts to Boost reserving the right to change terms in the future, possibly to the disadvantage of the authors and users. But I see lots of code that refers to the GPL that way, so this is another question for the lawyers. Oh, I'd missed that. I assumed the link would reference the license in the downloaded distribution, rather than the online version. That way you are bound to the license you downloaded, rather than a license potentially changing without your notice. Most licenses solve this issue by version numbering, don't they? The GPL certainly does. A typical license reference for a GPLed file: * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. You wouldn't necessarily want to include the "any later version" clause, but boost might want to version the license... Plus, not all PCs with Boost distributions are going to have Internet connections. In these cases you really do need to include the license with the distribution. [Especially as you are binding distribution of the license as a requirement (in appropriate circumstances)] I would agree with that. -- ------- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USAhttp://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Interest in a message buffer class for the boost library?
Paul Vanlint wrote: A couple of years ago I wrote a library module which provides a reasonably efficient way of handling with disjointed buffers and treating them as a single contiguous block for extracting data. I would be VERY interested ... since then I wouldn't have to figure out how to write one on my own :-) I have need for exactly this functionality for use in reading out and reconstructing measurements from a reasonably high data rate particle physics experiment. And I should have started working on it a few months ago :-) -- --- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USAhttp://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem Library mini-review
Iain K.Hanson wrote: We already have a standard portable error >scheme. Why reinvent the wheel? Will we do any better? We might. The POSIX errno scheme doesn't seem all that strong to me. Agreed. I've given a fair ammount of though to this over the past year ( whilst working on sockets). The conclusion I came to was that I would rather have a standard C++ name on what ever platform I work on than keep having to look them up on every platform. I would hope that if the POSIX naming is not used, that at least the documentation would contain a clear mapping between the POSIX name and the C++ name. -- ------- Kevin Lynchvoice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USA http://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] int vs int32_t [was: Serialiization Review repost withconsistent quoting]
Michael Walter wrote: If a library user wants his archives to be portable he has to use int8_t, int16_t, etc.. I don't remember seeing this pointed out, so forgive me if I just missed it or am just stating the obvious, but: These types are technically NOT portable, in two ways: 1) They are not defined by ISO C++ ... although they are required by POSIX 1g, and are optional types in ISO C, C++ compilers are not required to support them. 2) Although both POSIX and C99 define them to be 2's complement integers with the appropriate number of bits, neither standard sets a requirement on byte ordering within the multibyte types. Thus, even if a platform supports them (say, the BSD family), the binary form of the integers is not portable. 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). -- ------- Kevin Lynchvoice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USA http://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
Kevin S. Van Horn wrote: Looks like I may be wrong about the C++ Standard guaranteeing at least 32 bits to signed/unsigned int. I know I read this before, and I've seen it claimed on a web site, but I can't find it in the Standard. Maybe I read it in the draft Standard, and it didn't make the final cut. I think what you were looking for is footnote 39: 3.9.1/2 says that "Plain ints have the natural size suggested by the architecture of the execution environment (footnote 39 that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header .)" limits.h is defined in 5.2.4.2.1 of the C89 standard (which I don't have a copy of) BUT 5.2.4.2.1/1 of the C99 standard says that an int must be able to support values in the range INT_MIN to INT_MAX, which must be at least -32767 and 32767, or 16 bits. I imagine that 5.2.4.2.1 of the C89 standard says the same thing. -- ------- Kevin Lynchvoice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USA http://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
