March 2004 - Boost - lists.preview.boost.org

boost isnan/isinf/etc...?
by Matthias Schabel 05 Mar '04

05 Mar '04

For numeric code these functions are indispensible but, since they're C99, they are technically C++ verboten. It seems to me that it would be worthwhile to add them to boost::math - they could probably just be cut-n-pasted from the C99 gcc headers... Matthias ------------------------------------------------------------------------ --------------------------- Matthias Schabel, Ph.D. Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) mschabel at ucair med utah edu

3 2

Re: GUI library - another one
by Robert Ramey 05 Mar '04

05 Mar '04

I believe similar discussions were engaged some time ago and that these discussions resulted in: http://sourceforge.net/projects/notus/ What to the participants in these other discussions have to add? Robert Ramey

5 6

Re: whither the order language
by hartmutkaiser＠t-online.de 05 Mar '04

05 Mar '04

Vesa Karvonen wrote: > Ronald Garcia wrote: > >Where can I find a copy of the Order preprocessor language? The Boost > >files section seems to have examples of its use, as well as a manual, > >but I don't seem to see the implementation. > > I removed the Order interpreter implementation from the files section some > time ago, because it had changed significantly due to the discovery of a > couple of techniques for removing certain practical limitations. The > documentation and examples mostly reflect the current Order interpreter, > but as I have not been working on the implementation for some time, the > interpreter is not ready for publication. If you are really interested, > then I could e-mail you a snapshot of the interpreter. > > The current Order interpreter also uses C99 preprocessor features, namely > variadics and placemarkers, so it is not immediately useful for C++ > programming. The latest GNU CPP and the Wave library are known to be able > to preprocess the Order interpreter. Other preprocessors have not been > tested, but it should be possible to port the interpreter to most (more or > less buggy) preprocessors that support the C99 extensions. Yes, I'm interested in getting the latest version of your Order library, since I'm still using it as one of my test cases for Wave. Could you please send it to me? Regards Hartmut

1 0

Serialization17 - assert in basic_text_oarchive.hpp
by Jeff Flinn 05 Mar '04

05 Mar '04

Robert, My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with delimiter = 3 when serializing to a text_oarchive. The assertion occurs during serialization of the count for a shared_ptr. There is an access violation when attempting to serialize to a binary_oarchive also. XML serialization in both directions works fine. The odd thing is, if I comment out any usage of xml_oarchive, the assertion is not triggered, and serialization to both text_oarchive and binary_oarchive succeeds. Input from binary/text/xml succeeds in all cases. I'll try to diagnose further. This is all with vc7.1, both the exe and libs are compiled with static multi-threading library flags (/MT). Any thoughts? A quick perusal of the test suite doesn't show any cases using multiple oarchive types within a single test. Thanks, ----------------- Jeff Flinn Applied Dynamics, International

1 0

RE: [boost] whither the order language
by Vesa Karvonen 05 Mar '04

05 Mar '04

Hi, Ronald Garcia wrote: >Where can I find a copy of the Order preprocessor language? The Boost >files section seems to have examples of its use, as well as a manual, >but I don't seem to see the implementation. I removed the Order interpreter implementation from the files section some time ago, because it had changed significantly due to the discovery of a couple of techniques for removing certain practical limitations. The documentation and examples mostly reflect the current Order interpreter, but as I have not been working on the implementation for some time, the interpreter is not ready for publication. If you are really interested, then I could e-mail you a snapshot of the interpreter. The current Order interpreter also uses C99 preprocessor features, namely variadics and placemarkers, so it is not immediately useful for C++ programming. The latest GNU CPP and the Wave library are known to be able to preprocess the Order interpreter. Other preprocessors have not been tested, but it should be possible to port the interpreter to most (more or less buggy) preprocessors that support the C99 extensions. Regards, Vesa Karvonen _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

[serialization] non-conformance in collection_load_imp.hpp
by Joaquín Mª López Muñoz 05 Mar '04

05 Mar '04

"serialization/collections_load_imp.hpp" defines a private template class stack_allocate for stack-based reservation of uninitialized memory. To the best of my knowledge, the way it does so is not std-conformant due to alignment issues. Fortunately, (undocumented) "boost/aligned_storage.hpp" provides a template class named aligned_storage which handles the issue, so I guess the problem can be solved by just using this facility instead of stack_allocate. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: GUI library - another one
by E. Gladyshev 05 Mar '04

05 Mar '04

--- Robert Ramey <ramey(a)rrsd.com> wrote: It seems that my post didn't make it through. I got the Boost post acknowledgement but the message did not appear on the list. I am trying to use another e-mail account. If the mailing list moderators would like to look into this problem, please e-mail me privately so I could give you my account information. Thanks. Anyway back to the GUI stuff. > I believe similar discussions were engaged some time ago and that these > discussions resulted in: > > http://sourceforge.net/projects/notus/ > > What to the participants in these other discussions have to add? Well, I am quite happy with the direction notus is taking but there is a lot to be done. First I'd like to comment on the issue of simplicity. Simplicity is great but IMHO, it should NOT be of concern of the core GUI design. The higher layers could simplify the core interface any way they like. Like another poster pointed out if a feature is missing it could easily be a showstopper. It is like missing a letter in the alphabet. The primary concern of the core GUI design should be consistency, *scalability* and feature support. I think that the discussion of the syntax like using operators '<<' or '[]' and so on is important but it is a secondary issue. I think that what we are missing a consistent fundamental GUI design. All this syntactic sugar or XML support could be added at a latter stage. Most of the GUI frameworks with their endless polymorphic hierarchies and castings are not fun anymore. :) The fundamental GUI library doesn't have to support all possible features right from the start. It is more important to identify all fundamental features and architectures that will let you to scale the framework up with new features. Usually a GUI feature is not a standalone thing. It relies on presence of other features. A good GUI library should identify a set of *fundamental* features and architectures that will let the library grow vertically and orthogonally. Notus is based on what we call MDS (the DDV terminology will be deprecated). Model - application data Display - physical device such as window, button Strategy - user defined behaviors template <typename Model, typename Display, typename Strategies > struct view {...} A typical strategy looks like this struct my_strategy : handle_event<mouse> handle_event<paint> { template< typename View > void on_event( View& v, mouse& e); template< typename View > void on_event( View& v, paint& e); }; As you can see, the strategy event handlers take the event source (View) as a template parameter. So as soon as the View provides the interface that is required by this strategy, it doesn't care what View really is. So strategies can be used as interchangeable components. Strategies can be combined and reused. typedef view< my_data, displays::window, tuple<my_strategy> > my_window; //customize my_window typedef view < my_data, displays::window, tuple<my_customization, typename my_window::strategy> > my_custom_window; //my_custom_window reuses all strategies that are defined in my_window; I'd like to note that notus doesn't have any casting stuff and almost no polymorphism. The idea is to create a *generative* framework where components can be constructed from a set of interchangeable and custom parts. I'd like to touch the issue of ownership. The core Notus doesn't care about ownership at all, the physical devices such as windows, buttons, etc. are represented by Displays. One display can be connected to one or more other displays so that it will get events generated by the displays that it is connected to. So at this level, it is a *network* of display connections not an ownership hierarchy. I anticipate your question about what happens when the display's "physical" owner is deleted. Nothing really except that all the connections to the deleted display are lost. *Important* the displays don't keep direct references to other displays. I appreciate your comments. Eugene

1 0

boost::lexical_cast optimizations
by Val Samko 05 Mar '04

05 Mar '04

At the moment, boost::lexical_cast is about 70 times slower than corresponding C functions (at least with VC++ with all the optimizations enabled) for integer and floating point types (see my benchmark below). Is it possible to add boost::lexical_cast specializations for std::string, integer and floating point types? Val Samko === Benchmark code ==================== Output: VC++ 7.1: atoi: 1297ms vs lexical_cast: 79703ms g++ 3.3.3 (mingw): atoi: 1547ms vs lexical_cast: 148078ms #include <boost/lexical_cast.hpp> #include <iostream> #include <string> #include <windows.h> int main() { std::string s = "25413248"; int r; int REPEATS = 20000000; DWORD c1 = GetTickCount(); for (int i = 0; i < REPEATS; ++i) r += atoi(s.c_str()); DWORD c2 = GetTickCount(); for (int i = 0; i < REPEATS; ++i) r += boost::lexical_cast<int>(s); DWORD c3 = GetTickCount(); std::cout<<"atoi: "<<(c2-c1)<<"ms vs lexical_cast: "<<(c3-c2)<<"ms "<<std::endl; }

1 0

whither the order language
by Ronald Garcia 05 Mar '04

05 Mar '04

hi, Where can I find a copy of the Order preprocessor language? The Boost files section seems to have examples of its use, as well as a manual, but I don't seem to see the implementation. Thanks, ron

2 1

[preprocessor] warnings on VC6
by Jonathan Turkanis 05 Mar '04

05 Mar '04

When I compile the following simple program on VC6: #include <boost/preprocessor/facilities/empty.hpp> #include <boost/preprocessor/punctuation/comma_if.hpp> #define PARAM(has_param) BOOST_PP_IF(has_param, typename Param, BOOST_PP_EMPTY()) #define MACRO(has_param) \ template< PARAM(has_param) BOOST_PP_COMMA_IF(has_param) typename T> \ struct name { }; \ /**/ MACRO(0) int main() { return 0; } I get the following warnings: warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF' warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF_I' warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF_0' It works fine on other compilers. Am I missusing the preprocessor library, or is this a problem with VC6? If the latter, is there a workaround, or should I just turn off warning 4003? Jonathan

3 9