- Boost - lists.boost.org

Re: [boost] Re: [repost][interfaces] would the following work?
by JOAQUIN LOPEZ MU?Z 15 May '05

15 May '05

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Mayo 12, 2005 10:15 pm Asunto: [boost] Re: [repost][interfaces] would the following work? > JOAQUIN LOPEZ MU?Z wrote: > > [Sorry I didn't answer sooner; I'm reviewing a long manuscript] > > > Allow me to repost this, since given the current traffic in > > the list it could well have passed unnoticed. > > > > Is (the proposed) Boost.Interfaces lib able to handle the following > > scenario? > > > > > > template<typename T> > > interface IIterator > > { > > T& operator*()const; > > ... > > }; > > > > > > template<typename T> > > interface IContainer > > { > > IIterator<T> begin(); > > IIterator<T> end(); > > ... > > }; > > > It is not the issue of specifying an operator as part of the > interface> IIterator (this'll be taken care of in the future > according to the > > docs), but the fact that IContainer::begin is required to return an > > object implicitly convertible to IIterator<T>. Can Boost.Interfaces > > do that? > > This is one of the main motivating examples for introducing > operator overloading > and self-referential interfaces. Unfortunately, it's not done yet, > but it's the > first or second thing on my list. The implicit conversion from an > iterator of > the underlying container shouldn't be difficult. Iterators with > operatorsreturning proxies may be a problem. Another issue is that > IIterator<T> must > clone the underlying iterator; otherwise you will often end up > with pointers to > deallocated objects. > > I'm thinking of using the following syntax for polymorphic > container wrappers > (stealing from Andrei): > > sequence - sequence of anything > sequence::of<T> - sequence of T's > iterator - any iterator (more or less) > iterator::over<T> (or of<T>) - any iterator over T's Is this container wrapper stuff further elaborated somewhere I can take a look at? > > This allows sequence and iterator to be typedefs for template > specializationsinvolving allocator policies. > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > > > PS: Just for motivation, I' think this idiom could be taken > advantage> of in a possible implementation of a dynamic multi- > index container. > > Sounds great! > The rationale is, in a multi-index container where indices are added at run-time, some sort of dynamic polymorphism is called for when retrieveing and using the indices, much in the vein of the poly container wrappers. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

(BIL)Interfaces: Beta library
by tcmichals 15 May '05

15 May '05

Is there beta? When might it be available?

2 1

Re: (Named) Parameter Library
by Cromwell Enage 15 May '05

15 May '05

BTW, the include guards in <boost/parameter/macros.hpp> are all near the end of the file. I'll presume that's not where they should be? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

[string_algo] cw8.3 problem
by Pavol Droba 15 May '05

15 May '05

Hi, There is a reported problem with string_algo lib and cw8.3 http://tinyurl.com/bk9u2 I don't know what can be the problem. Can anybody with the access to this compiler have a look at it, please? Thank you. Pavol.

2 2

RE: ACT SPAM:[boost] [preprocessor] What syntax to present to the user
by Roman Yakovenko 15 May '05

15 May '05

> -----Original Message----- > From: loic.actarus.joly(a)wanadoo.fr > [mailto:loic.actarus.joly@wanadoo.fr] > Sent: Friday, May 13, 2005 1:22 PM > To: boost(a)lists.boost.org > Subject: ACT SPAM:[boost] [preprocessor] What syntax to > present to the user > > > Hello everybody, > > I'm trying to use the boost preprocessor library to allow the user to > define "rich" enums, for instance enums that cannot be > converted to int, > whose values can be displayed in human readable form on a stream... > > I think I have to use macro to ease the writing of such enums, and I ... There is a better approach. Try to search "smart enums" within boost mailing list archive Roman

1 0

failures-markup
by Pavol Droba 14 May '05

14 May '05

Hi Boosters, I'd like to ask for more caution when modifying explicit-failures-markup.xml file. Somebody has marked vc7 as unusable for string_algo lib, although the workaround is already on the way, and there is just few fixes to be done. I have unmarked this toolset few days ago, but it gets marked again. (Probably by mistake) It slows down my work since I don't have a direct access to this compiler so I must relay on the regression tests. Thanks. Pavol

2 1

[policy_ptr]source, sink policies proposal
by Larry Evans 14 May '05

14 May '05

Currently, policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… constains a conversion policy which determines whether or not to contain an implicit conversion to the raw pointer via the smart_ptr</*polcies typelist*/>::to<Referent> method: operator automatic_conversion_result(void) const; where: typedef typename conversion_policy::result_type automatic_conversion_result; However, since smart_ptr<...>::to<Referent> is derived as: class smart_ptr<P1, P2, P3, P4>::to : public detail::policy_ptr::conversion_policy_ couldn't the automatic conversion operator just be defined (in the case of allow_conversion) or not (in the case of disallow conversion) in the conversion policy itself? In addition, instead of allowing the raw pointer to escape from the "protection" of the smart_ptr via the storage policy's get_impl, why not delegate this decision to a "sink" policy, which decides how the pointee is exposed to outside use? IOW, rename the conversion policy to the sink policy which decides whether 'operator pointer_type()' or 'get_impl' are publicly exposed. This would allow for a "safer" smart pointer. Along the same lines, why not allow a "source" policy which decides the "inputs" (the CTOR args) to the smart pointer. Currently, for smart_ptr<...>::to<Referent>, the only "source", IIUC, is Referent*. (By source, I mean any CTOR arguments that don't include another smart pointer ). This would also allow for a "safer" smart pointer since the sole source could be something like David Abraham's auto_ptr_new: http://lists.boost.org/MailArchives/boost/msg42996.php

2 5

[Formal review] Singleton library
by Pavel Vozenilek 14 May '05

14 May '05

The formal review of Singleton library written by Jason Hise starts today, May 5th, and lasts 10 days. The library is available at http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… The singleton documentation can be browsed online at http://www.ezequal.com/chaos/docs/html/singleton/ Singleton is feature rich library: - ensuring single instance of a class and global access point to this instance - with policies specifying: - when the instance gets created (manually, immediatelly, when first used, ...) - how is the instance created (by new, malloc, in static memory, ...) - when the instance gets destroyed (never, by priority, after another singleton, ...) Parametrized singleton called Multiton is provided City::pointer p1("Chicago"); City::pointer p2("Brussels"); will create two different "singletons" of the same type. Another feature is ability to register resources (like shared pointer) who will get destroyed in controlled order, when the application exits. Not yet implemented features are: - MT safety - self-destroying singleton with timeout - bjam compatible tests The library is known to work with several newer compilers, VC7.1 among them. Help with other compilers is welcomed. When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. /Pavel

18 58

[program_options] Fix for 64 bit platforms
by Markus Schöpflin 14 May '05

14 May '05

Hello, attached patch has just been committed to program_options/src/cmdline.cpp. It fixes the test failures observed on Tru64 for the cmdline_test test and probably applies to all 64 bit platforms. As a side note, there are many other incorrect uses of unsigned in this file which also should replaced by the correct size_type, but currently these uses don't cause a test failure. Markus Index: cmdline.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/src/cmdline.cpp,v retrieving revision 1.18 diff -u -r1.18 cmdline.cpp --- cmdline.cpp 6 May 2005 07:48:45 -0000 1.18 +++ cmdline.cpp 13 May 2005 11:21:38 -0000 @@ -351,7 +351,7 @@ { string name, adjacent; - unsigned p = tok.find('='); + string::size_type p = tok.find('='); if (p != tok.npos) { name = tok.substr(2, p-2);

2 1

[website] New design is in CVS.
by Rene Rivera 14 May '05

14 May '05

The new design is now in CVS! But before people start saying.. "We don't like it! Why dis you put it in?" ... It was decided that having something now was better than having to wait for another release and have no progress shown on the website. Hence expect the design to continue to evolve after the release. Yell if you do an update, and find any problems. One WARNING, if you update either of the two new pages, index.htm and more/version_history.html, please process them with: tidy --tidy-mark no -i -wrap 78 -m -asxhtml --doctype strict [file] So as to ensure no errors creep in, and to make the formatting consistent. I'm trying to find a place to an instruction to that effect, but I can't readily see a place for it. Anyone have a suggestion where I should document running of tidy? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 5