July 2005 - Boost - lists.boost.org

[config] Why does BOOST_NO_INTEGRAL_INT64_T depend on BOOST_HAS_LONG_LONG?
by Markus Schöpflin 22 Aug '05

22 Aug '05

Currently config/suffix.hpp contains the following code which seems pretty wrong to me: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode. Shouldn't these lines just be removed? Markus

3 10

[type_traits] small workaround logic change
by Vladimir Prus 22 Aug '05

22 Aug '05

Hello, I suggest that the following patch be applied to type_traits/detail/cv_traits_impl.hpp: --- cv_traits_impl.hpp 22 Jun 2005 16:59:26 -0000 1.4 +++ cv_traits_impl.hpp 14 Jul 2005 06:49:40 -0000 @@ -19,7 +19,7 @@ // implementation helper: -#if !(BOOST_WORKAROUND(__GNUC__,== 3) && (__GNUC_MINOR__ <= 2)) +#if !(BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2)) namespace boost { namespace detail { #else The reason is that later in the file, we have: #if BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) and first condition does not exactly match the second condition. Specifically, suppose __GNUC__ is set to 3 and __GNUC_MINOR__ is not set. The first condition will evaluate to ! (BOOST_WORKAROUND(__GNUC__, == 3) && (__GNUC_MINOR__ <= 2) = ! (1 && (0 <= 2)) = ! (1 && 1 ) = 0 The second condition in the file will evaluate to: BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) = 1 && 0 = 0 So, both conditions evaluate to the same value, while they are supposed to be mutually exclusive. The case where __GNUC_MINOR__ is not set is a pathological -- I've found it when playing with some C++ parser, but the patch should do no harm. Opinions? - Volodya

3 2

Bug in boost::rational, no Boolean conversion; an operator template suggestion
by Daryle Walker 22 Aug '05

22 Aug '05

I'm writing a class template where the template parameter is a type that should represent real numbers. It started choking when using boost::rational when I needed Boolean conversion, e.g. template < typename T > void my_class<T>::my_func() { if ( this->s_ ) //... } Looking at boost::rational, I noticed that it does NOT have a Boolean conversion operator (i.e. an unspecified numeric/pointer type). Before anyone says that's proper, realize that boost::rational DOES have "operator not()" defined! This is a surprise to the typical C++ programmer. Either both should be defined, or neither. I think that boost::rational should add a Boolean conversion. (It's a quick fix, and it is critical, so it should be done for this release.) Incidentally, maybe we should define another helper template for <boost/operators.hpp>. If a type supports default construction and equality via "operator ==()", then a Boolean conversion and "operator not()" will be added. (It's up to the user to make sure the type is numeric and the default value is equivalent to zero.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 4

policy_ptr?
by Peter Dimov 16 Aug '05

16 Aug '05

The recent lively thread in comp.lang.c++.moderated has sparked my interest in the policy_ptr proposal. Is the final version of the submission available? -- Peter Dimov http://www.pdimov.com

3 9

What does "ll" stand for?
by Daryle Walker 15 Aug '05

15 Aug '05

This is for the "ll" function defined for quaternions and octonions. The function returns the 1-norm of its argument. Does anyone know what the "ll" name stands for? I finally figured out that "sup" (the infinity-norm) most likely stands for "supremum". (BTW, "abs" is the 2-norm. The "norm" function isn't actually in this system, despite the name!) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 4

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 15 Aug '05

15 Aug '05

>From: Rogier van Dalen <rogiervd(a)gmail.com> >Subject: Re: [boost] Call for interest for native unicode character > and string support in boost > >Great, this seems a good first step. Glad to see things moving. I'll >give my comments, but I hope Erik will step in so we can see what he's >got. > >> I welcome comments. >> >>I agree with the general idea. >>First, http://www.boost.org/more/lib_guide.htm#Guidelines has coding >>guidelines. In general, your code looks slightly C-ish. The Boost >>habit is to use the ".hpp" extension for C++ headers. You attached a >file "unicode.hpp" but talk about "Unicode.hpp": note that these are >different names. >I suggest we make a namespace "unicode" rather than prepending >everything with "uni". The enums had probably better be put in >structs. > >namespace unicode { > struct range { > enum type { > latin1_supplement, > latin_extended_a, > latin_extended_a, > ipa_extensions, > // ... > } > }; >} Yes - it should be namespaced - I had omitted it for clarity. I still think that the uni prefix might be useful to remind those programmers using 'using unicode' that these are Unicode functions - but I am happy to lose that argument. >The fact that I find "Hungarian notation" ugly and meaningless is >probably irrelevant, but it's not the way it's generally done in >Boost. >char32_t is not yet a part of the C++ standard, I believe. I'm not >sure, maybe we'd better call it "codepoint" anyway, and use #ifdef'ed >typedef's. >BOOL is not C++; it is spelled "bool". DWORD doesn't exist either; I >believe you mean uint16_t (sic) for the collation data, if I >understand correctly what the methods are doing. But I think collation >should not be in this header yet, but rather be inserted later, when >the string classes are defined. Oops - caught - I was attempting to write it in such a way that it could be used from C as well as C++ - hence BOOL not bool. DWORD is actually uint32_t. I believe collation must be here as there will be probably be several containers with Unicode characteristics and this is a good level for them to work on. >Case conversion should probably take output iterators. That'll get rid >of the complex/simple division. The methods should probably be >templated as well, and take ranges rather than counts. >template <class InputIterator, class Outputiterator> > lowercase (InputIterator first, InputIterator last, OutputIterator >result); >template <class InputIterator, class Outputiterator> > uppercase (InputIterator first, InputIterator last, OutputIterator >result); I like this but we will still need to have a complex/simple division. However using iterators the complex can do both, and the simple then becomes GetSimpleLowercase for case conversion without changing length, but it can again take an output iterator. >The break functions: >Couldn't these take iterators as well? For all use cases I can think >of, this would be a much easier version to use: >template <class InputIterator> > InputIterator advance_grapheme (InputIterator position, InputIterator >last); >(etc.) When I did my original coding I coding each of following: GetStartOfGrapheme GetPreviousGrapheme GetNextGrapheme I found that just be having IsStartOfGrapheme all these became really simple routines. I therefore believe extremely strongly that it is necessary to have StartOfGrapheme and that the others like GetNextGrapheme or advancegrapheme will then be simple/inline wrappers that use StartOfGrapheme. I also found that there was a coding hit if you have to test start and end iterator positions when processing the grapheme, hence I was passing in three DWORDs. Having said that, allowing inline versions that take iterators to call the core uint32_t/ [DWORD] functions would a good thing, and I would expect this to happen. >Finally, just thinking out loud: both the case mappings and collation >have default (non-locale-specific) and tailored modes. Shouldn't those >best be represented by classes rather than free functions, and >shouldn't there thus be a global variable "default" that provides >default operations, and other objects for locale-specific operations? Unicode case mappings are locale inspecific. I do not intend to handle any code page conversions at this stage - that can be added on later and should be handled separately in a separate discussion. Those conversions would not be Unicode conversions and I believe that discussion should be postponed for a later date. Yours, Graham

3 2

Interest for a perl6-like-junctions-class?
by FlSt＠gmx.de 11 Aug '05

11 Aug '05

Hi! The new Perl 6 has a nice feature called junctions. See http://www.perl.com/pub/a/2003/07/29/exegesis6.html?page=4 and http://www.metaperl.com/talks/p6-junctions/ for more information. I think this is a interesting way to save the time for writing loops in some situations. I've tried to implement this for C++ and uploaded a version with two examples into the Boost Sandbox File Vault (flos_super_position.zip). This version works for my purposes, but if you interested i would rework it and submit it to the boost library. Sincerely, Florian S.

13 95

Custom allocator for shared_ptr
by Dave 10 Aug '05

10 Aug '05

Hello all, I assume that the reference count object pointed to by shared_ptr objects is on the heap. Is there a way that I can specify a custom allocator for shared_ptr to use for this purpose? Thanks, Dave

4 3

[Range] No Reply?
by David Abrahams 05 Aug '05

05 Aug '05

Thorsten Ottosen <nesotto(a)cs.aau.dk> writes: > Citat David Abrahams <dave(a)boost-consulting.com>: > > Hi Dave, > >> >> Thorsten, >> >> there are important issues here that go to the suitability of this >> library for generic programming. I notice there was no answer on the >> list. It's crucial that you deal with these questions eventually, and >> IMO it should happen before the 1.33.0 release. >> > > I'll see what I can do. My laptop was stolen two weeks ago, so > its hard for me to do any real work. Ouch! I'm sorry to hear that! > When is 1.33.0 going to be? I think we're hoping to do a prerelease candidate this weekend or Monday. > Anyway, here's the issues: I'm not sure that you quite "got" most of the concerns I raised. > 1. change XXX to boost::XXX. ok, I don't see any problem with this. I > could fix it monday. -------------- If you already understood everything I'm writing in this section delimited by dashes, please just tell me so and I'll relax. I'm not asking for you to simply change XXX to boost::XXX everywhere. To quote from my original posting: > | 1. What does it take to get support for standard containers as ranges? > | According to what I can see in the documentation, the standard > | containers don't satisfy the range concepts. IOW, > | > | begin(v) > | > | isn't valid when v is a standard vector. > | > | From what I can tell from browsing the implementation, the > | requirement should be: > | > | boost::begin(v) The problem is that the Range concept requirements, as you specified them, are not satisfied by standard containers. Therefore the standard containers are not Ranges. Since it is a goal of the library that the standard containers be Ranges, you need to fix the way you've specified the concept requirements. And as I said later in the post: > One should be able to look at a concept definition and understand > which types will model that concept. That concept > definition may of course lead you to look at the implementation of > other functions, but it has to let you get ahold of one end of the > string, so you can follow it to its logical conclusion. That's why > the concept definition should say that boost::begin(s) is a > requirement... and of course it should link(**) to the documentation for > boost::begin so the reader can find out what it takes to make that > function work, and deduce that it works for standard containers. -------------- I also said: > | and the default behavior of boost::begin needs to be documented. > > it's documented in another document. I provided linke to in in the > CVS version some time ago after you requrested it. And then I asked that you post a link (both to the page with the boost::begin documentation and to the page in the main docs that links to it), but I have yet to see a reply. > 2. swappable range: > > The page says: "Since ranges are characterized by a specific underlying iterator > type, we get a type of range for each type of iterator." > > that's the definition. Sorry, but that's not a definition of anything. > Is it so hard to grasp? It is easy to infer what you mean, if you're very familiar with the new iterator concepts. It's also very easy to misinterpret if you're not, because swappable iterator is a counterintuitive name. More importantly, as I suggested, there is no need to name these concepts (because you can just say "Requires: iterator<R>::type is a model of RandomAccessTraversalIterator," or whatever), especially not before they have been shown to be useful in specifying algorithms. There's no need to build a parallel and redundant concept hierachy. In fact, it's probably harmful to do so. > 3. Implementation of concepts. > > A type conforms to a concept, so ok, you can't implement it. Maybe a renaming > to "Implementations of types that concorm to Range concepts". ? I don't know what the right title is first try to answer the question I asked: You need to rename this page. What is it really describing? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 4. links from concepts to implementation. I'm not sure what you're referring to. > I remember I put some links when you asked for it. It should be > in the cvs code. In the code? I remember asking you to post some links. Or maybe you mean you fulfilled the request in (**) to put links in the documentation? Can you tell me where, on the boost-consulting CVS mirror, I can find that? > Do you want more links? I can't know until I can see what you've already done. > 5. containers and iterators. It should be explained in the introduction > that pairs and containers "just works". That is insufficient. The concept requirements have to be correct. And by the way, if you mean "This library therefore provides the means to adapt standard-like containers, null terminated strings, std::pairs of iterators, and raw arrays (and more), such that the same generic code can work with them all." then no, it doesn't make it clear that they "just work." It claims that the library gives me the *means* to make them "just work." So I'm left asking, "how do I do that?" Also, IIUC, this and other mentions of null terminated strings need to be removed now. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[network] Boost.Network proposal v0.3
by Pedro Lamarão 05 Aug '05

05 Aug '05

Fellow Boosters, this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the Sandbox. I consider it feature complete for a 1.0 milestone; the features being: *) IOStreams classes, fully buffered *) A listener class *) A wrapper for the name resolution service *) A type to store addresses The missing pieces being: *) Complete the copy constructores and assignment operators of the generic_address class. *) Implement optimized xsputn() and xsgetn() in the stream buffer. *) Implement setbuf() in the stream buffer. *) Documentation (never enough) The above list is what I intend to polish up for a formal proposal. This is the TODO list for a next version: *) Address types specific for IPv4 and IPv6, with input operators. *) A formatter output operator for generic address types based on the name resolution service. *) Resolver options and manipulators for the above output operator. *) Code conversion in the stream buffer. *) A poller class. *) Wrapper for sendfile/TransmitFile. *) Implement showmanyc() and perhaps putbackfail() in the stream buffer. With a proper poller class I believe most people's desires for non-blocking operation would be satisfied. I'm going out of town on vacations for some days, so things are going to stall for a while. I hope to complete all tasks soon after Boost 1.33 is released and a new review cycle starts. -- Pedro Lamarão

6 8