- Boost - lists.preview.boost.org

Regression: avoid cleanup of binaries
by Stefan Slapeta 21 Sep '04

21 Sep '04

After the regression tests there seems to be a total cleanup of the binaries. Is it possible to avoid this in some way? (maybe specifying --incremental is the solution, but I would rather guess letting away this option should clean up the binaries _before_ the test run, shouldn't it?!?) Stefan

3 4

[shared_ptr] InterlockedIncrement rocks!
by John Torjo 21 Sep '04

21 Sep '04

Hi Peter, I just took your implementation (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) for shared_ptr and use it now in win32gui (upcoming v1.4.2). Using Interlocked* for win32 totally rocks! From my tests - Interlocked* are very fast. They're about twice as slow as a raw increment (or my tests are wrong;)). From what I see - I think you can certainly merge them into boost::shared_ptr. Maybe users can select the old version or this Interlocked* version with a certain macro - like BOOST_SHARED_PTR_USE_INTERLOCKED. Also, why not including windows.h directly, like this: #define WIN32_LEAN_AND_MEAN #include <windows.h> <side-note> From my tests it seems your version as is now fails to link for gcc (unresolved external _InterlockedIncrement/_InterlockedDecrement). However, if #including <windows.h> and use InterlockedIncrement/Decrement - they work. </side-note> Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 21 Sep '04

21 Sep '04

> >>Also, why not including windows.h directly, like this: > >>#define WIN32_LEAN_AND_MEAN > >>#include <windows.h> > > > > > > I believe WIN32_EXTRA_LEAN may be even better. > > Just a thought - there is no WIN32_EXTRA_LEAN on vc7.1 Yes you are correct. I misremembered VC_EXTRALEAN, which is a similar macro, but for MFC only. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

Re: [boost] Re: [assign] fixes for msvc, msvc-stlport and vc7
by JOAQUIN LOPEZ MU?Z 21 Sep '04

21 Sep '04

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Martes, Septiembre 21, 2004 9:03 pm Asunto: [boost] Re: [assign] fixes for msvc, msvc-stlport and vc7 > Hi Joaquin, > [...] > > | 2. list_insert::operator()(T t) has been changed to accept > | a const reference instead. > > I have made this change as > > #if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) > > template< class T > > list_inserter& operator()( const T& t ) > #else > template< class T > > list_inserter& operator()( T t ) > #endif As you wrote it, the workaround applies only to MSVC 6.0. Let's wait for the next test cycle to see if it has to be extended to MSVC 7.0 as well. > > | With these changes, all tests build, though three of them > | crash at run-time (list_inserter, list_of and multi_index_container) > > ok, this is much better than before! some of the test a big and > fat and do > some tricky conversions...but just having the > basic stuff working is great! > > |I've got two questions: > | > |1. Could somebody (the author, I guess) validate these changes > |for commit? > > I have comitted them. > > |2. list_inserter follows a strange convention (IMHO) of not > |forcing template params to be const references in its various > |copy ctors and assignment operators, for instance: > | > |list_inserter( Function fun ); > |template< class T > > |list_inserter& operator=( T r ); > | > |Any reason for this approach? I don't know if this can pose > |problems, but to me having these qualified with const & seems > |like the usual way. > > yes, the bitches are char[N] and wchar_t[N] which does not convert > to char* > and wchar_t* otherwise. this comes up in simple stuff like > > vector<string> = list_of( "foo" )( "goobar" ); Ummm, I see. The fact is that here lies, I think, the reason for the three remaining crashes, all on calls to multi-argument versions of list_inserter::operator(). Maybe I'll give this some thinking over if I have some spare time tomorrow. > > of course, the Function arg could be const Function&, but is there any > difference in inline code? I think this can involve an extra copy under some circumstances, ans some compilers might not optimize this away. But in general I agree with you little is gained by having const Function &. > > Muchos gracias for the patch! Velbekomme :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: static_cast and const
by Ben Hutchings 21 Sep '04

21 Sep '04

Jonathan Turkanis <technews(a)kangaroologic.com> wrote: > "David Abrahams" <dave(a)boost-consulting.com> wrote in message > news:umzzl3pvk.fsf@boost-consulting.com... > > Richard Hadsell <hadsell(a)blueskystudios.com> writes: > > > > > Jonathan Turkanis wrote: > > > > > >>When I was writing it I initially typed 'const_cast', but then > > >>thought to myself: why use my big guns if I don't have to? ;-) > > >> > > > For clarity -- to tell the reader that you intended to modify the > > > const-ness. > > > > static_cast is a bigger gun than const_cast. At least const_cast > > cant violate data layout, and unless there is actually a constant > > object, won't result in undefined behavior. > > Good point. I guess part of the reason I avoid const_cast whenever > possible is that people look upon it suspiciously, even if it's only > adding cv-qualification. Maybe people should be more suspicious of > static_cast. If you want to make an implicit conversion explicit, use boost::implicit_cast.

3 3

dynamic scoping emulation - was Re: Lexical cast suggestion
by Jonathan Graehl 21 Sep '04

21 Sep '04

> > >Nope, there's only one global locale, it's not per-thread. If it's >per-thread, you can do > > std::locale::tss_global(std::locale("koi8-r")); > // do some work with program_options > std::locale::tss_global(std::locale("")); > I do this all the time (but using a scope guard), for globals I've declared thread-local. This essentially simulates dynamic scoping (which I'd prefer to see supported directly by the language, as an alternative to lexical scoping). Perhaps a Boost library for dynamically scoped properties would be nice? -Jonathan

1 0

RE: [boost] Avoiding warning on the do{...}while(0) macroimplementation trick
by Ben Hutchings 21 Sep '04

21 Sep '04

Ivan Vecerina wrote: > I've noticed discussions about this a couple of years ago. > For assert-style macros that include multiple statements, > a common idiom is to enclose the statements in a do{...}while(0) > dummy loop. This makes the macro behave like a single statement. > > A problem with some compilers (notably VC7.x) is that this > triggers a warning (C4127: conditional expression is constant). > > The workaround adopted by boost is to automatically disable > this warning -- which however can be legitimate and useful > in user code. > > I think I have found a better 'always-false' condition which > does not trigger a warning, and works at least in VC7.1: > do{ }while(__LINE__==-1) > > Do you see a problem with this approach? <snip> It works in VC++ 7.1 if you enable "edit and continue", because this results in non-standard expansion of the __LINE__ macro to an expression that isn't a compile-time constant. In general it doesn't work.

3 2

[assign] MSVC support?
by Aleksey Gurtovoy 21 Sep '04

21 Sep '04

Is assign library unusable on MSVC < 7.1? If so, could the maintainer please mark it up as such in "boost/status/explicit-failures-markup.xml"? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 21 Sep '04

21 Sep '04

> Also, why not including windows.h directly, like this: > #define WIN32_LEAN_AND_MEAN > #include <windows.h> I believe WIN32_EXTRA_LEAN may be even better. > <side-note> > From my tests it seems your version as is now fails to link > for gcc (unresolved external > _InterlockedIncrement/_InterlockedDecrement). > However, if #including <windows.h> and use > InterlockedIncrement/Decrement - they work. > </side-note> That is not suprising - Interlocked* are parts of the Win32 API. In fact, it has been a complete mistery to me as to why boost doesn't use atomic operations for its ref counting. The mutex on the counter was one of the big reasons why people here decided not to use shared_ptr. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

RE: [boost] OutFmt library implementation questions
by Rozental, Gennadiy 21 Sep '04

21 Sep '04

> >2. Why doesn't insert_iterator is implemented using iterator_facade? > > [1] I am not that familiar with using iterator_facade > [2] Is it worth the abstraction penalties? Compring to output operations? > >4. How does this all machinery will work with wchar_t? > > std::wcout << formatob( vec, containerfmtex< wchar_t * > >()).format( L" - > " ); > > Use the ex< DelimiterType > variant on the innermost construct. This is inacceptable and does not follow standard practice. > >5. Why do you need static_cast< const base_type * > to cast > to the base > >type > >in container.hpp? > > This is a VC 6.x workaround. But you don't list this compiler amoung supported. > >6. Why the same entity you sometime call format_type and sometime > >DelimeterType? > > format_type is the typedefed version (should be delimiter_type) and > DelimiterType is the template parameter. So is it delimeter type or forat type - it can't be both. > >7. What deducer is supposed to deduce? I couldn't get > through all the > >details, but couldn't the same be achieved using partial > specialization > >and/or partial ordering. Cause it look way too complex and > unnecessary. > > The deduction mechanism is used to evaluate what type T is > (e.g. std::pair< > char, int >), what format object is needed to render it > (including nested > format objects) and to construct the appropriate format object. > > It could be possible to use partial specialization, but the > type traits are > used elsewhere to redirect formatting behaviour (e.g. when > reading in a > container do diffreent things if it is a sequential, > associative or set > container). IMO all that you needed is function overloading. I don't see a place for all these deduce/trats staff. > >9. What is RT2 stands for? > > ReturnType2. Do not abbreviate. > >11. Need for all this hierarchies: > >Formatter->formater_t->openclose_formatter_t > > This is to ensure that the return type of 'format' in Formatter > [FormatObject] is Formatter and not openclose_formatter_t. Thus: > formatob( vec, containerfmt().format( " / " )); > will work as intended without overriding 'format' in > containerfmt_t (created > by containerfmt()) to return the correct type. > > >openclose_formatter->openclose_formatter_t > > > >are completely unclear. Explanations presented in docs does not help > >since format methods seems to be returning *this anyway. > > They return: > *static_cast< ReturnType * >( this ) > to allow 'format' to return the correct type when inherited > in the format > objects. Formatob_t::format return *this. You did not answer my question. I still believe it's all unnecessary. > >Why couldn't we just use something trivial like > > > >template<char Ch> > >struct formatter > >{ > > std::basic_string<Ch> m_open; > > std::basic_string<Ch> m_close; > > std::basic_string<Ch> m_sep; > >}; > > > >Is beyond me. If any member is empty it means it missing. > > This is the direction I am going in the development version. The only > difference is that I am using io::decoration< CharT, int id > > instead of > std::basic_string< CharT >. The decoration class uses > std::basic_string to > store the values, while providing support for looking up the > default value > on a stream and an external function for checking for a match > on an input > stream. You presented library call *Output* formatter. Why do we talk about input at all. > >14. list_object -> formatter_t inheritance look wrong. > Where is IS A > >relationship? > > list_object *isa* formatter_t *isa* openclose_formatter_t > > using the new design: > > list_object *isa* sequence_decorators_t *isa* > wrapper_decorators_t *hasa* > decoration List_object IS A formatter ???? Something really worng with naming here. > Regards, > Reece Gennadiy.

1 0