- Boost - lists.boost.org

Proposed revised voting procedures
by christopher diggins 06 Apr '05

06 Apr '05

Still today, what variations should be merged has not been fully agreed upon. A continually changing ballot is neither fair nor accurate. In order to try and get this process out of the mud I propose we hold a new vote, with the following conditions (these are simply suggestions for guidelines this so that we have something to work with, I don't care if it is followed or not): 1) we agree for once and for all what the "variations" are, (it should be pretty obvious now) 2) the new list is posted with new numbers (and in order!), but *no* distinction is made for the variations (i.e. a ballot does not contain 51a, just 51) 3) the precise variation is chosen once a winner is chosen by the group working in conjunction with the logo maker. Just like what happens after a boost library is accepted for inclusion. 4) I think we should start the vote next monday, and go until friday. 5) new logo submissions can be enterered until sunday at midnight 6) the tally should not be displayed while the vote is going on. 7) votes can not be revised 8) ballots are made in the form readable by Jason Hise's computer program 9) the votes will be posted on line immediately after the vote closes, so that whoever is impatient like me, can do their own preemptive tally. Joel and Kalin has put a lot of effort into the vote up to now and are fair and open-minded. I suggest we elect them as cheerful benevolent dictators of the revised voting process. I think some leadership would make things work a little more smoothly. In other words, they will decide on the new voting guidelines with or without input from the community at their own disgression. Or they may choose not to, such being the nature of a dictatorship ;-) Christopher Diggins

2 1

Re: [boost] (Named) Parameter Library
by Cromwell Enage 06 Apr '05

06 Apr '05

The proposed changes should be okay with me. Was there anything wrong with my proposed extensions to provide the ability to return the type of the parameter argument? How should one improve on them, based on the new codebase? Cromwell D. Enage __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

Re: [Unicode strings] We're off
by Don G 06 Apr '05

06 Apr '05

Hi Erik, I thought I would jump in with some small observations: --- Erik Wien <wien(a)start.no> wrote: > Most users should not really care what kind of encoding > and normalization form is used. They want to work with > the string, not fiddle with it's internal representation. You do care about the representation when communicating with system API's or writing data to networks or files. For example, say, UTF-32 was the chosen representation, some programmers would be constantly converting to UTF-16 to call the system, and vise-versa if UTF-16 is chosen where the system wants something else. > I would be surprised if any other encoding than UTF-16 would > end up as the most efficient one. UTF-8 suffers from the big > variation in code unit count for any given code point and > UTF-32 is just a waste of space for little performance for > most users. You never know though. Here again, the performance measure could easily be dominated by conversions to the underlying system's encoding, depending on the application. Also, on some systems, particularly Mac, the system not only has an encoding preference, it doesn't particularly like "wchar_t *" either. On the Mac, most text is a CFString (a handle of sorts to the text). On Windows, you encounter BSTR's as well. In my not-so-nearly-thought-out work on this, I decided to have the default encoding be platform specific to eliminate the enormous number of conversions that might be otherwise needed. For example, on the Mac, I had an allocator-like strategy that allowed all unicode_strings to be backed by a CFString. There was a get_native() method that returned a platform-specific value (documented on a per platform basis) to allow platform-specific code to work more optimally. Just some thoughts... Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[Unicode strings] We're off
by Erik Wien 06 Apr '05

06 Apr '05

Hi. I hope you guys still remember this, despite my lack of activity on this list, but I was here about developing a Unicode library for Boost a while back, and well.. We're off! :) We are now at a point in the development where we would really appreciate feedback from you Boosters. We have developed a *very* early prototype based on some of the ideas put forward in the earlier discussion here, and we would like you guys to comment on it. The design is by no means locked, and only represent one possible way to implement a Unicode string class. If you have an alternate solution, please let us know. We are using an evolutionary development model (prototyping), so we are open for design changes should there be a need for that. You can download the source code (VC++/DevCpp projects only for now, sorry) from our site here: http://hovedprosjekter.hig.no/v2005/data/Gr5_unicode (the files section). On the same site we have also set up a forum where you can discuss different aspects of the project if you want to keep it off list. No registration is required, so it should be hassle (password) free. Current design: The current design is based around the concept of «encoding_traits». These are templated on the different encodings used in Unicode (UTF-8, 16 and 32, both endians), and provide functions and typedefs for working on code units (8, 16 and 32 bit integers respectively) in any encoding. These traits are then used for implementing different interfaces that externally use 32bit code points, thereby abstracting away the underlying encoding. The string class itself is created with encoding transparency in mind. Also at the class level. This means that the encoding used in the string is not a template parameter of the string class itself (making each instantiation of the string it's own type), but rather a parameter of an implementation class that is used internally to hold the string. Something like this (highly simplified): class impl_base { // A lot of pure virtual functions for manipulating a string. }; template<typename encoding> class impl { // Implement the functions...obviously. }; class encoded_string { impl_base* m_impl; template<typename encoding> void set_encoding(encoding enc_tag) { m_impl = new impl<encoding>(); } }; The reason for doing this is that it allows functions that take encoded_string parameters to be blissfully unaware of what encoding they are working on, without having to templatize (it that a word?) the function itself. (Something I understood was a bit of a worry for some in the last discussion.) An alternate way of doing this (something we also tested when developing the current version), is to simply template the string class itself on encoding, but then you loose the above advantage of being able to have non-template functions working on multipe encodings. You do however gain speed (I would assume), since you wouldn't have the overhead of virtual function-calls, as well as a less complex implementation. There's also an implementation of the Unicode Character Database in the prototype, along with an implementation of the normalization algorithms, but I won't go into the details of them here (to keep this from becoming a novel). Should be easy enough to understand if you want to. Anyway.. Comments are as always welcome. Either here, or in the forum at the site. Regards - Erik To Eric Niebler: Did you recieve the mail I sendt you a while back about the whole contact-person debackle? (on the Boost Consulting address) Never got a reply, so I'm not sure if it went through.

10 58

Logo: why not drop IRV?
by christopher diggins 06 Apr '05

06 Apr '05

I had an idea, let's drop IRV. Clearly it is too much work to manage. It's not like we're voting for a president. It's just a silly little logo, it isn't going to change our lives. Thoughts? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

Re: [boost] Re: logo contest status query
by Iain Hanson 06 Apr '05

06 Apr '05

On Wed, 2005-04-06 at 10:56 -0400, David Abrahams wrote: > Joel <joel(a)boost-consulting.com> writes: > > > Comments? Objections? > > > > <<My, this contest was not as simple as it seemed at first :P>> > > This doesn't directly address the issue, You may not remember this but > there was a growing consensus at the end of the contest that we > probably ought to try again given everything we had learned... That was my understanding also. > as such > I didn't bother to send you my revised votes. ditto. /ikh

1 0

Re: Asynchronicity (long)
by Don G 06 Apr '05

06 Apr '05

Hi Maxim, While we are coming from different sides on this, I do want to thank you for your input on libevent and epoll. It is a positive contribution to the discussion. Please see below for my replies. > But I also know that modern monster sites like > http://www.livejournal.com/ would not be possible > without epoll. (Well, I may be exaggerating a > little). <snip> I believe that an epoll-based implementation (not an exposed interface) would be one of the most likely. I'm really not dis'ing epoll's use, just where it is used. > Having said that, nowadays epoll support is a > requirement for any linux which is going to be > used in any decent networking. That is good news for the Linux platform, but it doesn't change things in the general case. > select bit manipulation is ugly and boring. poll > is much better. epoll is pretty much as simple as > one can get. I agree with the progression of better-ness all the way to "as simple as one can get". I think it can be much simpler. > This is what I'm talking about - my problems were > solved long time ago. I'm happy with a C-style > callback taking void* in libevent. And it's trivial > to wrap it to make it accept and callback arbitrary > function objects. I've been already living in a > perfect world... I guess a "perfect corner of the world" would be more accurate :). libevent is GPL, which for me is a full stop on its use and I cannot (politely<g>) say just how much I dislike C driving my C++ programming. While I came from a C background, I want to see pure C++ solutions for my problems. They are safer, easier to understand, use and maintain, but let's not get into a debate on such ethereal issues in this space. I think most folks using boost would agree: GPL evil, C bad, C++ good. ;) Best, Don __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

4 4

Re: [boost] shared_ptr on ppc?
by Michael D. Crawford 06 Apr '05

06 Apr '05

I have an OS X Mac with CodeWarrior 8.3 and some version of Apple's XCode. Let's see, g++ --version says it's 3.3. I also have a PowerPC mac running Debian Linux for PowerPC. Have you looked at the ZRef from ZooLib? It's thread safe, and supports CodeWarrior and g++ on PowerPC. It also supports some other platforms: http://www.zoolib.org/ Let's see if I can find the file you need... ZAtomic.h http://cvs.sourceforge.net/viewcvs.py/zoolib/zoolib/src/foundation/ZAtomic.… ZAtomic.cpp http://cvs.sourceforge.net/viewcvs.py/zoolib/zoolib/src/foundation/ZAtomic.… Look also in ZRefCount.h and ZRefCount.cpp in http://cvs.sourceforge.net/viewcvs.py/zoolib/zoolib/src/foundation/ ZooLib has the MIT License. Michael D. Crawford crawford(a)goingware.com Read "GoingWare's Bag of Programming Tricks" at http://www.goingware.com/tips/

2 1

Is there any interest in a Factory Pattern library?
by Federico Stella 06 Apr '05

06 Apr '05

Is there any interest in a simple Factory Design Pattern library? It uses a template based factory that register creator using an identifier and create object based on that identifier. Object could be default constructed or via typed_in_place_factory. Creator handle allocation using an allocator. If there is any interest I could upload the library with the documentation. Federico.

3 4

everything is [rational]
by Andras Erdei 06 Apr '05

06 Apr '05

whenever we do arithmetic, we are doing some kind of rational arithmetic: - integer arithmetic is rational arithmetic with all denominators equal to 1 - fixed point arithmetic is rational arithmetic with all denominators being a pre-specified constant - floating point arithmetic is rational arithmetic with denominator values limited to powers of 2 (e.g. 1/3 is represented as 11184811/2^25) - finite rational<> arithmetic is rational arithmetic with denominator values limited to a given range the first three does rounding, so the rule of thumb "behave like int" suggests rational<> should do the same. if we do not do rounding, we have to have some very good reasons for not doing it. br, andras

1 0