April 2005 - Boost - lists.preview.boost.org

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

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

06 Apr '05

Hi Maxim, --- Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: >> libevent is GPL > > My current understaning that it is not. Am I wrong? I tried to verify my statement and couldn't find it either. It looks like I am mistaken, and I do apologize. The code contains this, but I couldn't find a LICENSE file or explicit statement on their web page: * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission. Not quite as free a license as Boost, but I don't know where I got "GPL". Oops. Best, Don __________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest

1 0

Re: [boost] Re: [filesystem] Can't compile on Tru64/gcc
by Iain Hanson 05 Apr '05

05 Apr '05

On Mon, 2005-04-04 at 20:51 -0400, Beman Dawes wrote: > "Jonathan Wakely" <cow(a)compsoc.man.ac.uk> wrote in message > news:20050404134320.GA88664@compsoc.man.ac.uk... > [snip] > This is the first time I've ever used the POSIX config mechanisms, so I may > have it wrong. I'll check... Hum... I find the POSIX docs for sysconf() > pretty impeneratable regarding the return value. I can see why I took >=0 to > be needed, but I could also read it in a way that >0 would be OK. > > Any POSIX experts out there? > Not a posix expert but the linux man page seems fairly clear: <quote> For options, typically, there is a constant _POSIX_FOO that may be defined in <unistd.h>. If it is undefined, one should ask at run- time. If it is defined to -1, then the option is not supported. If it is defined to 0, then relevant functions and headers exist, but one has to ask at runtime what degree of support is available. If it is defined to a value other than -1 or 0, then the option is supported. Usually the value (such as 200112L) indicates the year and month of the POSIX revision describing the option. Glibc uses the value 1 to indicate support as long as the POSIX revision has not been published yet. The sysconf() argument will be _SC_FOO. For a list of options, see posixoptions(7). </quote> /ikh

1 0