- Boost - lists.boost.org

Comment regarding __GNUC__ spoofing
by Beman Dawes 05 Mar '04

05 Mar '04

In discussions with the Intel folks about their spoofing of __GNUC__ on Linux, Clark Nelson pointed out that Boost code should be much more careful about use of any predefined compiler identification macro, because there is nothing to prevent any compiler in the future predefining compiler identification macros used by other compilers. Scary as it is, he is right AFAICS. There are two cases I can see for checking a compiler identification macro: * The code wishes to see if it is safe to use an extension feature such as a pragma or compiler intrinsic provided by the compiler indicated by the macro. This is reasonably safe in that presumably the reason the actual compiler is pretending to be a different compiler is to indicate feature compatibility with the spoofed compiler. * The code wishes to apply a workaround for a bug in the spoofed compiler. This usage is fraught with possible problems. The actual compiler may or may not have the same bug. If not, useful functionality may be needlessly disabled or the workaround may not even work. We deal with _MSC_VER in various compilers by defining BOOST_MSVC if it is actually the Microsoft compiler. We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather than BOOST_GCC. To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers. --Beman

6 7

Re:[boost] [serialization] non-conformance in collection_load_imp.hpp
by Robert Ramey 05 Mar '04

05 Mar '04

Joaqu?n M? L?pez Mu?oz wrote: >"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. This has been mentioned before. I was unable to find any information other than the code itself which wasn't all that transparent to me. And the stack allocate was soooooo simple. Is aligned_storage part of boost? Is it documented anywhere? Is it part of any test suite? Has it been tested for portability? In general I would prefer a boostified component over a homebrew one. I'm really not sure of what the status of aligned_storage is. Also, the nameitself didn't make it clear to me that its intended purpose was identical to that implemented by stack_allocate. Robert Ramey

2 1

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