Re: [boost] Re: swappable user defined types and STLport libraries
Beman: >I'd like to be sure that some Booster signs up for this beta and starts >running the Boost regression tests against it. And then follows up with bug >reports to Borland as needed. Any bugs fixed in the compiler before it >ships are bugs Boosters don't have to cope with later. To the best of my knowledge, the compiler isn't yet being shown - I believe that they're looking at getting the IDE side of things working, and then will bring the compiler along once that's done. >Any volunteers:-? Mr Meredith? Alan -- Alan Bellingham ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Proposed smart_handle library
Victor A. Wagner Jr.: >>How do you measure failure? Certainly MFC is primitive, but tens of >>thousands of developers use it every day. There are better >>alternatives - Microsoft tells me they have been shipping an >>"unsupported" library which is "what MFC would have been if we'd >>started with templates". > >did they give you the name of this library? Presumably this is WTL - the Windows Template Library. http://www.microsoft.com/downloads/details.aspx?familyid=128e26ee-2112-4cf7-b28e-7727d9a1f288&displaylang=en> Overview Windows Template Library (WTL) is a library for developing Windows® applications and UI components. It extends ATL (Active Template Library) and provides a set of classes for controls, dialogs, frame windows, GDI objects, and more. This version provides full support for Visual Studio .NET and Windows XP. Note: The Windows Template Library (WTL) is not supported by Microsoft Product Support Services. However, you may find some peer support at the WTL Support List Web site. Despite the unsupported nature, it's currently at version 7.0 When they mention templates, they certainly went far beyond MFC - ATL not only uses multiple inheritance, it even use the Curiously Recurring Template Pattern. Having said which, any further discussion is probably off topic, unless we're trying to learn lessons from its design to apply to Boost candidates. Alan -- Alan Bellingham ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete without assignment to 0 - why?
Markus:
>In one of Herb Sutters articles I saw that
>after deleting a pointer (a pimpl) he assigns 0 afterwards
>which seems to me like a good idea.
>(see e.g. http://www.gotw.ca/gotw/028.htm or http://tinyurl.com/bq8o)
>
>Maybe there is a good reason (efficiency?)
>why checked_delete omits this extra step.
>Please explain.
>
>template inline void checked_delete(T * x)
>{
> typedef char type_must_be_complete[sizeof(T)];
> delete x;
> // why not ?
> x = 0;
>}
Well, it's pretty pointless, though an reasonable optimiser will spot
that the value x is never used after that last assignment, and lose it.
Would we want to put extra code into Boost just to get a slower compile
speed and possibly slower execution speed? Probably not.
It's reasonable to promote strictly unnecessary safety code in user
code, but when it comes to a library, we want it to be as efficient as
possible consistent with safety. In this case, we rigourously inspect
the code (by eye, and by linting) and determine that the line in
question actually is unnecessary.
Alan
--
Alan Bellingham
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart_ptr vs smart_resource
Phil Nash: >> Not all pointers refer to resources. > >Hmmm, unless you are thinking of null pointers I can't think of any pointers >that don't refer to resources. Perhaps we have a different definition of >resource? Or of 'refer to resources'? char * ptr = new char [12]; // points to (ergo, refers to) resource char * ptr2 = ptr+4 ; // points _into_ resource Alan -- Alan Bellingham ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: dynamic_void_cast
Terje Slettebø <[EMAIL PROTECTED]>: >>>in this thread, void * is type erasure. More or less the only safe thing you >>>can do with it, is to delete it. You can also cast it back to its original [snip David Abrahams demurral] >Of course, it depends on whether the type supports polymorphic deletion, and >whether or not it's an array (so you would need delete[]), but are there >other issues besides this? I assumed that if types were used in this way, >then at least the above was known. Well, in addition, you've forgotten that because void* has no type associated with it, any real object behind the pointer will not have its dtor called. Not good news, usually. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
