Re: [boost] Re: indentation on streams
John Torjo on 23 Apr 2003 06:16:20 -0700 (PDT) wrote: [snip] > > 2. binding marg_stream to a std::ostream& couples them too much IMHO > (that is, the marg_stream variable is coupled to the other stream). > This actually came to me when I wanted to use col_io together with my > thread_safe_log library. > > The point I'm trying to make (the way I see it) is that I'm not sure you > should keep a reference to a std::ostream inside marg_ostream. First of all, > because the reference might become invalid if the underlying stream is > destroyed (which actually happened in my case, since I use > temporaries But doesn't the indent_ostream store an std::ostream& in m_underlyingOut, and doesn't this mean indent_ostream suffers the same problem? > heavily). Second, the underlying stream and the marg_ostream variable might > go out-of-sync (formatting information, state, etc.) which could > cause The code at boost/files/col_io/test_ostreambuf_decorator.zip shows an unbuffered version which, because it's unbuffered, is always in-sync. However, I don't think this is what you want, but maybe a variation of it. I don't think it's what you want because it replaces the streambuf in the "final" ostream with a linked list of ostreambuf_decorator_abs's terminated by the "original" ostreambuf of the ostream. Hence, the final (actually only) ostream writes to the ostreambuf_decorator_abs at the head of the list, which does it's transform and sends the result to the next ostreambuf_decorator_abs or the final ostreambuf, which was the original ostreambuf in the only ostream. However, as you've indicated, this final ostream may disappear; hence, you want "endpoint" this "pipeline" of ostreambuf_decorator_abs's to be changeable. More precisely, you want the endpoint to be: string_stream_type m_pStreamBuffer; defined in: template< class char_type , class traits_type = std::char_traits< char_type> > class basic_message_handler_log_streambuf; where: typedef std::basic_ostringstream< char_type> string_stream_type; as defined in message_handler_log.hpp in your upload: http://groups.yahoo.com/group/boost/files/thread_safe_log.zip And all this means, I think, that if the endpoint of the pipeline is m_pStreamBuffer instead of the final ostream's streambuf, then you'd get what you want. Is that right? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 05:58 PM 6/27/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> Now you might ask, "what about the interface, doesn't the copyright >> cover that too?" The answer is "no", as has been fought out in court >> several times. Ask a lawyer for details, but interfaces themselves >> aren't covered by copyright. The docs are covered, the header is >> covered, the implementation, test cases, etc, are all covered, but not >> the conceptual interface. > >We ought to put this in the license FAQ. Done. Once we think the license background page is pretty stable, perhaps the lawyers can take a quick look at it to make sure we haven't said anything totally wrong. (Dave is the Boost point person in dealing with the lawyers; he deserves a lot of credit for persevering in getting busy people to focus on Boost, and getting them to understand the Boost culture.) --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 01:26 PM 6/27/2003, Alisdair Meredith wrote: >Gregory Colvin wrote: > >> It seems that doing it by reference to a web page amounts to Boost >> reserving >> the right to change terms in the future, possibly to the disadvantage >> of the >> authors and users. But I see lots of code that refers to the GPL that >> way, >> so this is another question for the lawyers. > >Oh, I'd missed that. I assumed the link would reference the license in >the downloaded distribution, rather than the online version. That way >you are bound to the license you downloaded, rather than a license >potentially changing without your notice. > >Plus, not all PCs with Boost distributions are going to have Internet >connections. In these cases you really do need to include the license >with the distribution. [Especially as you are binding distribution of >the license as a requirement (in appropriate circumstances)] Yes, the link should certainly reference the license included in the distribution. But there needs to be a backup link to the web site so if the file gets separated from the distribution, there is still a way to reach the license, docs, etc. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::filesystem::path bug?
Pardon me if this has already been noted or
discussed..
I seem to have found a bug/issue with
boost::filesystem::path. It dies upon being created with a filename that begins
with a space. Being that these are legal filenames on several
platforms, it would appear that this is undesirable behavior.
Quick example:
boost::filesystem::path p;
p = boost::filesystem::path(" .txt");
.// Three spaces
Result, upon execution, is "Aborted" to stderr.
If anyone could shed some light, I'd appreciate it.
Or just tell me "That's how it's supposed to be" -- that's cool
too.
--Tim
[boost] Re: Draft of new Boost Software License
David Abrahams wrote: > > Thomas Wenisch <[EMAIL PROTECTED]> writes: > > > I have been told by previous employers' lawyers that the word "Copyright" > > is in fact required. > > That matches my understanding. Also that (C) has no legal value. http://www.iusmentis.com/copyright/crashcourse/requirements (Formalities for obtaining copyright protection...) regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Thomas Wenisch <[EMAIL PROTECTED]> writes: > I have been told by previous employers' lawyers that the word "Copyright" > is in fact required. That matches my understanding. Also that (C) has no legal value. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes <[EMAIL PROTECTED]> writes: > Now you might ask, "what about the interface, doesn't the copyright > cover that too?" The answer is "no", as has been fought out in court > several times. Ask a lawyer for details, but interfaces themselves > aren't covered by copyright. The docs are covered, the header is > covered, the implementation, test cases, etc, are all covered, but not > the conceptual interface. We ought to put this in the license FAQ. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes wrote: > > At 10:27 PM 6/26/2003, Howard Hinnant wrote: [...] > company, and then moved to another company. Although no physical copy of > the source code was involved, the programmer had a good memory, and > basically just duplicated the prior effort. Yup. That's what "The Clean Room" is all about... Howard, and you're already seriously "contaminated", I'm afraid. ;-) http://digital-law-online.info/lpdi1.0/treatise27.html regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Fernando Cacciola wrote:
>
> Alexander Terekhov <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > Fernando Cacciola wrote:
> > [...]
> > > Motivated by A. Terekhov concerns, I think the license should, if at all
> > > possible, expressely PROHIBIT anyone, including the copyright holder,
> > > from patenting the covered Software and any implied intellectual production.
> >
> > That would make no sense.
> >
> Why?
Because a patent protects against the unauthorized manufacture,
use, sale... {subset of} rights that *ARE GRANTED* by a license
{subject to whatever requirements} we're discussing here. Also,
a public disclosure of an invention prior to the patent
application renders the invention no longer "novel" under the
IP laws of almost all countries outside North America. Finally,
AFAICS, a sort of "common practice" at companies practicing
"the open source" (e.g. IBM) is to seek the patent protection
and grant rights to the open source community (again: CPL *is*
the preferred license) but seek "compensation" from the
proprietary "closed source" competitors. What's wrong with that?
regards,
alexander.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] PP interest in facilities for variablelengthargumentlists
> #define IS_END(...) IS_END_I(__VA_ARGS__,) > #define IS_END_I(x, ...) \ > IS_VARIADIC(IS_END_II x,) \ ^^^ > /**/ > #define IS_END_II(a, b, c, d, e, f, g, h, i, j, ...) __VA_ARGS__ Sorry, mistake. You need a bunch of commas here rather than just one. Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 09:33 PM 6/26/2003, Fernando Cacciola wrote: >Motivated by A. Terekhov concerns, I think the license should, if at all >possible, expressely PROHIBIT anyone, including the copyright holder, >from patenting the covered Software and any implied intellectual >production. That's an interesting issue. I've added it to the list. (Rather than peppering the legal folks with issues one-by-one, I'll build up a list for a few more days and then send it to them all at once.) >BTW, make sure to express our gratitude to those lawers for their time and >great work!! Will do. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 12:36 AM 6/27/2003, Rene Rivera wrote: >>Ha! You've never dealt with ISO, I guess. They are a world unto themselves >>and their views on copyrights are pretty high-handed. > >No I haven't. And I get the fealing that I should run away if said beast >approaches ;-) Well, luckily the standards committee has a sort of chairman called the Convenor, currently Herb Sutter, whose job it is to deal with ISO. So don't let the idiosyncrasies of ISO worry you if you are interested in participating in standards work:-) --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
At 09:53 AM 6/26/2003, William E. Kempf wrote: >Paul A. Bristow said: > >> And: >> >> // (C) Jane Programmer, 2003 >> // See www.boost.org/license for license terms and conditions >> // See www.boost.org/libs/janes-lib for documentation >> >> Looks fine to me, though I prefer "Copyright" to (C) Yes, I do too. The above was meant to be an example; the lawyers will help with the exact wording. >It looks simple, but would it be legally binding? For instance, say I >release my software with this Boost license today, using the above text >(and assuming the links point to the license, of course). Now, a year >from now something is found to be problematic with the license and the >lawyers tweak it. I can see a case being made that existing projects >could from that point on be changed to be covered by this new license, but >previous releases would seem to have to be legally bound to the license as >it existed then. The above links, however, will not refer to this older >license, but to the newer license. This seems to make the above scheme a >little legally shakey, no? I thought you had to physically include the >license with distributions and have the individual file licenses refer to >this distributed license? Yes, those are all issues. In non-Boost code, I've seen wording something like "See the attached license; if it is missing see www.foo.org/license." Maybe something like that is what will be recommended. >That's obviously a question for the lawyers, as us laymen will only be >guessing ;). > >But it would be nice to just refer to the license instead of repeating it >in every single file. They've already signed off on the concept of a single copy of the license. It is just the exact way to refer to it that hasn't been finalized. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
At 07:14 AM 6/27/2003, Alexander Terekhov wrote: > >Beman Dawes wrote: >[...] >> The point of the Boost license is to grant various permissions to >everyday >> users. Special uses such as ISO standardization, or maybe some >corporation >> that wants a different license, can be dealt with on a case-by-case >basis. >> That's a nice aspect of the developer retaining copyright. The developer >> can cut a special deal if he or she wishes (but of course is under no >> obligation to do so). > >Hmm. I just can't believe that ISO paid something to "BS/K&R/PJP". I don't think any money changed hands. The issue was that those folks wanted to protect the copyrights on their books. That was all they were asking. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
At 10:27 PM 6/26/2003, Howard Hinnant wrote: >On Thursday, June 26, 2003, at 07:51 PM, Beman Dawes wrote: > >> A copyright, unlike a patent, just applies to the actual >> representation. So unless another implementation actually made a >> literal copy of the Boost code, the other implementation would not be >> a derived work of the Boost code and so would not have to follow the >> Boost license. > > >Thanks Beman. That was most informative and useful. Well, do ask a lawyer if you've got any serious copyright questions. The real world is messy. For example, there have been cases (including some involving software) where the copyrighted work wasn't physically copied, but the courts still ruled infringement had occurred. The cases I'm aware of were (1) a book which used the same characters, plot, and many important other aspects as the copyrighted work, (2) a photograph which was set up to mimic a famous copyrighted photo in every respect, and (3) a software program which used the same organization, functional decomposition, algorithms, variable names, etc, etc, etc, as a copyrighted program. In the case of the program, the same programmer wrote the first program for one company, and then moved to another company. Although no physical copy of the source code was involved, the programmer had a good memory, and basically just duplicated the prior effort. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in FC++?
Brian McNamara wrote: I would like to see if there is interest in incorporating the FC++ library into Boost. I had no clue what FC++ was, but hunted down some information on it. It seems pretty cool... Being new, I'll hope for lots of reuse of other boost features, and quality documentation. I would also hope that whatever the naming is, that it would foster intuition into the namings of previously unknown aspects of the library. If there is a tight merger between FC++ and boost, I'd probably insist on keeping with boost naming conventions as much as possible. That would really help a user with an intermediate level of familiarity with the library use it effectively. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] qt and msvc
Hello all, I've just started playing with bjam and I was wondering if anyone could enlighten me about using qt and msdev 6.0. Reading the docs seems to indicate that qt can't be use with msvc but seems like it should be a straight forward thing to do. Thanks -Gedalia Pasternak ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
Alisdair Meredith wrote: Gregory Colvin wrote: It seems that doing it by reference to a web page amounts to Boost reserving the right to change terms in the future, possibly to the disadvantage of the authors and users. But I see lots of code that refers to the GPL that way, so this is another question for the lawyers. Oh, I'd missed that. I assumed the link would reference the license in the downloaded distribution, rather than the online version. That way you are bound to the license you downloaded, rather than a license potentially changing without your notice. Most licenses solve this issue by version numbering, don't they? The GPL certainly does. A typical license reference for a GPLed file: * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. You wouldn't necessarily want to include the "any later version" clause, but boost might want to version the license... Plus, not all PCs with Boost distributions are going to have Internet connections. In these cases you really do need to include the license with the distribution. [Especially as you are binding distribution of the license as a requirement (in appropriate circumstances)] I would agree with that. -- --- Kevin Lynch voice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USAhttp://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Gregory Colvin wrote: > It seems that doing it by reference to a web page amounts to Boost > reserving > the right to change terms in the future, possibly to the disadvantage > of the > authors and users. But I see lots of code that refers to the GPL that > way, > so this is another question for the lawyers. Oh, I'd missed that. I assumed the link would reference the license in the downloaded distribution, rather than the online version. That way you are bound to the license you downloaded, rather than a license potentially changing without your notice. Plus, not all PCs with Boost distributions are going to have Internet connections. In these cases you really do need to include the license with the distribution. [Especially as you are binding distribution of the license as a requirement (in appropriate circumstances)] -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Alexander Terekhov <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Fernando Cacciola wrote: > [...] > > Motivated by A. Terekhov concerns, I think the license should, if at all > > possible, expressely PROHIBIT anyone, including the copyright holder, > > from patenting the covered Software and any implied intellectual production. > > That would make no sense. > Why? Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
On Thu, 26 Jun 2003, Paul A. Bristow wrote: > > // (C) Jane Programmer, 2003 > // See www.boost.org/license for license terms and conditions > // See www.boost.org/libs/janes-lib for documentation > > Looks fine to me, though I prefer "Copyright" to (C) > > Paul I have been told by previous employers' lawyers that the word "Copyright" is in fact required. A claim of copyright must include the word "Copyright" or the copyright symbol (a circled C), and the year of the copyright. In the US, a capital C in parenthesis does not carry the legal meaning of the word copyright or the copyright symbol. Since ASCII doesn't offer a copyright symbol, we must include the word copyright. However, the same lawyers suggested including both "Copyright" and "(C)", as other countries may not accept the word Copyright, but might accept the (C). In any event, this is a really short and easy question for the lawyers. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Draft of new Boost Software License
On Thursday, Jun 26, 2003, at 07:53 America/Denver, William E. Kempf wrote: ... But it would be nice to just refer to the license instead of repeating it in every single file. Though this license is brief enough that inclusion is no big deal. It seems that doing it by reference to a web page amounts to Boost reserving the right to change terms in the future, possibly to the disadvantage of the authors and users. But I see lots of code that refers to the GPL that way, so this is another question for the lawyers. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
Paul A. Bristow said: > > > | -Original Message- > | From: [EMAIL PROTECTED] > | [mailto:[EMAIL PROTECTED] Behalf Of Rene Rivera > | Sent: Wednesday, June 25, 2003 8:26 PM > | To: Boost mailing list > | Subject: Re: [boost] Draft of new Boost Software License > | > | Spanish is my first, but English is a very close second. > > | The impression I got is that it's somewhat hard to parse as it is. | > | The second paragraph is long; and without any separators other than > the commas it's > | hard to read. > | > | Here's an edited version which might be better for non-english readers > to | understand: > | > | > | Permission is hereby granted ... > > | all derivative works of the Software. Unless such copies or derivative > works | are solely in the form of machine-executable object code > generated by a | source language processor. > > As someone whose first language really is english - unlike the majority > of ex-colonial Boosters :-)) > > I really must protest that the last 'sentence' isn't one! > > Seriously, overall I think this is excellent. > > It isn't meant to be read by human beings, only lawyers - and they are > used to this stuff. > > And: > > // (C) Jane Programmer, 2003 > // See www.boost.org/license for license terms and conditions > // See www.boost.org/libs/janes-lib for documentation > > Looks fine to me, though I prefer "Copyright" to (C) It looks simple, but would it be legally binding? For instance, say I release my software with this Boost license today, using the above text (and assuming the links point to the license, of course). Now, a year from now something is found to be problematic with the license and the lawyers tweak it. I can see a case being made that existing projects could from that point on be changed to be covered by this new license, but previous releases would seem to have to be legally bound to the license as it existed then. The above links, however, will not refer to this older license, but to the newer license. This seems to make the above scheme a little legally shakey, no? I thought you had to physically include the license with distributions and have the individual file licenses refer to this distributed license? That's obviously a question for the lawyers, as us laymen will only be guessing ;). But it would be nice to just refer to the license instead of repeating it in every single file. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Interest in FC++?
Brian McNamara wrote:
I would like to see if there is interest in incorporating the FC++
library into Boost.
Whoa! I've taken a look into FC++ at one occasion and found it most
impressive. :)
With regards to (1), I hope yes, but the Boost Lambda Library has a bit
of conceptual overlap with FC++, so I can imagine this issue being
potentially contentious. (FC++ and Lambda ostensibly provide much of the
same kinds of functionality, but while there is overlap, each library
does a lot of "its own thing" too. I (and Jaakko too, probably) can say
more about this if necessary.)
I've written some code of my own that uses lots of functoids (basically,
sort of not-quite continuations) and found out to my horror that
Boost::lambda (and the entire STL machinery in general) is not very
comfortable with them. If the inclusion of FC++ into Boost could provide
a greater compatibility between template struct ... { operator() ...}
and struct ... { template ... operator(); } worlds, that would be a
very worthwile goal in its own right. :)
Miro
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML API for C++, second round
On Fri, 2003-06-27 at 12:53, Anthony Williams wrote: > It was meant to be a description of semantics, in terms of a sample > implementation. > > A node that is not part of a document is a free-standing subtree that needs > adding to a document. If it is an element, then you can treat it as if it is > the root node of a document. If it is anything else, then you are more limited > in what you can do, but then what does it mean to perform an XPath query on a > PI? > > If the underlying API requires that the document is kept alive to keep the > nodes alive, then the wrapper class must handle this, whilst simulating the > above semantic description. If you look in one of my other posts you will see a description of just that. The thing that concerns me most about this is doc.find( path ).parent(); // non null (unless it found the root node) BUT... node n( doc.find( path ) ); n.parent(); // User may not expect this to be null n.document(); // or this You could have a node_container (or standalone_node) which had no parent or document methods but otherwise looked like a node. node_container n( doc.find( path ) ); n.parent(); // compile time error n.document(); // compile time error which is good but doesn't really solve the problem... n.first_child().document(); // null My preference is that if you want to make a copy of a node you have to have a new document... document doc2( doc.find( path ) ); doc2.root().parent(); // null but you would expect that (it's the root) doc2.root().document(); // non null as you would expect That way the user can rely on parent() to be non null for all but root nodes and document() can return a reference since it can never be null. > > You could copy the libxml2 tree into your own structure but then you are > > on your own when it comes to higher level things like xpath and xslt. > > I imagined that you would write forwarding functions for the underlying API, > so when you are given an Xpath query, you pass it on to the underlying API and > then wrap the result. Then you would need to keep libxml2 version of the tree too and synchronise any changes (or rebuild it every time you want to call a libxml2 function). -- Hamish Mackenzie <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] filtered/decorated streambufs
Paul A. Bristow wrote:
I also have an updated ('C++ 1998 STL standardized') version of James Kanze's
of filtering streambuf and filtering streams derived from his files at
www.gabi-soft.fr re-built for MSVC 7.1, (Could be posted on request).
Please do.
and his illuminating articles in C++ Report 1998 (attached).
There are also several examples of Inserting (decorating - not sure this term is
an improvement) and Extracting on input, and some tests (though not Boost style
I guess it depends on whether a person is more used to unix "filtering"
term or the person wants to emphasize the "design pattern" of the code
(as mentioned by Maxim Egorushkin on about 6/14).
[snip]
(More sadly, I was much impeded in trying to understand much of Larry's work in
progress on account of the bizarre layout - this would be an serious impediment
to acceptance by Boosters - see the Boost coding guidelines?)
OK. I concede it's bizarre, but I really didn't think it would impede
understanding. I've just been using it for years and it has some
distinct advantages (IMHO) over the Boost guidelines. However, I been
thinking about writing a program to just move the ";"'s to the end
of line using maybe spirit or wave. I was also thinking about using
a filter or decorator to do that :) Now I have more of a reason
to do that.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML API for C++, second round
Anthony Williams wrote: Hmm, just to check whether we are still talking about the same thing here: do we agree that there can't be a 'node' type, i.e. just a 'node_ref'/'node_ptr' ? You mean: have "node" as an abstract class, so you can't have any objects of that type, but you can have pointers and references? Sounds good. What's wrong with just having boost::shared_ptr and boost::shared_ptr, boost::shared_ptr ? no, I was alluding to the fact that in my case nodes are fully managed their parent. That implies that I can't have free floating nodes, i.e. outside the document tree. Well, I probably could but that would put the burden of managing the memory on the programmer's shoulders, while with the current model all memory is managed by libxml2. That's why I'm suggesting _ptr/_ref types in the first place. The expression dom::node_ptr parent = current.parent(); will return a reference to the parent node, i.e. it will create a temporary reference object, who's lifecycle is fully decoupled from the lifecycle of the actual node (who is managed by the document tree). You could have each node store a boost::weak_ptr pointing to its parent, which is converted to a boost::shared_ptr when you ask for it. That way, a child doesn't keep its parent alive (though parents should keep their children alive), but you can still traverse up the tree if you like. yes, when reimplementing a dom tree from scratch that may be an option. But as I said, I'm wrapping a C XML library that already does most of the work for me, and I'm trying to make the wrapper objects as lightweight as possible. Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: tokenizer comments
[EMAIL PROTECTED] wrote: >> From: Edward Diener [mailto:[EMAIL PROTECTED] >> >> More than a month ago I posted a correction to the tokenizer >> documentation >> to which no one replied: > > Sorry about that. > >> "The Tokenizer documentation for char_separator tokenizer >> function states >> that the default argument for the second template type is >> "char_traits". This is incorrect. The source code in >> token_functions.hpp clearly shows that the default argument is >> "std::basic_string::traits_type". Could this please be >> corrected ?" > > I don't think that the documentation should change (not counting the > change from char to Char), but rather the implementation. > std::basic_string::traits_type will always be > std::char_traits. If there are no objections to this (there > might have been some compiler > issue that justified the code, although there's no such indication in > the > CVS history), I'll change token_functions.hpp accordingly. You will probably want to change escaped_list_separator in the same way. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] vc6 + stlport + boost/unit_test.hpp
Thanks for your suggestion, now everything works. :-)
Following your advice I tried 1.30 and it would not link using bjam, so I
tried the dsw and it worked fine. I tried my test app and everything worked.
I tried compiling the 1.29 test lib using the dsw instead of bjam and
everything was fixed. I don't know what I did wrong using bjam but I guess
the dsws are there for a reason...
If you are curious here are the answers to your questions :
1. My test app :
#include "stdafx.h" // empty
#include "boost/test/unit_test.hpp"
using boost::unit_test_framework::test_suite;
void MyTest()
{
BOOST_CHECK( true );
}
test_suite*
init_unit_test_suite( int argc, char* argv[] ) {
test_suite* test= BOOST_TEST_SUITE( "vc6 + stlport + boost" );
test->add( BOOST_TEST_CASE( &MyTest ) );
return test;
}
> 2. Did you try to debug it? Where does it fail?
Yes. It failed at the end of the MyTest function. Here is the call stack.
NTDLL! 77f9180c()
NTDLL! 77fb168b()
NTDLL! 77fa60c0()
KERNEL32! 77e9f540()
_CrtIsValidHeapPointer(const void * 0x002f2e68) line 1697
_free_dbg_lk(void * 0x002f2e68, int 1) line 1044 + 9 bytes
_free_dbg(void * 0x002f2e68, int 1) line 1001 + 13 bytes
free(void * 0x002f2e68) line 956 + 11 bytes
operator delete(void * 0x002f2e68) line 7 + 9 bytes
_STL::__stl_delete(void * 0x002f2e68) line 99 + 33 bytes
_STL::__node_alloc<1,0>::deallocate(void * 0x002f2e68, unsigned int
4291875228) line 253 + 42 bytes
_STL::allocator::deallocate(char * 0x002f2e68, unsigned int
4291875228) line 360 + 19 bytes
_STL::_STLP_alloc_proxy >::deallocate(char
* 0x002f2e68, unsigned int 4291875228) line 507
_STL::_String_base >::_M_deallocate_block() line
124 + 58 bytes
_STL::_String_base
>::~_String_base >() line 135 + 65 bytes
_STL::basic_string,_STL::allocator
>::~basic_string,_STL::allocator >() line
302 + 96 bytes
boost::test_toolbox::detail::wrapstrstream::~wrapstrstream() + 68 bytes
MyTest() line 28
boost::unit_test_framework::function_test_case::do_run() line 135 + 37 bytes
boost::unit_test_framework::detail::unit_test_monitor::function() line 74
boost::detail::catch_signals(boost::execution_monitor & {...}, int 0) line
344
boost::execution_monitor::execute(int 0) line 152 + 13 bytes
boost::unit_test_framework::detail::unit_test_monitor::execute_and_translate
(int 0) line 41
boost::unit_test_framework::test_case::run() line 69 + 151 bytes
boost::unit_test_framework::test_suite::do_run() line 181
boost::unit_test_framework::detail::unit_test_monitor::function() line 74
boost::detail::catch_signals(boost::execution_monitor & {...}, int 0) line
344
boost::execution_monitor::execute(int 0) line 152 + 13 bytes
boost::unit_test_framework::detail::unit_test_monitor::execute_and_translate
(int 0) line 41
boost::unit_test_framework::test_case::run() line 69 + 151 bytes
main(int 1, char * * 0x002f5b48) line 87
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77ea847c()
> 3. Try to use Boost.Test that comes with boost 1.30.0. Does it help?
It helped!
I don't understand why compiling with bjam produced the wrong results, but
as long as it works, I'm happy.
If someone wishes to dig deeper I'll be happy to provide all the details of
my build environment.
Thanks!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Rozental, Gennadiy
Sent: 26 juin, 2003 22:09
To: '[EMAIL PROTECTED] '
Subject: RE: [boost] vc6 + stlport + boost/unit_test.hpp
> Hello,
> I neep help integrating STLport 4.5.3 with Microsoft Visual C++6.0 SP5
> and the unit test framework from boost(1.29).
> Everything seems fine when I use vc6 with STLport alone but when I try
> to use it in a test environment I get memory corruption. (It compiles
> and links fine).
1. Could you provide a small example so I could replicate the issue here?
2. Did you try to debug it? Where does it fail?
3. Try to use Boost.Test that comes with boost 1.30.0. Does it help?
I was using sucessfully the Unit test Frameowrk in above confguration. I
need more hints to tackle the issue.
Gennadiy.
___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] filtered/decorated streambufs
I also have an updated ('C++ 1998 STL standardized') version of James Kanze's
of filtering streambuf and filtering streams derived from his files at
www.gabi-soft.fr re-built for MSVC 7.1, (Could be posted on request).
and his illuminating articles in C++ Report 1998 (attached).
There are also several examples of Inserting (decorating - not sure this term is
an improvement) and Extracting on input, and some tests (though not Boost style
test suite, a possible TODO item).
His examples include:
Output:
prefixing each non-blank line by a timestamp.
translating each char with a mapping table.
expanding tabs.
Input:
translating each char with a mapping table.
removing 'comments' after # (say) upto the end of line.
rebuilding continuation lines.
Sadly I didn't spot much documentation or examples of Daryle's quite complex
code, which looks to have quite a lot in common with this code that Larry Evans
is threatening to use.
(More sadly, I was much impeded in trying to understand much of Larry's work in
progress on account of the bizarre layout - this would be an serious impediment
to acceptance by Boosters - see the Boost coding guidelines?)
However, both the filtering stream process, and the application to several
layout desiderata that various people have been chipping away at, seem important
items for Boost library. I'd like to encourage both of these.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Daryle Walker
| Sent: Friday, June 27, 2003 6:40 AM
| To: Boost
| Subject: [boost] Someone wanted filtered/decorated streambufs?
|
|
| For the past few weeks, some posters were talking about streambufs that
| can decorate another stream buffer. I wrote up a general class at
| .
|
| The non-virtual filter functions act as a pass-through (i.e. no change)
| filter/monitor at the moment. We would need to figure out the points
| of customizing before adding the virtual filter functions. For
| instance, "doing_imbue" could have a virtual "do_postonly_imbue" that
| only lets the filter do its own adjusting for locale changes after the
| main stream buffer has already done its adjustments. The "doing_sync"
| method could have a virtual "do_preonly_sync" that is called before the
| main stream buffer's syncing, and the virtual method could return a
| Boolean determining if the main buffer should continue. The other
| "doings" could have pre- and post-actions (no "only," of course).
|
| One difficulty would be if the reading and/or writing overrides need
| to store extra characters. Maybe I could add reserve space in the
| filtering stream buffer
|
| Daryle
|
| ___
| Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
Title: Filtering Streambufs
Filtering Streambufs
Variations on a Theme by Schwarz
by James Kanze
Introduction
There has been much discussion in the last couple of years
concerning the STL, and the abstraction of a sequence (materialized
by its concept of iterator) that it so elegantly uses. Strangely
enough, however, another major abstraction in the proposed standard
library doesn't seem to get much attention, that of an abstract data
sink and/or source, as materialized in Jerry Schwarz's
streambuf. This may be partially due to the fact that
most people only use the formatting interface, and somehow only
associate the streambuf with IO. In fact, IO is only a
special case of the more general abstraction of a data sink or
source.
In this article, I will concentrate on one particular variation of
this abstraction, which I call a filtering streambuf. In a
filtering streambuf, the streambuf in question is not
the ultimate sink or source, but simply processes the data and
passes it on. In this way, it acts somewhat like a pipe in UNIX,
but within the process. Anyone who has worked with UNIX is familiar
with just how powerful this piping idiom can be.
Many different filtering streambuf's are possible: on input, we can
filter out comments, or merge continuation lines; on output, we can
expand tabs, or insert timestamps. Ideally, we would like to write
as little code as possible, which suggests some sort of generic
class to handle the boiler plating, with only the actual filtering
to be written for each use.
One small note: the iostream library has evolved some in the
standards committee, and different compilers will have different
versions. For convenience, I've based the following code on the
original release which accompanied CFront. This is partially
because this corresponds to the version I use most ofte
[boost] Re: boost::regex opeartor+= bug report
> I believe that consistent use of std::advance would solve the problem. > Or would this change be so costly that I ought to use vector or deque? > Unfortunately, doing so would cause me other problems such as iterator > invalidation. :-/ Should be fixed in cvs now. Thanks for the report, John Maddock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regex documentation bug
> http://www.boost.org/libs/regex/template_class_ref.htm#partial_matches > > There are two examples given. Though the examples are different, in > both cases, the "example" links to a complete implementation of the > first example. This likely was a cut-and-paste error. Thanks, fixed in cvs, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: API Review request: XML API for C++, second round
Hamish Mackenzie <[EMAIL PROTECTED]> writes: > On Fri, 2003-06-27 at 09:09, Anthony Williams wrote: > > What's wrong with just having boost::shared_ptr and > > boost::shared_ptr, boost::shared_ptr ? > > > > You could have each node store a boost::weak_ptr pointing to its > > parent, which is converted to a boost::shared_ptr when you ask for > > it. That way, a child doesn't keep its parent alive (though parents should > > keep their children alive), but you can still traverse up the tree if you > > like. > > > > You could do the same for documents --- the document holds a shared_ptr to > > the root element, and so keeps the whole tree alive. Each element holds a > > weak_ptr to the document, so you can retrieve the document from it, but it > > doesn't keep it alive. Consequently, if you erase an element from the > > document, but you still have a pointer to it, then the element itself is > > OK, but it will then die when your pointer goes out of scope. Also, if the > > document goes out of scope, then your element is still OK, but is no > > longer associated with a document. > > This sounds like a description of an implementation rather than the > interface. This implementation would not solve the problem "what is a > node when it is not part of document?". It was meant to be a description of semantics, in terms of a sample implementation. A node that is not part of a document is a free-standing subtree that needs adding to a document. If it is an element, then you can treat it as if it is the root node of a document. If it is anything else, then you are more limited in what you can do, but then what does it mean to perform an XPath query on a PI? If the underlying API requires that the document is kept alive to keep the nodes alive, then the wrapper class must handle this, whilst simulating the above semantic description. > Your implementation would be much easier to wrap than libxml2. You > could implement the same interface simply with... > > typedef Document document; > typedef Node * node_ptr; > typedef Node & node_ref; > > The problem when wrapping libxml2 is that the node is stored by libxml2 > in its own xmlNode structure. You can't add methods to it like you > could if you wrote your own Node. > > You could copy the libxml2 tree into your own structure but then you are > on your own when it comes to higher level things like xpath and xslt. I imagined that you would write forwarding functions for the underlying API, so when you are given an Xpath query, you pass it on to the underlying API and then wrap the result. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: tokenizer comments
> From: Edward Diener [mailto:[EMAIL PROTECTED] > > More than a month ago I posted a correction to the tokenizer > documentation > to which no one replied: Sorry about that. > "The Tokenizer documentation for char_separator tokenizer > function states > that the default argument for the second template type is > "char_traits". This is incorrect. The source code in > token_functions.hpp clearly shows that the default argument is > "std::basic_string::traits_type". Could this please be > corrected ?" I don't think that the documentation should change (not counting the change from char to Char), but rather the implementation. std::basic_string::traits_type will always be std::char_traits. If there are no objections to this (there might have been some compiler issue that justified the code, although there's no such indication in the CVS history), I'll change token_functions.hpp accordingly. Thanks for the report! Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes wrote: [...] > The point of the Boost license is to grant various permissions to everyday > users. Special uses such as ISO standardization, or maybe some corporation > that wants a different license, can be dealt with on a case-by-case basis. > That's a nice aspect of the developer retaining copyright. The developer > can cut a special deal if he or she wishes (but of course is under no > obligation to do so). Hmm. I just can't believe that ISO paid something to "BS/K&R/PJP". regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Howard Hinnant wrote: [...] > >> Will the copyright need to appear in the standard itself? > > > > Uhmm, why would you care? > > My job is to implement the std::lib for Metrowerks. Why would I /not/ > care? Because it has no bearing whatsoever on you job. regards, alexander. -- http://opengroup.org/onlinepubs/007904975/frontmatter/participants.html ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Fernando Cacciola wrote: [...] > Motivated by A. Terekhov concerns, I think the license should, if at all > possible, expressely PROHIBIT anyone, including the copyright holder, > from patenting the covered Software and any implied intellectual production. That would make no sense. My concern is this: http://boost.sourceforge.net/misc/license-background.html "This license grants all rights under the owner's copyrights (as well as an implied patent license), " that's one possible (and maybe even reasonable interpretation) but "implied" is Not Good. Well, patents aside for a moment, I personally find this whole issue rather entertaining... if you grant "all rights" then why not simply release it into the public domain? http://lists.boost.org/MailArchives/boost/msg36819.php ([boost] Re: boost vs. The Lawyers (non-technical)) http://lists.boost.org/MailArchives/boost/msg46093.php ([boost] Re: Legal issues and licensing -- again) regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Borland-tools.jam
Dave, Is there any reason for including the option in the Borland toolset: this is set to on by default in features jam, and then selectively turned off for , this means that if I inherit a toolset from borland-tools.jam (I want multiple toolsets to test different Borland versions) then it gets turned on again in the inherited toolset and nothing compiles anymore. BTW this option should *not* be turned on by default - the effect of -WU is to make the linker look for a Unicode entrypoint: int wmain(int argc, wchar_t** argv); and since no boost code uses such an entry point this is obviously a mistake. Also since only borland-tools.jam provides this option, I think we can just remove all reference to it (or at the very least rename it to something more suitable and turn it off by default in features.jam). Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML API for C++, second round
On Fri, 2003-06-27 at 09:09, Anthony Williams wrote: > Stefan Seefeld <[EMAIL PROTECTED]> writes: > > > Hamish Mackenzie wrote: > > > > > dom::document doc; > > > dom::document_ref doc2( doc.root().document() ); > > > assert( &doc2 == &doc ); > > > and... > > > assert( doc2 == doc ); > > > Can be implemented but ideally it would compare all the nodes in the > > > document. > > > > well, that's different. Do you want to know whether both documents are > > equal, or whether they are identical, i.e. whether both references point to > > the same document ? > > > > Hmm, just to check whether we are still talking about the same thing here: > > do we agree that there can't be a 'node' type, i.e. just a > > 'node_ref'/'node_ptr' ? > > You mean: have "node" as an abstract class, so you can't have any objects of > that type, but you can have pointers and references? Sounds good. > > What's wrong with just having boost::shared_ptr and > boost::shared_ptr, boost::shared_ptr ? > > You could have each node store a boost::weak_ptr pointing to its > parent, which is converted to a boost::shared_ptr when you ask for > it. That way, a child doesn't keep its parent alive (though parents should > keep their children alive), but you can still traverse up the tree if you > like. > > You could do the same for documents --- the document holds a shared_ptr to the > root element, and so keeps the whole tree alive. Each element holds a weak_ptr > to the document, so you can retrieve the document from it, but it doesn't keep > it alive. Consequently, if you erase an element from the document, but you > still have a pointer to it, then the element itself is OK, but it will then > die when your pointer goes out of scope. Also, if the document goes out of > scope, then your element is still OK, but is no longer associated with a > document. This sounds like a description of an implementation rather than the interface. This implementation would not solve the problem "what is a node when it is not part of document?". Your implementation would be much easier to wrap than libxml2. You could implement the same interface simply with... typedef Document document; typedef Node * node_ptr; typedef Node & node_ref; The problem when wrapping libxml2 is that the node is stored by libxml2 in its own xmlNode structure. You can't add methods to it like you could if you wrote your own Node. You could copy the libxml2 tree into your own structure but then you are on your own when it comes to higher level things like xpath and xslt. -- Hamish Mackenzie <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: API Review request: XML API for C++, second round
Stefan Seefeld <[EMAIL PROTECTED]> writes: > Hamish Mackenzie wrote: > > > dom::document doc; > > dom::document_ref doc2( doc.root().document() ); > > assert( &doc2 == &doc ); > > and... > > assert( doc2 == doc ); > > Can be implemented but ideally it would compare all the nodes in the > > document. > > well, that's different. Do you want to know whether both documents are > equal, or whether they are identical, i.e. whether both references point to > the same document ? > > Hmm, just to check whether we are still talking about the same thing here: > do we agree that there can't be a 'node' type, i.e. just a > 'node_ref'/'node_ptr' ? You mean: have "node" as an abstract class, so you can't have any objects of that type, but you can have pointers and references? Sounds good. What's wrong with just having boost::shared_ptr and boost::shared_ptr, boost::shared_ptr ? You could have each node store a boost::weak_ptr pointing to its parent, which is converted to a boost::shared_ptr when you ask for it. That way, a child doesn't keep its parent alive (though parents should keep their children alive), but you can still traverse up the tree if you like. You could do the same for documents --- the document holds a shared_ptr to the root element, and so keeps the whole tree alive. Each element holds a weak_ptr to the document, so you can retrieve the document from it, but it doesn't keep it alive. Consequently, if you erase an element from the document, but you still have a pointer to it, then the element itself is OK, but it will then die when your pointer goes out of scope. Also, if the document goes out of scope, then your element is still OK, but is no longer associated with a document. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
