[boost] Re: pool benefit ratio for different compilers
"Bohdan" <[EMAIL PROTECTED]> wrote > > All boost::pool library is about allocation of small objects > of the same size. I'm just curious how malloc can be > accelerated if it handles different size allocations? > May be boost will also need something like that. > I understand that "char" can be treated as small object, > but i'm not sure if boost::fast_pool_allocator gives any acceleration > in this case. > malloc() cannot be accelerated very much: free() is missing information about allocated memory block size. new/delete probably won't be accelerated a lot using some pool management - new libraries took car of it already. I did comparison of Alexandrescu's SmallObjAllocator<> versus up-to-date allocators and found them much better. They ( Borland 6.0, Visual C++ 6.0 and Intel 6.0) use pools for small objects and are also _significantly_ faster than even hand tuned C++ code. I assume they are coded in assembler. The only exception I found was Linux GCC 2.94: SmallObjAllocator<> here has better characteristics (both speed/memory). /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost release compressed by bzip2
Bandwith and time of those with dialup can be saved by compressing Boost release by BZIP2 compressor (http://sources.redhat.com/bzip2/). For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed by bzip2 size is 4 282 kB (down to 81%). Boost size will grow (Spirit lib has over 600kB) and bzip2 can reduce the growth a bit. Bzip2 is available on many platforms, free to use, stable and quite used. /Pavel _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] statistics
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 03:05 PM 11/29/2002, Pavel Vozenilek wrote: > > >Bandwith and time of those with dialup can be saved by compressing Boost > >release by BZIP2 compressor (http://sources.redhat.com/bzip2/). > > [snip] > Regardless, thanks for bringing it up. I've been wondering if bzip2 was > becoming a commonplace format. > Statistics for first 15 projects from SourceForge, keyword C++: Compressed downloadable files: - ZIP files: 250 - GZ files: 212 - BZIP2 files: 50 No other general purpose compressors were used (there were few Mac specific files and some RPM). 4 out of 15 projects provided BZIP2 compressed files. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: statistics
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [snip] > > If I understand you correctly, those are counts of the number of files. > Yes. The visible tendency is to provide all formats: zip/gz/bzip2. Previous releases typically come with only zip/gz and this skews statistic a bit. Bzip2 is catching on lately. > It would also be interesting to look at the download counts for projects > which make several formats available. > SourceForge, for what I know, doesn't provide statistics breakdown on single files. > In other words, what formats do users prefer to download when several are > available? > Question for SourceForge staff, if exact number is needed. I personally always pick the smallest file available. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_abstract_class type trait
Rani Sharoni posted one possible implementation on http://tinyurl.com/459q (c.l.c++.m, 2002-07-11, topic 'is_abstract_class implementation!'). The implementation depends on border-case C++ feature (more in Rani's text). I compiled it sucessfully with Comeau online compiler. It may be considered as addition to type_traits library, after the standard settles on it. is_abstract_class may be useful e.g. to enforce "don't derive from non-abstract classes" constraint. /Pavel _ MSN 8: advanced junk mail protection and 2 months FREE*. http://join.msn.com/?page=features/junkmail ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Small thing: yes_type and no_type made public?
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message 031901c2b661$a1f9c9a0$cb6c6f50@pc">news:031901c2b661$a1f9c9a0$cb6c6f50@pc... > The types yes_type and no_type (or equivalent) - that is, two types which > are guaranteed to have different size - [snip] > By the way, these are defined as char and double, respectively. Are these > required to have different size? I haven't found that guarantee in the C++ > or C standard. Theoretically, you might have an architecture which operated > only on values of one size, so that char and double would have the same > size. > > In that case, maybe something like this could be safer: > > typedef char yes_type[1]; > typedef char no_type[2]; > > There are many variants, e.g.: typedef double yes_type; typedef yes_type no_type[2]; /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] function_traits.hpp: a little inconsistency
(Boost 1.29): File type_traits/function_traits.hpp includes other headers using #include <...> convention. All other sources use #include "..." convention. Maybe it can be made consistent accros the library. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost preprocessor library
- Original Message - From: "Edward Diener" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.lib.boost.devel Sent: Monday, January 13, 2003 6:43 PM Subject: Re: Boost preprocessor library [snip] > I see many pre-processor macros in the reference section of the > documentation but I don't see any good overview explaining the various > macros or groups of macros and the ideas behind them. [snip] The "Topics" section gives the overview, just follow the individual pages in their order. The docs is IMHO very well written. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Boost preprocessor library
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Edward Diener" <[EMAIL PROTECTED]> writes: > [snip] > Something along the lines of: > > "The Boost PP lib is a (mostly) functional programming system built > around the C/C++ preprocessor. ... [snip] High level overview should IMO concentrate what the library can be used for, something like: "The Boost PP lib can be used for ... and ... but not ... " People who skim over the info may choose whether to look deeper into it or not. If they do, they will be more focused. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
"Steven Mauceri" <[EMAIL PROTECTED]> wrote in message 000f01c2c301$fca17ae0$[EMAIL PROTECTED]">news:000f01c2c301$fca17ae0$[EMAIL PROTECTED]... > Hi Andreas, > [snip] > Some things ive come across include: > [snip] Undo library may also provide features like: - user friendly description of what is going to be undoed/redoed, - ability to keep only N last undo steps in memory and save rest on disk (maybe with help of an serialisation library), - ability to group multiple undo commands to one (e.g. moves), - ability to generate 'change log' for any given time period. Most of it may be implemented by specialised command manager. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message b0pu01$bqd$[EMAIL PROTECTED]">news:b0pu01$bqd$[EMAIL PROTECTED]... > Al Stevens has an article in a past DDJ about a generic undo/redo library, > can anyone dig it out? I recall it was interesting. > Can be purchased here: https://www.sdmediagroup.com/secure/?sid=954 and followup here: https://www.sdmediagroup.com/secure/?sid=914 /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: undo library
"Ihsan Ali Al Darhi" <[EMAIL PROTECTED]> wrote in message 01d001c2c2ba$6af14ea0$73c721d4@h8p7o2">news:01d001c2c2ba$6af14ea0$73c721d4@h8p7o2... > Can I use this library to implement multiple undo/redo in GUI applications > under Windows? For example in a word processor. > Undo/redo is generic mechanism that can be used for whatever purpose. Undo/redo in wordprocessors/graphics editors is the most common case. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_abstract_base ?
"Robert Ramey" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Is there such a thing as is_abstract_base similar to is_polymorphic ? > > Is such a thing possible? I could use it but have been unable to figrure > out how to do it. > Rani Sharoni wrote is_abstract_class type trait (see on http://groups.google.com/groups?q=is_abstract_class&hl=en&lr=&ie=UTF-8&oe=UT F-8&selm=df893da6.0207110613.75b2fe90%40posting.google.com&rnum=1). It compiles on Comeau, Intel C++ 7.0 and VC++ 7.1beta. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shifted_ptr<> w/ lock mechanism
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > From: "David Abrahams" <[EMAIL PROTECTED]> > >> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > >> > >> > Lock mechanism was added to shifted_ptr<>: > >> > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > >> > > >> > Benchmarks are also updated. Still shifted_ptr<> is using less memory > > and > >> > twice faster for reconstruction time. > >> [snip] > > One easy way to estimate the impact of an optimized allocator is to #define > > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI > > derived STLs, std::allocator is usually faster than plain new. > > Yeah; I'm pretty sure that my specialized allocator was faster still, > since it just allocated fixed-sized blocks and linked them back into a > free-list. It was pretty trivial to implement on top of a std::deque > of POD unions. > Latest C++ compilers come with fairly good allocator for small object . I played with Loki's SmallObjAllocator and even heavily sped up version didn't match the native allocators used in BCB or Intel C++ (being still 30% slower and no MT safety). I guess small object optimisation was already provided, maybe mixed together with tricks as assembler optimisation or cache wizardry. OTOH GCC 2.95.* was significantly slower than Loki. $0.02 /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [optional] two problems with BCB 6 and 1.30b
I use Borland C++ Builder 6, update 4, STLPort 4.5.1 (provided by Borland) and Boost is 1.30.0beta1. Following snippet of code fails: - #include #include void foo(const boost::optional >& aux = boost::optional >()) {} int main() {} - with error message: [C++ Error] Unit1.cpp(12): E2188 Expression syntax [C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization from '_STLD::pair<_T1,_T2>' [C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization from 'boost::optional' [C++ Error] Unit1.cpp(13): E2257 , expected [C++ Error] Unit1.cpp(33): E2151 Type mismatch in default value for parameter 'aux' [C++ Error] Unit1.cpp(12): E2293 ) expected The same code compiles OK with Intel C++ 7.0. If I use typedef it works OK with both BC++B and Intel C++: - #include #include typedef boost::optional > AType; void foo(AType aux = AType()) {} int main() {} - Borland also fails with this construct: - #include int main() { boost::optional aux(0); if (aux && *aux == 0) { aux.reset(1); } } - with this error message: [C++ Error] Unit1.cpp(24): E2094 'operator&&' not implemented in type 'boost::optional' for arguments of type 'bool' Intel C++ 7.0 compiles and executes this snippet OK. This works in BC++B: - #include int main() { boost::optional aux(0); if ((!!aux) && *aux == 0) { aux.reset(1); } } - These problems may be caused by bugs in BC++B compiler. Sorry if this problem was already spotted. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] two problems with BCB 6 and 1.30b
- Original Message - From: "Fernando Cacciola" <[EMAIL PROTECTED]> > > Following snippet of code fails: > > - > > #include > > #include > > > > void foo(const boost::optional >& aux = > > boost::optional >()) > > {} > > > > int main() {} > > - [snip] > Hmm.. > I can't reproduce the problem here with the 1.30.0 release, > BCB6, update 4, from within the IDE. > Which command line options are you using? > The BCB flags are: CFLAG1 = -Od -H=$(BCB)\lib\vcl60.csm -Hc -Vx -Ve -X- -r- -a8 -b- -k -y -v -vi- -tWC \ -tWM- -c IDLCFLAGS = -IC:\Temp\optional_test -I$(BCB)\include -I$(BCB)\include\vcl \ -IC:\Work\Editor\3pp\boost_1_30_0 -src_suffix cpp -D_DEBUG -boa PFLAGS = -$YD -$W -$O- -$A8 -v -JPHNE -M RFLAGS = AFLAGS = /mx /w2 /zd LFLAGS = -D"" -ap -Tpe -x -Gn -v It is normal console IDE project in BCB Enterprise, using default options. It fails with 1.30 as well here. I may send you the whole project if you want. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
"Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Russell Hind wrote: > > WinAPI Note: we can get a higher resolution using the > QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution > info is required) > It is (was) not completely reliable: see Q274323 bug in MS Knowledgebase: "Symptoms: The result that is returned by the QueryPerformanceCounter function may unexpectedly leap forward from time to time. This leap may represent several seconds." The MSDN article specifies what HW can cause the problem and how to work it around. /Pavel PS: my experience with this API is positive, I got resolution cca ~1 microsecond and the call overhead was tiny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in a member function pointer -> functionpointerconverter? (a la boost::function)
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [snip] > int main() > { > function_ptr fn; > > // The rest the same > > A a; > int r=fn(&a, 3); // sets r to 9 > } > Is it similar (in principle) to http://www.code-genie.com/cpp/articles/events/events.html (long text)? /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Better Intel-Win32 support
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not so > worried about ADL, at least with VC++ <7.1. > You may look on test table http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864. (Warning : when playing with options I managed to break something in compiler configuration and as result compiler decided to define macro indicating wchar_t support _always_.) /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Better Intel-Win32 support
"John Maddock" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > That will certainly work, but you shouldn't have to do that since the > > compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier > this > > afternoon I am able to compile some non-boost code correctly which had > > previously be failing. > > Just let me jump in here: you absolutely can not use _WCHAR_T_DEFINED to > detect native wchar_t support: the windows headers will define this when > wchar_t has been defined as a typedef (and wchar_t is not a native type). > There appears to be no way to actually tell whether wchar_t is a native type > or not with Intel. > Is is possible to post tiny example which fails? /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [lexical_cast] performance related feature
lexical_cast<> constructs and destroys std::stringstream (including dynamic memory allocation/free.) each time a conversion is done. Maybe specialised version of lexical_cast<> can be developed which takes external, existing stringstream instance as template parameter and reuses it. Very rough idea: template Target lex_cast(Source s) { // clear ss ss << s; Target t; ss >> t; return t; } extern std::stringstream ss; std::stringstream ss; ... int a = 99; std::string s = lex_cast(a); /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Quantity library: any interest?
I wrote Quantity library some time ago and wonder whether it may get added into Conversion library. If anyone gets interested I will Boostify and submit it. Quantity library is used to get safe conversions between different physical units (like between Celsius and Farhernheit degrees). Instead of bare number you have specific type and conversion rules are applied automatically. Example: typedef struct { float value; } speed_km_per_hour_t; typedef Quantity < float, // numeric type to represent speed in meter/sec speed_km_per_hour// alternative representation > speed_meters_per_sec_t; // conversion rule: define them when it makes sense void convert_quantity(const speed_meters_per_sec_t& from, speed_km_per_hour_t& to) { to.value = from.value * 3.6; } int main() { speed_meters_per_sec_t m_p_s(10); speed_km_per_hour_tkm_p_h; km_p_h = m_p_s;// OK // m_p_s = km_p_h; ERROR - this conversion is not defined km_p_h = static_cast(m_p_s); // OK } You can manipulate Quantity value like any other value (add, multiply, compare), you may add e.g. 1 inch to value of 2.1 meters. This library helps to avoid really hard to track down conversion errors. Some conversions may not be needed: e.g. $1.5 money may be converted to string "one dollar, fifty cents" but not vice versa. Unimplemented and used conversions result in (relatively) readable linker error. Ability e.g. to divide length quantity by time quantity and get speed quantity may be added into the library. The library is simple and uses Boost.Preprocessor to emulate variable number of template parameters. - Shortened snippet of implementation: template class Quantity { public: Quantity() {} Quantity(const Quantity& other) : value(other.value) {} Quantity(const MainType& val) : value(val) {} Quantity(const OtherType1& val) { convert_quantity(val, *this); } ~Quantity() {} Quantity& operator=(const Quantity& other) { value = other.value; return *this; } Quantity& operator=(const MainType& other) { value = other; return this*; } Quantity& operator=(const OtherType1& other) { convert_quantity(other, *this); return *this; } operator MainType() { return value; } operator OtherType1() { OtherType1 result; convert_quantity(*this, result); return result; } // operators like ==, /, * etc. not shown here MainType value; }; - Name and inspiration was taken from Martin Fowler's article http://www.martinfowler.com/ap2/quantity.html. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
"Jason House" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > :blat ??? > > 1. I have no clue what that would mean > 2. Is there any handling of :blat in any way shape or form in the file > system stuff? I don't remember seeing any description of that case... > It means alternate stream of NTFS file. One file can contain any number of such streams. Default one - unnamed - is what you usually use. To use alternate stream, just append ":something" to the filename parameter of an API call. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: better assertion technique
"John Torjo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > assert( (i < j) || (i == 0) || (j == 1) ); would change into > SMART_ASSERT( (v_(i) < v_(j)) || (i == 0) || (j == 1) ); > > The output of the above (in case the assertion fails) can look like: > > Assertion failed: > '(v_(i) < v_(j)) || (i < 0) || (v_(k) == -1)' > i= '3' > j= '2' > k= '1' > This feature looks handy. Short macro like "v_" is IMHO acceptable, it won't clash with definition like: int v_; I wounder if it could be somehow merged with http://www.cuj.com/experts/2104/alexandr.htm?topic=experts ? /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: quantity.hpp uploaded into files section
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > If one were to implement currency conversion, how might that be done, in > general? > > Does one need to store the conversion rates between any two currencies > (giving an N^2 size table), or might it be possible to convert any currency > to some "universal currency", and from that again to any other, and still > getting the right values (giving a 2N table)? > > Currency conversion as drop-in library is IMHO not possible - currencies differ from strict units like weight and future applications may require functionality beyond current requirements. Speaking about quantity.hpp uploaded to Yahoo: it is general purpose and lightweight utility to help with conversions. It doesn't know angles or currencies or SI. I prefere to use example of convering between screen pixel and image point - something application specific what cannot be known and implemented in advance by library writer. Conversion between well known physical units is covered by SIunits (and other libraries) and quantity.hpp doesn't try to compete with these. Another examples: - You may need to know date when one currency value was converted into another (to find exchange ratio): quantity.hpp may help here to keep details separated from application code. - Conversion between angle and geometric point (contrived application specific example). - 'Dynamic' conversions: currency is converted into another using available realtime exchange rate. - 'Lossy' and 'one way' conversions: rounding up to nearest $ and (intentionally) with no conversion back. I am interested if such a utility will be found useful. It is very simple code (just few constructors + cast operators + naming convention) but the name quantity probably gives expectations of very specific functionality. I may change the name ("Safer Value Conversions" would be better but is wordy). /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
"Trevor Taylor" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > So it sounds to me like the :blat is *not* part of the extension. It > sounds like the NT file name is made up of three parts: name, extension > and "stream". > > In which case I think it is fine to have functions extension() and > change_extension() - they just should not report or modify the stream part. > > To implement them I guess I'd need to know whether the file name was an > NTFS filename, and then how to reliably locate the "extension" part? > Functin DeviceIoControl() with parameter IOCTL_DISK_GET_PARTITION_INFO can do it. It is available on NT/W2K. Does it make sense to take into account NTFS drives for Win95/98 (from www.systeminternals.com) or Linux NTFS drivers? /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Configuration for Intel compiler
"Guillaume Melquiond" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > > I found a bug in the interval library. but when I corrected it, I stumbled > over another problem: this bug was ironically what allowed the library to > be correctly compiled with my version of the compiler (Intel compiler 7.1 > for Linux). When I remove it, the library no longer works... > > The default configuration defines BOOST_NO_STDC_NAMESPACE for this > compiler. So the library expects to find standard C math functions (the > ones in ) in the global namespace. Unfortunately, they are where > they are supposed to be: in the std namespace. So here is my question: is > this macro really necessary for this compiler? > Intel C++ compiler can be embedded in VC++6 IDE and in this configuration puts functions in global namespace. It may be different for Intel C++ embedded into VC++7 IDE and yet different for standalone compiler. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Fix: current_function.hpp
current_function.hpp doesn't include Intel C++ where __FUNCTION__ can be used. It is more-less equivalent of GCC __FUNCTION__ (not the pretty one). No other similar macro works. It is not listed in official documentation but (likely) provided as GCC compatibility feature. Tested configurations: - Intel C++ 6.0 plugin in MSVC 6 - Intel C++ 7.0 plugin in MSVC 6 - Intel C++ 7.0 standalone (Number of configurations is much larger, including Linux version). Btw: what is purpose of current_function_helper()? /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_WARNING ?
"Robert Ramey" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > H - I never imagined that something like this would be so problematic. > > For now with my VC 7.0 compiler I can use the following and it gives > me almost exactly what I need. The warning message points exactly > to the place in my code where I have invoked it - just like BOOST_STATIC_ASSERT. > > I would hope something like this could be boostified so that I could use it outside > of a function. > > template > struct warning > { > typedef int type; > }; > > template<> > struct warning > { > typedef char type; > }; > > #define BOOST_STATIC_WARNING(B) \ > { \ > char x = (warning::type)0x; \ > } > Played with, it works on Intel C++ 7 and MSVC 6 (two warnings issued). It doesn't work for BC++B and needs change, e.g.: #ifdef __BORLANDC__ template struct warning { typedef int& type }; template<> struct warning { typedef int type; }; #define BOOST_STATIC_WARNING(B) \ { \ warning::type compile_time_warning_issued = 0; \ compile_time_warning_issued = compile_time_warning_issued; \ } #endif (It produces warning "temporary used to initialize 'compile_time_warning_issued'.) It would not work if #pragma warn -8028 is defined. I thought about preprocessor based solution (for compilers supporting #pragma message): file test.cpp: #include #define BOOST_STATIC_WARNING(x) \ BOOST_PP_STRINGIZE( BOOST_PP_CAT( BOOST_PP_CAT(warning, BOOST_PP_BOOL(x) ), .hpp ) ) int main() { #define BOOST_STATIC_WARNING_TEXT "detailed warning description" #include BOOST_STATIC_WARNING(0) } file warning0.hpp: #ifndef BOOST_STATIC_WARNING_TEXT #error You must define BOOST_STATIC_WARNING_TEXT each time before using BOOST_STATIC_WARNING #endif #ifdef _MSC_VER # pragma message ("COMPILE TIME WARNING: " BOOST_STATIC_WARNING_TEXT) #endif #undef BOOST_STATIC_WARNING_TEXT file warning1.hpp: #ifndef BOOST_STATIC_WARNING_TEXT #error You must define BOOST_STATIC_WARNING_TEXT each time before using BOOST_STATIC_WARNING #endif #undef BOOST_STATIC_WARNING_TEXT Output (Intel C++ 7.0 plugged in MSVC 6 IDE, MSVC 6 as well): Configuration: test - Win32 Debug Compiling... test.cpp COMPILE TIME WARNING: detailed warning description Linking... link: executing 'C:\PROGRA~1\Microsoft Visual Studio\VC98\Bin\link.exe' test.exe - 0 error(s), 1 warning(s) It cannot be used to generate warnings for template instantiations etc. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_ASSERT - a little better
"John Torjo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi all, > > I was just thinking (actually, I needed this, while doing some coding), that > STATIC_ASSERT could get a little of the SMART_ASSERT flavour. > > What am I talking about? > In case a STATIC_ASSERT fails, how about dumping some data that was involved > in the expression? > SMART_ASSERT is very useful to provide context information for hard to reproduce errors. STATIC_ASSERT error can be reproduced reliably during every compilation. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [thread] bugfix + possible deadlock
Boost 1.30, Windows. libs/thread/src/once.cpp, function call_once(), CreateMutex() should be replaced with CreateMutexA() in one place. Looking into the code, I have question: if the 'called once' function throws, it leaves (under Win32) opened mutex and this can deadlock the app (if there are more functions to be 'called once'). The mutex can be closed even in this case and function flagged as executed. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: current_function.hpp extension
"Peter Dimov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > There is currently no BOOST_HAS_CURRENT_FUNCTION since the idealistic goal > has been to cover all widely used compilers one day, ... > On the other hand, perhaps you have a use case that clearly demonstrates the > need for BOOST_HAS_CURRENT_FUNCTION? > SMART_ASSERT library implements BOOST_HAS_CURRENT_FUNCTION equivalent (it would be ugly to print out the default text). If not covered yet: MSVC 7 can be added (http://aspn.activestate.com/ASPN/Mail/Message/1647745) as well as HP aCC (http://aspn.activestate.com/ASPN/Mail/Message/1647818). /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] circular_buffer: minor feature request
Would it be possible to add helper function 'flatten()' into circular_buffer? After invocation, user would be sure of: &buff[0] < &buff[1] < ... < &buff[n] In other words, user will be able to treat circular_buffer content as continuous array of values in this moment. It is not earth shaking feature, it violates 'minimal interface' ideal but can be handy: - when legacy C function requires continuous array (like Win32 API) - when buffer is being saved to file or written to socket - special purpose adaptor could present result as (nonresizable) vector<> Alternatives are simple but much more CPU/memory expensive. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Formal Review Request: circular_buffer [long]
Hello Jano, "Jan Gaspar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 3. This fragment fails: > > struct Test {} > > circular_buffer a(2); > > a.push_back(Test()); > > a.push_back(a[0]); > > > I don't understand this. IMHO there will be 2 copies of Test(). Nothing should be > destroyed in the second push_back(). I think, everything is OK. > It works OK - I did mistake. The circular_buffer<> can safely pushXXX its own values. > > > > 3. cb_iterator: is the m_end value needed? > Should or shouldn't impact performance? What about setting m_it to 0 ? > Zero is even better. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer: minor feature request
"Jan Gaspar" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I think, I changed mind. The flatten() method can be substituted by something like > this: > > void doSomething(const int* pInt, size_t numInts); // C API > circular_buffer intBuffer(10); > ... // > fill the buffer somehow > vector v(intBuffer.begin(), intBuffer.end());// copy > if (!v.empty()) doSomething(&v[0], v.size());// pass the data to the API > > // &v[0] < &v[1] < ... < &v[n] > > I think, we should rather keep the interface minimal. > Yes but flatten() may be much more efficient, in some cases it may involve less or no copying at all and memory consumption won't be size() + capacity(). /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [dynamic_bitset] - small fix for workaround macro
dynamic_bitset.hpp defines macro BOOST_WORKAROUND_REPEAT_DEFAULT_TEMPLATE_ARGUMENTS that can be trivially replaced by BOOST_WORKAROUND. The macro is used only in this header. Diff for 1.30: 31d30 < #include 53,55c52 < namespace boost { < < #if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) --- > #if defined(BOOST_MSVC) && BOOST_MSVC <= 1300 57a55,63 > // > # define BOOST_WORKAROUND_REPEAT_DEFAULT_TEMPLATE_ARGUMENTS // macro 'local' to this file > #endif > > > > namespace boost { > > #ifdef BOOST_WORKAROUND_REPEAT_DEFAULT_TEMPLATE_ARGUMENTS 1403a1410,1411 > > #undef BOOST_WORKAROUND_REPEAT_DEFAULT_TEMPLATE_ARGUMENTS /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: BOOST_NO_TEMPLATED_STREAMS config macroandhelpers
"Gennaro Prota" <[EMAIL PROTECTED]> wrote ... > I had this problem with dynamic_bitset and, after discussing it with > Phil Edwards (who is one of the maintainers of libstdc++), I came up > with the macro that is currently in > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/b oost/dynamic_bitset.hpp?rev=1.28&content-type=text/vnd.viewcvs-markup > Just note: the macros (BOOST_OLD_IOSTREAMS and BOOST_BITSET_CHAR) should get undefined at the end of the header. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer and unused space overhead
"Nigel Stewart" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > Wouldn't it be better to use smaller internal memory block initially and > > resize it only when demand goes up? > > That's a good point, but it certainly complicates both the interface > and the semantics of the container. Could this style of circular > buffer be an adaptor, or perhaps a policy adaptor? > IMO the resize/shrink cannot be added via adaptor (unless it is very complex one). It may be possible to design circular_buffer<> as adaptor over [vector | deque | list | slist | shrinkable vector | ...]. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer and unused space overhead
"Nigel Stewart" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> > IMO the resize/shrink cannot be added via adaptor (unless it is very complex >> > one). >> >> An adaptor that wraps push() and insert() would >> be considerd too heavy-weight? > I think it is pretty heavyweight, but maybe there's some misunderstanding. > The point of NOT adapting a circular_buffer over > vector, deque or list is to preserve the fixed time > push and pop. It is also useful to automatically > overwrite items at the opposite end of the container, > to obscure that with resizing semantics seems is > undesirable. (In other words, a resizing circular > buffer is not consistant with the conventional > understanding of what a circular buffer is - correct > me if I'm wrong.) > My feeling is that with optional auto-resize feature circular_buffer<> may hit the sweet spot of being good enough for 80% apps. The auto-resize would kick in only when user explicitly asked for it. The fixed push/pop times and optimal memory use would be guarantied if things are going in normal, expected way. When buffer needs to get resized it is likely result of exceptional situation somewhere else and the resize overhead may be insignificant at this point. Primitive type elements may be detected and memcpy() solution used to decrease resize overhead here. > In relation to the previous discussion I thought an > alternative container may be a circular_deque that could > have the kind of flexibility with resizing that > also sounds desirable. > I was thinking about circular_bitbuffer<>, space efficient bool container. Boolean values are quite common output of sensors. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer and unused space overhead
> >>In relation to the previous discussion I thought an > >>alternative container may be a circular_deque that could > >>have the kind of flexibility with resizing that > >>also sounds desirable. > > Does a circular_deque sound like the right solution > to your particular application, rather than a > vector-like resizing contiguous circular buffer? > I think these solutions are (mostly) equivalent. >From practical point of view, adding auto-resize to circular_buffer<> is easier than creating new container. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer update
Hello Jano, "Jan Gaspar" <[EMAIL PROTECTED]> wrote > The updated circular_buffer implementation can be found > at the common place > http://groups.yahoo.com/group/boost/files/circular_buffer.zip > I looked briefly over the code: 1. IMO the macro based exception handling isn't needed, it is better to use RAII, like: void set_capacity(size_type new_capacity) { if (new_capacity == capacity()) return; pointer buff = allocate(new_capacity); size_type new_size = new_capacity < size() ? new_capacity : size(); BOOST_CB_TRY std::uninitialized_copy(end() - new_size, end(), buff); BOOST_CB_UNWIND(deallocate(buff, new_capacity)) destroy(); m_size = new_size; m_buff = m_first = buff; m_end = m_buff + new_capacity; m_last = full() ? m_buff : m_buff + size(); } can be replaced by: void set_capacity(size_type new_capacity) { if (new_capacity == capacity()) return; pointer buff = allocate(new_capacity); struct deleter_t { pointer data; size_type capacity; deleter_t(pointer p, size_type s) : data(p), capacity(s) {} ~deleter_t() { deallocate(data, capacity); } }; deleter_t guard(buff, new_capacity); size_type new_size = new_capacity < size() ? new_capacity : size(); std::uninitialized_copy(end() - new_size, end(), buff); destroy(); m_size = new_size; m_buff = m_first = buff; m_end = m_buff + new_capacity; m_last = full() ? m_buff : m_buff + size(); guard.data = 0; } RAII may replace all the macros in the code. Source code size, runtime speed and executable size should not get worse. 2. in function cb_iterator::operator -(), shouldn't it be std::less instead of less? (actually I do not see why < isn't enough here). 3. cb_iterator::operator +(): instead of cb_iterator operator + (difference_type n) const { cb_iterator tmp = *this; return tmp += n; } you may use cb_iterator operator + (difference_type n) const { return cb_iterator (*this) += n; } which looks the same but may use unnamed return value optimisation (URVO). The original code would require compiler to support named RVO to optimize copy away. Some other code may or may not be changed in this way, I didn't look futher for this. 4. circular_buffer::check_position(): raw throw is used, it may be conditionally disabled if BOOST_NO_EXCEPTION or function from may be used. 5. Similarly in circular_buffer::allocate(). (I wonder where std::length_error does come from?) > Regarding "unused space overhead" > > I share the Nigel's opinion. The circular_buffer was designed with fixed > allocated memory. It will just complicate things. For example statements > regarding iterator invalidation won't be true any more. On contrary it > is quite easy to adapt std::list, std::slist or std::deque to achieve > this goal. You can just push_back() elements at the end of e.g. > std:list. In case the size of the container exceeds the desired capacity > you just remove the element from the front. > Maybe in this case circular_buffer<> can reuse vector<> to keep internal data (the source code would be smaller + potential for smaller executable). The circular_buffer<> could keep start+end pointers and delegate quite a lot of functionality to std::vector<>. (Since there are not many Mojo enabled vectors, using Mojo likely means own buffer handling to be of any effect.) /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: GUI/GDI template library
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Make no mistake - this is a lot of work, too. However, it may be much less > work than creating one from scratch. What do we want - vaporware of a Boost > GUI library coming "real soon now", perhaps not appearing for many years, if > ever, due to the amount of work, or adapting an existing solution and being > able to use it here and now, with a boostified version to come? > Every project needs to start and can be labeled 'vaporware' at this moment. > My goal was to include > existing libraries in the discussion, and that has been met. > Exhaustive list of toolkits is on: http://www.free-soft.org/guitool/ Here is interesting review of five GUI toolkits, including wxWindows: http://freshmeat.net/articles/view/928/ /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filesystem feature request
From: "David Abrahams" <[EMAIL PROTECTED]> > I need the ability to do interprocess synchronization through file > locking, c.f. Java.File.createNewFile and Java.File.deleteOnExit: ... > On Posix, the first one would be done with > open(..., O_CREAT | O_EXCL) > > and the second, I suppose, would be done with a terminate handler. > The second feature (delete-on-exit) is supported by OS: - on Win32 using FILE_FLAG_DELETE_ON_CLOSE flag in CreateFile() - on Unix using unlink() standard system call /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Beman Dawes wrote: > > At 09:58 PM 8/4/2003, Alisdair Meredith wrote: > > > > >There is a problem with the Borland BCB6 compiler... > > > > What is the status of the Borland compiler as far as fixes and > > updates go? Have they announced any plans? > > Although they have not announced anything further about more BCB6 service > packs, it is easy to guess that there will not be any more. All indications > are that Borland is working on a BCB7 release but, in true Borland fashion, > there is no date given when it will be released until it happens. ... Something is happening right now - announcement and beta invitation is on http://bdn.borland.com/article/0,1410,30279,00.html. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Pavel Vozenilek" <[EMAIL PROTECTED]> writes: > > > Type traits library may be extended with: > > - memcpy_copyable<> and > > - memcpy_moveable<> > > see boost::is_POD. > memcpy_moveable<> may be useful for non-POD types, like some pimpls. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > > I don't believe you can use memcpy to move any non-POD types portably, > i.e. without special knowledge of the compiler. > Thats my point - you may flag some types as safely moveable and then use this knowledge in algorithms. User has the responsibility to do the decision. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Extremely dangerous and error prone. I can't even imagine a non-POD type > where flagging it for memcpy_copyable and memcpy_moveable can be right. Can > you give an example ? > It is error prone but many other constructs are too. Example of moveable object: struct string_buffer { unsigned size; char* data; // allocated buffer }; The user could then write: template<> memcpy_moveable { static bool moveable = true; // or defining some type or so } and container can detect moveability and use memcpy(). If type is not flagged, memcpy() won't be used. Usually strings, smart pointers, vectors, pimpls are memcpy moveable. Pimpl with back pointer isn't. (The memcpy_copyable<> is probably not that good idea and not much useful.) /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: memcpy_copyable<> and memcpy_moveable<> type traits
"John Maddock" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > He needs to take a look at the has_trivial_* traits: > > has_trivial_assign is roughly equivalent to memcpy_copyable > > I guess there is no equivalent to memcpy_moveable: but it looks rather > dangerous, > It looks dangerous but the memcpy_moveable is intended for containers designed to deal with this danger. (The problem can be a bit alleviated (in debug mode) by overwriting old storage by 0xCC bit pattern, making invalid use easier to spot.) Combination of is_POD and has_trivial_* covers many cases for memcpy_moveable but not all of them, IMO. Also the has_trivial_* are not yet supported by compilers. My intention was to give user chance to flag moveable types manually. Those causing performance bottleneck could be examined and flagged without need to change container/algorithm/architecture. Performance optimization is often targeted after system gets built and being able to improve it without major design changes looks useful. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > But even for a POD type such as this, copying would lead to > errors if the char * data were dynamically allocated since a double delete > would probably be done. > Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable<> can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable<> cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable<> is intended for situations where large arrays of objects are moved, like vector<> reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > But even for a POD type such as this, copying would lead to > errors if the char * data were dynamically allocated since a double delete > would probably be done. > Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable<> can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable<> cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable<> is intended for situations where large arrays of objects are moved, like vector<> reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost/detail/iterator.hpp update
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.lib.boost.devel Sent: Thursday, August 28, 2003 9:05 PM Subject: Re: boost/detail/iterator.hpp update ... > Anyone got a brilliant way to cause vc7 to print the error message? > #pragma message ( "some text" ) shown during compilation, is good enough? /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: circular_buffer ver. 3.3
Hello Jano, > > 5. Borland C++ Builder 6.4 doesn't allow to bring > >operator[] via using. ... > > What about just overriding operator[] for all compilers? (With the note that some > compilers doesn't support using for operators.) > Incentive for vendows to blush and fix the bug? AFAICS Borland won't anyway :( > > Also the "<< 1" and ">> 1" can be in this case safely replaced by * 2 and / > > 2 (it is unsigned). > What is wrong with "<<1" and ">>1". I think it is safe and it is more effective > for some compilers which don't optimize the *2 operation. > My feeling is it is a bit obscure. Modern compilers I know do this optimisation. > > Shrink algorithm can be: > > a. allow hysteresis when shrinking > >if new_size < current_capacity / 3 then shrink_to(std::max(min_capacity, > > current_capacity / 2)) > > Why current_capacity / 3 ? > Sorry, it was unclear: new_capacity = min(2 * current_capacity, max_capacity) if (new_capacity + new_capacity / 2 >= max_capacity) then new_capacity = max_capacity > > The constructors and set_capacity() would need one more paramerer or > > overload, > > capacity() could return pair<>. clear() would need change. > > Maybe new method can be introduced e.g. min_capacity(). The capacity method stays > unchanged. > Probably. > > 9. circular_buffer_base.hpp and circular_buffer_adaptor.hpp: > >instead of check > > > > #if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) || defined(BOOST_MSVC) > > > > is enough to use > > > > #if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) > > > > (it is defined for MSVC). > > I don't know why, but this does not work. You have to include "|| > defined(BOOST_MSVC)" too. > Works on my machine, hmm... It may be too pessimistic for future versions of MSVC. > > 14. Btw, isn't cb_iterator::operator[]() added by mistake? > > I have never seen such an operation for iterator. > No, iterators do have this operator. > Oops, newer used before :-o > > 16. RAII vs try blocks: ... > My colleague told me, if such a system exception ocurrs the destructor of the > exception guard won't be called. Check this out please. He also told me that the > system exceptions have nothing to do with C++ exceptions except that catch(...) > catches them. Btw. I would wonder if all the STL implementations would be just > wrong. > I did small test with Intel C++ and destructor gets called. After checking newsgroups, it seems main objections are against: catch(...) {} // no re-throw inside but: catch(...) { ... throw; } should behave right. Few more notes: 1. It may be good to mention exception safety in the documentation (the basic safety guarantee, that is). 2. Maybe header files (with exception circular_buffer.hpp and circular_buffer_fwd.hpp) should be moved into subdirectory boost/circular_buffer/. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: circular_buffer ver. 3.3
"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > Is there some reason you're defining your own iterators instead of > using iterator_facade or iterator_adaptor? > iterator_adaptor is used here, AFAICS. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost