Re: [boost] Configuration for Intel compiler
Guillaume Melquiond wrote: Yes, this time the conditional is correct. Unfortunately, this patch is still not good: __ICL is not defined so it doesn't work. My version of the compiler (the standard version available on Intel's website) does not define __ICL, but only __ICC and __INTEL_COMPILER. So the patch is still not enough. As a matter of fact, what is the meaning of ICL? For ICC, it's easy: it's the acronym of Intel C Compiler. But for ICL, I don't know. By doing a grep on the Boost source tree, I also saw a lot of place where only __ICL is tested and not __ICC. If they are supposed to have the same meaning, maybe all the occurences of __ICC and __ICL should be replaced by a common macro: BOOST_INTEL_CXX_VERSION (or maybe a shorter version like BOOST_INTEL). As long as you're trying to get the Intel compiler predefined macros straight, please note that it defines __ICC only for the IA-32 version. For the Itanium version, the compiler defines __ECC. That is why they deprecate both and recommend using __INTEL_COMPILER instead. I understand that you may need to support all three for the purposes of older versions of the compiler. I don't know when they introduced __INTEL_COMPILER. -- Dick Hadsell914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost implementation of the Library TR?
Beman Dawes wrote: * What if the committee changes the namespace? Hum... That could happen. Maybe we should use a macro to make it easy to change. A macro would be ugly, unless it looked just like the namespace. Can you define a macro to make std::tr1 be equivalent to std::tr2? Can't you do something that imports all of the new namespace into the old namespace, so that people could make the change (or not) to the new namespace gradually? -- Dick Hadsell914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
David B. Held wrote: So those arrays never get resized? No, but if they did, I could use the swap function to move the pointers from the old array to the new one. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
Greg Colvin wrote: And I don't see a problem with adding constructors to scoped_ptr that support custom deallocation, especially since C++ has no 'finally' construct. Although someone mentioned this earlier, I have not seen it reiterated -- if the size of scoped_ptr grows to more than just the pointer itself, I can not use it. I imagine that others also need it to remain simple, at least in this respect. If someone adds anything to scoped_ptr or scoped_array that increases its size, I hope he/she will give it a new name, so that I can continue to use the current classes. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fw: Why scoped_ptr dost provide custom deallocation?
Alisdair Meredith wrote: I am curious why the size of scoped_ptr matters so much? I certainly worry about the size of shared_ptr as I may store many of them in containers. However, this is not possible with scoped_ptr so I am curious about usage where size might still matter? [Whenever I think I have the hang of these things, someone goes and points out the obvious case I'm missing! The more you look into smart pointer, the more you understand why the debates never end!!] Our application is a raytracing renderer. Storing data for each object encountered in a scene that contains ~100,000 objects is a problem. Some of the data are in scoped_arrays of scoped_ptrs. If we had to double the size of those arrays just to get a feature that we don't need, I would copy the current scoped_ptr code and make it my own. I couldn't take the memory waste, even if it were only another 50 MB. We work very hard in every other way to use memory frugally, so that we can support larger scenes, which our users continually demand. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST:SSTREAM:ERROR WHILE COMPILING
Pavan Kumar wrote:
Hi All,
I am a newbie to boost libraries. Just a small query :
Using the sstream.h library file provided at gnu.org for the
regex example program, I am getting an error as follows :
regex_merge_example.cpp: In function `int main(int, const char **)':
regex_merge_example.cpp:74: `::ostringstream' undeclared (first use here)
regex_merge_example.cpp:74: parse error before `('
regex_merge_example.cpp:75: `t' undeclared (first use this function)
regex_merge_example.cpp:75: (Each undeclared identifier is reported only
once
regex_merge_example.cpp:75: for each function it appears in.)
Did you mean to include sstream or sstream.h?
Try std::ostringstream instead of ostringstream.
--
Dick Hadsell914-259-6320 Fax: 914-259-6499
Reply-to: [EMAIL PROTECTED]
Blue Sky Studioshttp://www.blueskystudios.com
44 South Broadway, White Plains, NY 10601
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
