[boost] Re: const T & const and C++98
Thanks for the responses to my question. My generic list formatting library used the const T & const ref; construct when passing values. This was because I had been looking at the spirit library and read T const & ref; as T & const ref; I then interpreted that in the way pointers and const work. My mistake. The first response answered my question, and I have reverted back to using const T & ref; in the code. I did not expect it to produce a large discussion. -rhd- mailto:[EMAIL PROTECTED] _ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Graph] Improved creation of visitors from functionobjects
On Thursday 17 April 2003 03:50 am, Vladimir Prus wrote: > IOW, now specifying behaviour for event requires creating a new class, with > "event_filter" typedef and operator(). You propose to pass lambda, > immediately on dfs_visitor creation. I think this is indeed convenient. > I've some concerns about efficiency, but why don't try? It's a little worse than just creating the new class with event_filter: you need to build up a cons-list out of std::pairs containing your visitor types. I generally just subclass dfs_visitor<>, but that's a typing-heavy hoop to jump through for a simple visitor. The efficiency won't be any worse than using a bind object elsewhere in a program. The do_on_XXX functions merely augment the visitor list of dfs_visitor and return a new dfs_visitor object. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: const T & const and C++98
Reece Dunn wrote: > construct when passing values. This was because I had been looking at > the spirit library and read >T const & ref; > as >T & const ref; To be clear, Spirit's convention is T const& ref. Cheers, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [filesystem] new functions proposals
I think that the filesystem library would very benefit from two functions: std::string extension(const boost::filesystem::path&); boost::filesystem::path change_extension(const boost::filesystem::path&, const std::string& new_suffix); and, probably, std::string basename(const boost::filesystem::path&); The intent is to get/change the part of leaf name after the first dot. I needed the change_extension in a couple of contexts, and just now cleaning up an old code where a check for correct extension is made. Do others agree that those functions are very usefull? I can write/document them in that case. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Adding a generic list manipulator
[documentation]: William E. Kempf wrote: > NOTE: I am thinking about writing an XSLT file that will generate > boost-style documentation. Already done. You're reinventing the wheel, and should instead be helping out the development efforts of BoostBook. I said that I was *thinking* about it. Anyway, I'd be happy to help out the BoostBook development efforts. I am currently using a different XML structure/XSLT fileset that I have been using for a while now, that has features such as MathML support and unicode mappings for IE6 (as XSLT -> HTML/CSS) based on David Carlisle's work at http://www.w3.org/Math/XSL. I have updated this XSLT code to use a CSS file passed as a parameter to it. The syntax highlighter now uses CSS class types so the CSS file can configure the highlighting accordingly. I am now using boost.css for the boost version of the document, and default.css for my internal version (no difference except the CSS file used). boost.css provides black on white text with softer colours for the syntax highlighting based on the feedback I have recieved. [code]: Terje wrote: Regarding the use of names starting with double underscore: This has now been fixed in both identifiers and header guards. " __cdecl" - This is Microsoft-specific, so it may be a good idea to remove (it can always be set in the project settings, instead). This has now been removed from the test files. Some headers, such as list_output.hpp, are not stand-alone. Including it gives several errors about undefined names. I am working on this. Some names don't conform to Boost's coding standard, such as "spaceAroundList()" (instead of "space_around_list()"). This has been fixed to conform to Boost coding standards. [todo]: [1] Work on the documentation This is a work-in-progress. [2] Clean up the code I have made progress in this area, by removing redundant constructs. [3] Examples and test files I have split the examples based on the technology that they use. [4] Extensions I have begun to document where I want to extend the existing code. NOTE: The code is not 100% backward compatible, but is compatible for the most part. The rationale for this is because it is still a beta library, and as such is likely to be in a constant state of flux. If/when the library becomes part of boost, *then* I will apply stricter version controlling and backwards compatibility support/testing. -rhd- _ formatlist.zip Description: Zip compressed data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Graph] Improved creation of visitors from functionobjects
Douglas Gregor wrote: > On Thursday 17 April 2003 03:50 am, Vladimir Prus wrote: > > IOW, now specifying behaviour for event requires creating a new class, > > with "event_filter" typedef and operator(). You propose to pass lambda, > > immediately on dfs_visitor creation. I think this is indeed convenient. > > I've some concerns about efficiency, but why don't try? > > It's a little worse than just creating the new class with event_filter: you > need to build up a cons-list out of std::pairs containing your visitor > types. Yep, but that's the easy part of the game, IMO. > The efficiency won't be any worse than using a bind object elsewhere in a > program. The do_on_XXX functions merely augment the visitor list of > dfs_visitor and return a new dfs_visitor object. This precisely what worries me -- bind might not be very efficient. I may be a overly concerned about efficiency at the moment --- recently wrote a graph algorithm in BGL which turned out to be 100 times slower that a simply-coded one :-( Not sure if this is BGL's fault or the problem with the algorithm, though. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 'const T & const' and C++98
Matthew Towler wrote: > int a, c; > int& b = a; > b = c; // error, as attempting to reseat the reference. um.. That's not an error, it just doesn't do what you think it does. It actually assigns the value of c to a. -- Truth, James Curran www.noveltheory.com (personal) www.njtheater.com (professional) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Vladimir Prus wrote: > The intent is to get/change the part of leaf name after the first > dot. um.. After the FIRST dot or the LAST dot. In Win32, "james.m.curran.txt" the extention is "txt", not "m.curran.txt" -- Truth, James Curran www.noveltheory.com (personal) www.njtheater.com (professional) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] new functions proposals
On Thu, 17 Apr 2003 17:41:24 +0400, Vladimir Prus wrote > I think that the filesystem library would very benefit from two functions: > > std::string extension(const boost::filesystem::path&); > boost::filesystem::path change_extension(const > boost::filesystem::path&, const std::string& new_suffix); > > and, probably, > > std::string basename(const boost::filesystem::path&); > > The intent is to get/change the part of leaf name after the first > dot. I needed the change_extension in a couple of contexts, and just > now cleaning up an old code where a check for correct extension is > made. Do others agree that those functions are very usefull? I can > write/document them in that case. Yes, these would be useful as this problem comes up quite frequently. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: an xml-binary persistence library
Hi Nicola,
Nicola Santi wrote:
> >4. I don't understand how serialization of base classes should be done.
>
> In derive class serialization method remember to call the serialization
> method of base class.
>
> void Derived::serialize( bin_archive &stream) {
> // first base class serialization
> Abase::serialize(stream);
Ok, I see now.
> > 5. .. Then, if you use put_object for storing ? if you store a
> several different pointers to the same class, you'll have type name
> stored many times, and it's likely it will be longer that the class data!
>
> put_object() stores the class conventional name than call the method
> serialze(). get_object() retrieves the conventional name, create the
> object, call the method serialize.
>
> If you do not need dynamic creation (because you know it?s type or
> because it is allocated on the stack, etc.) create the object and call
> its serialize() method instead of get_object().
I'm afraid I don't like this approach. You have 3 ways to serialize an
object:
1. Call operator <<
2. Call put_oject
3. Call serialize on object directly.
That's quite confusing.
> 7. (thinking aloud) ..
>
> >- The space is important. A single class may be 4-ints big, and
> writing class name will double the size of data.
> >- The speed is important. In one case, the type of data is known
> during writing, and just raw bytes are added to a buffer. Adding
> "typeid" call and a search for conventional name (you do it with linear
> search now, but map is not O(1) as well), will not be acceptable.
>
> Same as previous point, if you know the type don?t store it. Otherwise
> if you need dynamic creation assistance the name of the class should
> necessarily has been stored in the archive: in this situation could be
> of some help register the class with short name only for the duration of
> storing and retrieving.
OK, short name will help with the space issue. But still, lookup up that
short name will take time.
> > I recalled that someone suggested to Robert to separate class
> registration to a separate component (possibly replacable). That would
> be very good here. I could create custom class which will return id for
> a type at compile-time. What do you think?
>
> I think could be interesting, please let me know more details about the
> API you are suggesting and we could try to implement it.
If I only new what API I am suggesting ;-) The originally idea came from
something else, and it started to resonate with my needs recently. I'll try
to think about something concrete.
> > 1. The documentation on the web page could be better.
> - I don't see "overview" anywhere. I see such document in the
> distribution, but if you don't have overview instantly accessible, some
> folks will not even bother to download the library.
> - The "examples" web page does not contain examples, but just
> mentions the ones from distribution. Having examples on the web would
> be much better.
>
> I agree: I?ve change eternity web site this morning to follow your
> suggestions.
That's good.
> 6. I believe there's not enough tests for your library.
> Again, your are right. Could you help me in writing more tests? I will
> appreciate it?
I think that Robert's library has quite a plenty of tests. You can look for
ideas there.
> DESIGN CONSIDERATION
>
> 2. (DP) Binary serialization and XML serialization are entirely separate.
>
> Storing a primitive type in xml archive required an additional field
> (the tag label) then storing the same field in binary archive. Moreover
> retrieve that field required one other parameter (the position) that is
> not needed in binary persistence.
BTW, I don't understand why tag is required on loading. I would suppose that
XML is just like binary stream, only you have extra annotations for the
benefit of humans and tools.
> One year ago a developer from French write me if it could be possible to
> have only one serialize() method to store both xml and binary way. I
> wrote the modification to eternity (moving a lot of methods from
> xml_archive to archive ) and having serialization method like this:
[..]
> When this method is called for binary persistence it passes a lot of
> parameters that are not using and loose the random access facility over
> XML archive. Do you really things it is a good idea? With two methods
> (serialize and xml_serialize) the class has more control over the
> persistence engine and could choice to implement only one of the two ways.
First, I don't yet get the idea of "random access facility". Thinking about
uneeded data, I though that if you had template method:
template
void save(Saver& s) const
{
s << class_name("foo") << field_name("x") << x;
}
then a saver for binary data would have empty inline overloads for
class_name and field_name manipulators. The compiler will surely
optimize away all names manipulation and you won't pay for it.
A saver for XML would make use of names, of course.
> Ok, ex
[boost] Re: an xml-binary persistence library
Hi Robert, Robert Ramey wrote: > Nicola, Vladimir et.al > > I submitted a serialization library for review last november. > > It was rejected for inclusion in boost for a number of reasons which > I will attempt to summarize as follows: [...] > b) Certain usage features > ii) inconvenient type registration requirement > iii) requirement to pre-register classes to be saved as pointers > through a base class Was it ever considered a problem. You surely have to register a class in order to deserialize it (Java can create a class given its name, but we're in C++). > iv) requirement to have separt save/load code for serialization functions I though about it just recently, and stubmled upon the issue of const-correctness. Probably, separate save/load is OK, since I don't know any good alternative solution. > After addressing this, the path to addressing the main feature objections > a and b > became clear. I believe that if I submit another version of my > serialization library, it well meet all the objections listed above. I am > currently implementing an XML archive. Can we have a look at it? Probably, putting it to boost-sandbox is good idea. I'm really interested to see how it applies to use case I have at hand. > a) better documentation. What you have (the PDF) isn't bad. Its just that > more will > be requested. Personally I'm not impressed with the "Oxygen" automatic > documentor (or any other automatic documentor). IMO, the biggest problem with Doxygen is the way programmers tend to use it. Automatically generated class reference is good, but in itself it's to low-level, and very often comments are too quick (like function name with spaces instead of underscores). > b) versioning at the class level It would be nice, BTW, to have optional versioning - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [config] New workaround macro
> Done. Let me know what you think of it. On the model of boost/type.hpp I've > added a trivial boost/non_type.hpp, which envelops non-type template > parameters. If you like the macro names, I'll write the documentation too. The names are a little long,but I can't think of anything shorter... so go for it, good work, thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Adding a generic list manipulator
Another suggestion, which was also suggested, and done, for my composite stream operators (which is similar to your library), is to put it in the Sandbox. That enables easier use and updating, and you don't have to attach a file for each update. People using the Sandbox can just add it to their include path, and use it like Boost (same "boost" path prefix for the libraries). The composite operators are at boost-sandbox/boost/io/format and boost-sandbox/libs/io/format, and I'll add some docs, soon, as well. I'm sure there's room for more such libraries, there. :) Maybe a combined library could come from this. Anyway, several libraries enables experimentation, as well. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sandbox iterator adaptors update
David Abrahams wrote: > While at the ACCU and committee meeting, Jeremy, Thomas and I did a > whole bunch of work on the sandbox version of iterator adaptors and > the new categories in boost/iterator and libs/iterator. We think that > the implementations are quite stable now and are trying to get a > proposal together for the post-meeting mailing. Please check it out > and see how it works for you! We'd value your comments. I've a very basic question for now: how to I convert "*rst" files in documentation to something nice-looking, like hmtl? TIA, Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RFC shared_ptr_embedded
Hi All,
I have created a new shared_ptr class called shared_ptr_embedded. This is
based on the code for intrusive_ptr but differs in one important
aspect. The struct/class pointed to is required to be derived from
shared_ptr_count. The latter class contains an 'int count_' and methods
for adding and removing references. This allows you to have the count
embedded in your primary data, rather than having a separate allocation for
count as shared_ptr does.
Here is an example:
#include
class SharedName
{
struct Data : public boost::shared_ptr_count
{
std::string name_;
};
boost::shared_ptr_embedded data_;
public:
SharedName(std::string n) : data_(new Data) { data_->name_ = n; }
const std::string& GetName() { return data_->name_; }
SharedName& operator=(std::string n) { data_->name_ = n; return
*this; }
};
I think this would be a valuable addition to the boost suite. How would I
go about submitting this?
Scott Maxwell
PocketPurchase, Inc.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Graph] Improved creation of visitors from functionobjects
On Thursday 17 April 2003 10:04 am, Vladimir Prus wrote: > Douglas Gregor wrote: > > The efficiency won't be any worse than using a bind object elsewhere in a > > program. The do_on_XXX functions merely augment the visitor list of > > dfs_visitor and return a new dfs_visitor object. > > This precisely what worries me -- bind might not be very efficient. I may > be a overly concerned about efficiency at the moment --- recently wrote a > graph algorithm in BGL which turned out to be 100 times slower that a > simply-coded one :-( Not sure if this is BGL's fault or the problem with > the algorithm, though. Not to blame the victim, but in my experience the abstraction penalty doesn't go above, say, 20x in the worst case, so it sounds like an algorithmic problem to me. Granted, figuring out the actual complexity of a particular instance of any BGL algorithm can be a nontrivial task: one property map with non-constant access time can sink the whole thing. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [type_traits] Missing include for function traits?
John Maddock wrote: Yes, I made it gcc specific, also added a similar fix for is_union, but not for has_trivial_copy which also produces these warnings. Fixes will be in cvs towards the weekend - when I get my cvs access up again (I only have limited mail access at present). Looks good. That means, I think it will do the job - not that I like the #ifdef's :) Also, IIRC, the comment from Dave seen below is lying (due to changes that happened after he wrote it). Maybe we should fix this up, too. It would IMHO lead to the removal of the #ifdef-block, but I didn't wanted to mix it up with the fix for the warnings, so I left it out for now. Not quite - the fix is required if you can't pass non-copyable types through is_convertible, and that is still true for some compilers unfortunately, even if this has been fixed for most of them... Ah, thanks. And sorry to Dave. Hm, type traits are a good example for "never change a running system" I guess... :)) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: an xml-binary persistence library
Vladimir Prus wrote: b) versioning at the class level I implemented a binary serialisation library at my previous work place that was very similar to what has been described here. As for versioning, we left it up to the class. But implemented it in all classes. All classes stored a version number as the first item they wrote to the archive and then read it back in to know how to load them selves. Not sure if it is the ideal way, but it worked. It would be nice not to have to handle this in every class, though. I suppose it could be handled by the class registration. Give the registration info a version number. The in the reading method, the version number is passed in by the archive which the archive reads from the file. The other issue we hit was that class names took up a lot of space in a binary archive so we went for type number (which was generated during class registration for each class). The problem here is that the order of registration is then important to preserve the numbers so that subsequent builds of the software can load up the old files. We handled this by storing the type map in the file at the end (i.e. a list of type names/type numbers). This was read in and another map created that mapped the numbers in the file to the current class registration numbers. This is done as soon as the archive is opened for reading. It allows you to re-order the class registrations without worrying about not being able to open old files. Another way to do it, rather than have a list in the file is to store the type name only when the first object of that type is saved. Subsequent saves of that object will only store the type number. When reading, the map is built up as objects of the various types are read back in. A suggestion for being able to use the same code for loading/storing objects: I'm quite happy for the binary archive to just ignore the first parameter and write the value out, but as others aren't, then maybe a duplicate set of methods in the binary archive which don't take that parameter. This would allow you to write the same code for reading and writing xml/binary, but if you really didn't want the performance hit on your object in binary mode, then you could use the other methods and would have to have 2 lots of code. I suppose the xml version could support the methods without comments as well, and just write the type e.g. 10 Hello and this then leaves it up to the users of the library to how they wish to serialise. Another difference we had, was that we had a base interface called Persistent which all objects stored polymorphically through the archive used. I like the idea of making the storing/loading method template based, so you don't need an interface class to store objects. Maybe you could customise the method that is called during the class registration process also? (with defaults). People may then be able to specify the same method for xml and binary or different ones, which means they wouldn't have to find out at run time in the serialise method as to whether it was XML or binary. I don't know if this could be done with templates, though. We also used a static Create method that was stored during the registration process which meant we could make the default constructor protected or private to stop people calling it accidently if it was only there for the persistent archive. Another way to do this is to make a constructor that takes the archive so the object could serialize itself at construction time as well as later on during its life. Just some thoughs, but I really would like to see a library like this added to boost at some point. Cheers Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [type_traits] Missing include for function traits?
John Maddock wrote: Yes, I made it gcc specific, also added a similar fix for is_union, but not Just looked at is_union. That won't work, I guess. You need to add a typedef T cvt; or change it to BOOST_STATIC_CONSTANT(bool, value = BOOST_IS_UNION(T)); Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
James Curran wrote: > Vladimir Prus wrote: >> The intent is to get/change the part of leaf name after the first >> dot. > > um.. After the FIRST dot or the LAST dot. > > In Win32, "james.m.curran.txt" the extention is "txt", not > "m.curran.txt" Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are legal. The 'extension' is '.blip', not '.baz.blip' and not '.baz.blip:blat'. The very existence of such special cases probably means that such a function would be a good addition to the filesystem library. -cd ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RFC shared_ptr_embedded
Scott Maxwell wrote: > Hi All, > > I have created a new shared_ptr class called shared_ptr_embedded. > This is based on the code for intrusive_ptr but differs in one > important > aspect. The struct/class pointed to is required to be derived from > shared_ptr_count. The latter class contains an 'int count_' and > methods > for adding and removing references. This allows you to have the count > embedded in your primary data, rather than having a separate > allocation for count as shared_ptr does. This is what intrusive_ptr is for. Just define intrusive_ptr_add_ref and intrusive_ptr_release for your count class. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sandbox iterator adaptors update
Vladimir Prus <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> While at the ACCU and committee meeting, Jeremy, Thomas and I did a >> whole bunch of work on the sandbox version of iterator adaptors and >> the new categories in boost/iterator and libs/iterator. We think that >> the implementations are quite stable now and are trying to get a >> proposal together for the post-meeting mailing. Please check it out >> and see how it works for you! We'd value your comments. > > I've a very basic question for now: how to I convert "*rst" files in > documentation to something nice-looking, like hmtl? ReStructuredText: http://docutils.sourceforge.net/README.html#quick-start Use the html.py script in the tools/ directory -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] NO_MEMBER_TEMPLATE_KEYWORD on HPUX
Looking at
http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#cast_test acc
you could say that aCC supports no member template keywords.
However, the code sample at the bottom compiles fine ?!
Nevertheless, I'd like to add the patches in attachment to take
the 53800 version of HP_aCC into account, set the
BOOST_NO_MEMBER_TEMPLATE_KEYWORD
and disable the pthreads.
#include
template < bool b >
class if_true
{
public:
template < class Y, class N >
struct then { typedef Y type ; } ;
} ;
class B : public if_true< true >
:: template then< int, double >
{
} ;
int main()
{
std::cout << __HP_aCC << std::endl ;
B b ;
return 0 ;
}
Index: hpux.hpp
===
RCS file: /cvsroot/boost/boost/boost/config/platform/hpux.hpp,v
retrieving revision 1.10
diff -r1.10 hpux.hpp
25,31d24
< // HPUX has an incomplete pthreads implementation, so it doesn't
< // define _POSIX_THREADS, but it might be enough to implement
< // Boost.Threads.
< #if !defined(BOOST_HAS_PTHREADS) && defined(_POSIX_THREAD_ATTR_STACKADDR)
< # define BOOST_HAS_PTHREADS
< #endif
<
Index: hp_acc.hpp
===
RCS file: /cvsroot/boost/boost/boost/config/compiler/hp_acc.hpp,v
retrieving revision 1.13
diff -r1.13 hp_acc.hpp
39a40,43
> #if (__HP_aCC <= 53800 )
> #define BOOST_NO_MEMBER_TEMPLATE_KEYWORD
> #endif
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
: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... Carl Daniel wrote: > > James Curran wrote: > > Vladimir Prus wrote: > >> The intent is to get/change the part of leaf name after the first > >> dot. > > > > um.. After the FIRST dot or the LAST dot. > > > > In Win32, "james.m.curran.txt" the extention is "txt", not > > "m.curran.txt" > > Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are > legal. The 'extension' is '.blip', not '.baz.blip' and not > '.baz.blip:blat'. > > The very existence of such special cases probably means that such a function > would be a good addition to the filesystem library. > > -cd > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ 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: an xml-binary persistence library
Vladimir Prus wrote: >> iii) requirement to pre-register classes to be saved as pointers >> through a base class >Was it ever considered a problem. You surely have to register a class in >order to deserialize it (Java can create a class given its name, but we're >in C++). I refering to the issue of "forward declaration" vs "module level registration" We spent a quite of bit of time on this as well as type_info, etc. I have added the "module level registration which I think would satisfy the concerns you raised and conflict with my concerns. But I want to pass through it one more time to unitify the treatment of external type ids. This is in part inspired by G Rozenthal's concern that RTTI should not be required. I don't really share the concern. But if things are factored in the right way the external type id issue becomes a replaceable component and we won't have to spend a lot of time on the issue. >> iv) requirement to have separt save/load code for serialization functions >I though about it just recently, and stubmled upon the issue of >const-correctness. Probably, separate save/load is OK, since I don't know >any good alternative solution. I was always a fan of "const-correctness" that came with the save/load system. Also the save/load system permitted a finer granularity such that a program that only read would only have to import half the headers and library code. (Same for programs that only write archives). However, I was sensitive to the redundance of the save/load system and came to appreciate the usage of the & operator for both saving an loading - even at the cost of const - correctness. (thanks to jens maurers effort) After trying out a number of alternatives I came to a solution which permits either to be used on a class by class basis. >Can we have a look at it? Probably, putting it to boost-sandbox is good >idea. I'm really interested to see how it applies to use case I have at >hand. I don't feel its quite ready for that. Some things are still in the experimental stage and I'm still weighng alternatives. After these things are settled I would better be able to provide explanations for the choices I made. Please send me your use case. I am very interested in it. Hopefully soon I will have the package working at the level I desire. Then there's a huge amount of work (re)writing and expanding the documentation and finer granularity test cases. oh then there's the jam build. and then making things work on more compilers,etc. In all its a very large job. So my preferred plan would be: a) finish what I'm doing as far as features are concerned b) expand documentation a minium amount c) expand test cases a minimum amont d) send it privately to boosters who have shown a special interest in this package e) make some more changes f) If there's still interest, upload it to CVS g) see what happens. This would still be a couple of months away. > b) versioning at the class level > >It would be nice, BTW, to have optional versioning The question about "optionality" features is much more intricate than it first appears. Other features that are candidates for optionality are: a) serialization of pointers b) versioning c) tracking of object addresses to eliminate extraneous copies d) bypassing the serialization system for special cases and some of these features interact with each other. After much experimentation I have made a system which permits selection of optional serialization features on a per class basis. It turns out that ALL the issues raised in the review, including those that I dismissed, are being addressed. I didn't really intend to do this I had resolved to improve the quality of the implementation and leave most of the feature decisions unchanged as I saw them as ireconcilable trade offs. I was much surprised to discover that improving the implementation made apparent that what I had thought were trade offs where in fact artifacts of implementation stratagy decisions. Note to potential library submitters: The boost review process is far more rigorous than what one is normally accustomed to and I suspect that few are really prepared for it. On the other hand, I have no doubt that this the reason for the incredible high quality and utility of the boost libraries. The only thing I can't explain why anyone would subject himself to this. Yet here I am. oh well. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Passing template-ids as macro parameters
Terje Slettebø wrote:
> Is there some way (using PP-lib, or whatever), to pass a template-id
> with more than one parameter (thus, it contains at least one comma),
> to a macro?
>
> E.g.:
>
> #define TEST(a) test t;
>
> TEST(std::pair) // Won't work
>
> Maybe some sort of variation of BOOST_PP_IDENTITY:
>
> #define BOOST_PP_IDENTITY1(a) a
> #define BOOST_PP_IDENTITY2(a,b) a,b
> #define BOOST_PP_IDENTITY3(a,b,c) a,b,c
>
> etc.
>
> TEST(BOOST_PP_IDENTITY2(std::pair)) // Now ok
I'll answer all three of these emails at once, since they are about the same
thing. First, the above will cause problems, specifically problems like this:
#define T1(a) T2(a)
#define T2(a) test t;
#define IDENTITY2(a, b) a, b
T1(IDENTITY2(std::pair)) // error
I.e. by the time that T2 is invoked, IDENTITY2 has already expanded, which
yields too many arguments to T2. What we need is a general solution and a set
of conventions for passing types. This is difficult without variadics to do
with the preprocessor itself. Specifically, you have to use the core language:
template struct wrap {
typedef T type;
};
template struct wrap {
typedef T type;
};
#define TYPE(x) wrap::type
TYPE((int)) // okay
TYPE((std::pair)) // okay
However, this has its own problems. Specifically, it is using function types to
store the type--which is inside parentheses and therefore protected from the
preprocessor. The use of function types with cause certain things to error:
TYPE(( void )) // error
TYPE(( int (int, int) )) // function type altered to pointer-to-function
TYPE(( int[2] )) // array altered to pointer
There is only one other language construct that might be of use here:
pointers-to-members. Specifically, it is parenthesized, yet does not undergo
promotion/alteration when used in a parameter list. However, it is intrusive:
template struct wrap;
template struct wrap {
typedef T type;
};
#define TYPE(x) wrap::type
TYPE(( std::pair::* ))
^^^
Also, this cannot be used for non-class types--which can still have commas in
them:
template struct typelist {
typedef T head;
typedef U tail;
};
TYPE(( typelist::head::* )) // error
So, without variadic macros, there is no "good" solution. Instead, you have to
resort to hacks that require you to know the number of unbound commas in the
type:
#define IN(s, x) (s) x
#define OUT(x) BOOST_PP_TUPLE_REM x
#define M1(type) M2(type)
#define M2(type) OUT(type)
MACRO( IN(2, (std::pair)) )
In other words, it is a complete pain to deal with them without variadics.
*With* variadics, however, you can do a little better.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RFC shared_ptr_embedded
This is what intrusive_ptr is for. Just define intrusive_ptr_add_ref and intrusive_ptr_release for your count class. Unless I have missed something, intrusive_ptr has the following issues: 1. You must declare intrusive_ptr_add_ref and intrusive_ptr_release as top-level functions that take a pointer to your class. This can be problematic if your client class is a nested private class as in my prior example. 2. You must define the functionality of those two functions. While the functionality is trivial, it still needs to be done manually for each class. Anything manual is subject to error. The shared_ptr_embedded and shared_ptr_count pair solve both issues. Scott Maxwell PocketPurchase, Inc. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RFC shared_ptr_embedded
Scott Maxwell wrote: >> This is what intrusive_ptr is for. Just define intrusive_ptr_add_ref >> and intrusive_ptr_release for your count class. > > Unless I have missed something, intrusive_ptr has the following > issues: > > 1. You must declare intrusive_ptr_add_ref and intrusive_ptr_release as > top-level functions that take a pointer to your class. This can be > problematic if your client class is a nested private class as in my > prior example. > > 2. You must define the functionality of those two functions. While > the functionality is trivial, it still needs to be done manually for > each > class. Anything manual is subject to error. > > The shared_ptr_embedded and shared_ptr_count pair solve both issues. No, you only need to implement the addref/release functions for the base class. See libs/smart_ptr/test/intrusive_ptr_test.cpp for an example. A future boost release will probably contain such a base class. I didn't want to introduce one at this time since it may have created confusion, as 1.29 had boost::counted_base that was automatically recognized by shared_ptr. In 1.30 shared_ptr no longer supports intrusive counting. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Passing template-ids as macro parameters
>From: "Paul Mensonides" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> > Is there some way (using PP-lib, or whatever), to pass a template-id
> > with more than one parameter (thus, it contains at least one comma),
> > to a macro?
> >
> > E.g.:
> >
> > #define TEST(a) test t;
> >
> > TEST(std::pair) // Won't work
> >
> > Maybe some sort of variation of BOOST_PP_IDENTITY:
> >
> > #define BOOST_PP_IDENTITY1(a) a
> > #define BOOST_PP_IDENTITY2(a,b) a,b
> > #define BOOST_PP_IDENTITY3(a,b,c) a,b,c
> >
> > etc.
> >
> > TEST(BOOST_PP_IDENTITY2(std::pair)) // Now ok
>
> I'll answer all three of these emails at once, since they are about the
same
> thing. First, the above will cause problems, specifically problems like
this:
>
> #define T1(a) T2(a)
> #define T2(a) test t;
>
> #define IDENTITY2(a, b) a, b
>
> T1(IDENTITY2(std::pair)) // error
>
> I.e. by the time that T2 is invoked, IDENTITY2 has already expanded, which
> yields too many arguments to T2.
Right. However, for simple use (only one level of macro expansion), this
works, and has the advantage of being simple and non-intrusive to use.
> What we need is a general solution and a set
> of conventions for passing types. This is difficult without variadics to
do
> with the preprocessor itself. Specifically, you have to use the core
language:
>
> template struct wrap {
> typedef T type;
> };
>
> template struct wrap {
> typedef T type;
> };
>
> #define TYPE(x) wrap::type
>
> TYPE((int)) // okay
> TYPE((std::pair)) // okay
>
> However, this has its own problems. Specifically, it is using function
types to
> store the type--which is inside parentheses and therefore protected from
the
> preprocessor. The use of function types with cause certain things to
error:
>
> TYPE(( void )) // error
> TYPE(( int (int, int) )) // function type altered to pointer-to-function
> TYPE(( int[2] )) // array altered to pointer
Right. It's similar to Aleksey's "round lambda".
> There is only one other language construct that might be of use here:
> pointers-to-members. Specifically, it is parenthesized, yet does not
undergo
> promotion/alteration when used in a parameter list. However, it is
intrusive:
>
> template struct wrap;
> template struct wrap {
> typedef T type;
> };
>
> #define TYPE(x) wrap::type
>
> TYPE(( std::pair::* ))
> ^^^
> Also, this cannot be used for non-class types--which can still have commas
in
> them:
>
> template struct typelist {
> typedef T head;
> typedef U tail;
> };
>
> TYPE(( typelist::head::* )) // error
>
> So, without variadic macros, there is no "good" solution. Instead, you
have to
> resort to hacks that require you to know the number of unbound commas in
the
> type:
>
> #define IN(s, x) (s) x
> #define OUT(x) BOOST_PP_TUPLE_REM x
>
> #define M1(type) M2(type)
> #define M2(type) OUT(type)
>
> MACRO( IN(2, (std::pair)) )
I'm not sure how this latter solution could be used. How could MACRO
retrieve the type being passed?
Thanks. :)
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RFC shared_ptr_embedded
No, you only need to implement the addref/release functions for the base class. See libs/smart_ptr/test/intrusive_ptr_test.cpp for an example. A future boost release will probably contain such a base class. I didn't want to introduce one at this time since it may have created confusion, as 1.29 had boost::counted_base that was automatically recognized by shared_ptr. In 1.30 shared_ptr no longer supports intrusive counting. Hmm, sounds like that is essentially what my shared_ptr_count turned out to be. How about just renaming shared_ptr_count to intrusive_ptr_count_base or something like that and including it in the intrusive_ptr.hpp file. That way people can roll their own if they like or just use the included mechanism if that is more convenient. Seems better than leaving it as an exercise for the user. Also, I added a 'release' method to my version of intrusive_ptr. I needed this to get out of a circular reference situation. Scott Maxwell PocketPurchase, Inc. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Types and Programming Languages
We have been using this book on a course in programming language foundations - and I strongly recommend it. It is well written, the proofs are well explained and detailed (at least in the beginning - later on he assumes that we are adept at structural induction), the exercises are very helpful, and the insights provided regarding evaluation semantics and type safety are delightful. In the first 11 chapters, the author introduces a very simple untyped language with three syntactical forms, specifies the evaluation semantics of this language, then introduces a pure lambda calculus and does the same (also shows us how to do recursion in a pure lambda calculus! - this is kool because lambdas don't really have names), then combines the two languages, then adds types to these languages and shows us what type safety is and how we can prove it. He also shows how to add extensions (let, records, sequencing) to our simple lambda calculus while proving type safety. We are midway through the chapter on adding references to our lambda calculus, and if i may repeat myself, the book is a delightful read. (I am especially looking forward to the section that shows how to prove type safety in a language that allows subtyping) I can't imagine someone with your interests not enjoying this book ;-) regards, Faisal Vali David Abrahams wrote: > > While I was in Oxford I happened to pick up a copy of this book at > Blackwell's (the greatest bookstore in all of England): > http://www.cis.upenn.edu/~bcpierce/tapl/ > > It seemed like a beautifully understandable tour of type theory and > its application in real programming languages. It even had a section > on Jeremy's latest obsession: existential types. Does anyone else > have experience with this book? I'm planning to buy it unless > someone can tell me that they know of a better one. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Passing template-ids as macro parameters
Terje Slettebø wrote: >> MACRO( IN(2, (std::pair)) ) > > I'm not sure how this latter solution could be used. How could MACRO > retrieve the type being passed? You have to encode the type in a structure, and then decode it when you actually need it: #define IN(s, x) (s) x #define OUT(type) BOOST_PP_TUPLE_REM type #define MACRO(z, i, type) \ BOOST_PP_CAT(class T, i) = OUT(type) \ /**/ template< BOOST_PP_ENUM( 3, MACRO, IN(2, (std::pair)) ) > class xyz; Passing in an intermediate value like this: #define ID2(a, b) a, b #define MACRO(x) x MACRO( ID2( std::pair ) ) ...is error prone (and dangerous). :( Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
James Curran wrote: > Vladimir Prus wrote: >> The intent is to get/change the part of leaf name after the first >> dot. > > um.. After the FIRST dot or the LAST dot. > > In Win32, "james.m.curran.txt" the extention is "txt", not > "m.curran.txt" Certainly the last. My existing code uses the last dot, in fast, and I've just typed wrong. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Jason House wrote: >> James Curran wrote: >> > Vladimir Prus wrote: >> >> The intent is to get/change the part of leaf name after the first >> >> dot. >> > >> > um.. After the FIRST dot or the LAST dot. >> > >> > In Win32, "james.m.curran.txt" the extention is "txt", not >> > "m.curran.txt" >> >> Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are >> legal. The 'extension' is '.blip', not '.baz.blip' and not >> '.baz.blip:blat'. > :blat ??? > > 1. I have no clue what that would mean I, too, had not clue about this until now. > 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... Does those "alternate streams" belong to filesystem library at all? For one thing, the ':' symbols is not allowed anywhere except for root name. For another thing, on all systems but NTFS, "bar.baz.blip:blat" would be considered as having "blip:blat" extension, and making the function behave differently on NTFS is confusing. Lastly, the 'extension' function is supposed to do only syntax transformation, but to tell if you're on Fat32 or NFTS you'd need to ask operating system... - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PP: MSVC BOOST_PP_REPEAT + BOOST_PP_SEQ_ELEM bug
Aleksey Gurtovoy wrote: > Paul Mensonides wrote: >>> Yep, they do - that's why I named it "BOOST_PP_REPEAT + >>> BOOST_PP_SEQ_ELEM bug". >> >> That is what I figured, but I wanted to make sure that the (a, b, c) >> wasn't causing a problem--which it shouldn't be anyway. I'll look >> at this later when I have time to install VC6 on my other computer. > > That would be much appreciated. Okay, this is "fixed," but before you update, this is the reduction of the problem. First, it has nothing to do with BOOST_PP_REPEAT per se. Rather it is the kind of instability that I mentioned before relative to IS_UNARY, since SEQ_ELEM does a similar kind of thing. Take a look: #include #define X() ... #define A(seq) BOOST_PP_SEQ_ELEM(0, seq) #define B(seq) (BOOST_PP_SEQ_ELEM(0, seq)) #define C(seq) ID( BOOST_PP_SEQ_ELEM(0, seq) ) #define D(seq) ID(( BOOST_PP_SEQ_ELEM(0, seq) )) #define ID(x) x A( (X)(Y) ) // X B( (X)(Y) ) // (X) C( (X)(Y) ) // X D( (X)(Y) ) // 0 The last one is wrong. It should expand to (X). This should be fixed now, but it illustrates the kind of encapsulation issues that I was referring to before. As far as the other bug is concerned, here is the reduction of the problem: // entire file... #define M() M VC6 expects to find the open parentheses of a macro invocation, but instead it finds EOF. There is nothing that I can do to fix this one. However, VC7 seems to have fixed this problem, at least. Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
