- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1178259 ] Muss of "host" and "target"
by SourceForge.net 07 Apr '05

07 Apr '05

Bugs item #1178259, was opened at 2005-04-06 21:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178259&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Muss of "host" and "target" Initial Comment: When I try build boost for crossplatform compiler (i386-mingw32msvc-gcc) on linux host. When I set tool to mingw, jam try build ".so" libraries (I use hack for set $OBJCOPY to i386-mingw32msvc-objcopy). When I set WINNT variable, jam try use windows directory delimiter. And in any case it fails build ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178259&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] large file support detection broken on Solaris (possibly others)
by Caleb Epstein 06 Apr '05

06 Apr '05

The file "operations_posix_windows.cpp" in the filesystem library defines the macro _FILE_OFFSET_BITS=64 in an attempt to enable large file support on POSIX platforms. Unfortunately, this definition comes too late for it to work properly on Solaris, so Boost.Filesystem incorrectly reports that large file support is unavailable (cf. http://tinyurl.com/44jvy) The _FILE_OFFSET_BITS macro definition needs to happen before the inclusion of <sys/types.h>, but this system header is being pulled in courtesy of <boost/config.hpp> which is included by <boost/filesystem/config.hpp>. I'm attaching the output of g++ -H on this file which lists header files as they are included, along with a nesting depth so you can see what is going on. Can this macro definition just be moved before any other includes? I think it should be harmless on any non-POSIX platform. I think defining it before ANY header is included or on the compiler command-line is the only way for to make this work reliably. -- Caleb Epstein caleb dot epstein at gmail dot com

2 6

[Boost-bugs] [ boost-Bugs-1178092 ] std::locale construction slows down convert_to_lower()
by SourceForge.net 06 Apr '05

06 Apr '05

Bugs item #1178092, was opened at 2005-04-07 00:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178092&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Melnikov (nimnul) Assigned to: Jeff Garland (az_sw_dude) Summary: std::locale construction slows down convert_to_lower() Initial Comment: Replacing std::locale loc(""); with static const std::locale loc(""); improves speed a lot in VC7.1 and VC8.0 beta ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178092&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1178068 ] Past-the-end tokenization in parse_date()
by SourceForge.net 06 Apr '05

06 Apr '05

Bugs item #1178068, was opened at 2005-04-06 23:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178068&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrey Melnikov (nimnul) Assigned to: Jeff Garland (az_sw_dude) Summary: Past-the-end tokenization in parse_date() Initial Comment: Loop termination condition is wrong. Comma is used instead of and operator: for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end(), pos < spec_str.size(); ++beg, ++pos) Should read as for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end() && pos < spec_str.size(); ++beg, ++pos) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1178068&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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