[boost] Re: filtered/decorated streambufs
On Friday, June 27, 2003, at 1:27 PM, 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).
and his illuminating articles in C++ Report 1998 (attached).
I've read them before. Couldn't you just provide an URL?
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).
I think the decorating term comes from some famous programming book
(nicknamed Gang of Four or GOF, don't know real title).
[SNIP list of James Kanze's examples]
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?)
[TRUNCATE]
Please note that the code I gave is UNFINISHED. That is why there is
no documentation or examples. The crux of this library, the virtual
filtering functions, haven't been written yet! I posted the code
because I was looking for suggestions on what the virtual filtering
functions should be.
1. Most of the similar code I've seen has been specific input- or
output-filtering examples (like Larry's), or general input-filtering or
output-filtering classes (like James Kanze's code you gave). The
classes I wrote are a general filter framework; for input, output,
miscellaneous, or a combination of these.
2. What's the deal with the complexity? Since there are 12 points of
stream buffer overriding (although there are related groups), I have to
put in 12 sets of filtering methods. It can't be considered complex if
there is nothing left to remove without leaving a hole.
3. I could have used just a filtering stream-buffer class, without a
separate filter class hierarchy. However, I want to limit the amount
of customization, so steps I consider important wouldn't be skipped.
Since (almost) all of the stream-buffer functionality is in its virtual
methods, which I have to change, an user can create overrides that
totally skip my changes. So I designed a stream buffer class that
users should not change, and moved the customizable parts to the filter
class hierarchy.
4. The filter class is definitely _not_ final. It is missing the
functionality overrides. The non-virtual functions, starting with
doing_, would call the future overrides to do parts of their
functionalities. The default implementations of the future virtual
functions would make the non-virtual functions act as those non-virtual
functions currently are (i.e. pass-through). These defaults would
allow, for example, an user to add output filtering without worrying
how the input and miscellaneous methods operated.
Daryle
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: tokenizer comments
On Friday, June 27, 2003, at 8:59 AM, Edward Diener wrote: [EMAIL PROTECTED] wrote: From: Edward Diener [mailto:[EMAIL PROTECTED] [SNIP] The Tokenizer documentation for char_separator tokenizer function states that the default argument for the second template type is char_traitschar. This is incorrect. The source code in token_functions.hpp clearly shows that the default argument is std::basic_stringChar::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_stringChar::traits_type will always be std::char_traitsChar. 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. Since std::basic_stringCh::traits_type == std::char_traitsCh is always true, shouldn't both the code and documentation be changed? There is no need to hide the class's identity. Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filtered/decorated streambufs
On Friday, June 27, 2003, at 8:34 AM, Larry Evans wrote: Paul A. Bristow wrote: [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. Was the code machine-generated (e.g. Perl script, etc.)? I was wondering that when I noticed that the statements end (as always) and _begin_ (sometimes) with semicolons (there's only one semicolon between consecutive statements), and empty functions still have one semicolon. What advantages does your style have? I'm still wondering about some of the design decisions, though. It doesn't help that it's hard to figure out the designs due to the unusual writing style. Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost-bugs] [ boost-Bugs-762304 ] signals problems with dll
Bugs item #762304, was opened at 2003-06-28 02:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=107586aid=762304group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: signals problems with dll
Initial Comment:
If I create signal in exe and connect some handlers in dll
and try destroying signal before disconnect handlers or
try disconnect it in exe I have runtime error. But if
disconnect all in dll, all ok.
I think it happened because dll have different memory
manager.
I think basic_connection must be refcounted or have
method like this.
void destroy()
{
delete this;
}
Best regards,
WolfHound
[EMAIL PROTECTED]
PS Sorry for my English.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=107586aid=762304group_id=7586
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Boost-bugs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/boost-bugs
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Mon, 23 Jun 2003 15:24:54 +0200, Daniel Frey wrote: FYI: I send the question with a minimalistic example to csc++, should appear there soon. My personal feeling is that GCC/MSVC are correct, but let's see what happens at csc++... OK, I was wrong. Daveed Vandervoorde provided the reference to the standard which is quite clear IMO. I filed a bug report to GCC Bugzilla (#11357). Maybe some MS-user wants to do the same for the VC++... Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: filtered/decorated streambufs
On 28 Jun 2003 01:38:14 -0700 (PDT) Daryle Walker wrote:
On Friday, June 27, 2003, at 8:34 AM, Larry Evans wrote:
Paul A. Bristow wrote:
[SNIP]
[snip]
Was the code machine-generated (e.g. Perl script, etc.)? I was
wondering that when I noticed that the statements end (as always) and
_begin_ (sometimes) with semicolons (there's only one semicolon between
consecutive statements), and empty functions still have one semicolon.
What advantages does your style have?
Years ago, I noticed one person put all semicolons in the same column.
This lead to semicolons in a far right column's, I suppose to make it
easier to see missing semicolons. Also, years ago, another person
wrote a program to print is program formated with square blocks
indicating the nested, e.g.
if(x==7)
| a := b; |
| if(ac) |
| |
| | a := c; | |
| | b := c; | |
| |
| c := 2; |
I just substituted the ;'s for the left |'s in the blocks closely
approximated what both these people intended:
; a := b
; if(ac)
{ a := c
; b := c
;}
; c := 2
This first person also put the type and identifier of his declarations
in distinct columns:
int a;
very_long_typenameb;
the purpose being, I guess, to easily find the identifier or type. I
thought finding the identifier was most important so I thought why not
put it in a prominent place, at the left hand margin. Hence:
int
a;
very_long_typename
b;
This left the problem of semicolons. In the case of declarations,
this sometimes serves as a placeholder for the definition of a
method; hence, the logical location for it is the place where the
definition would go. Hence:
int
a
;
very_long_typename
b
;
char
a_not_yet_defined_function(void)
;
This also has the distinct advantage of enabling cut-and-paste when
defining the function:
char
class_owning_following_function::
a_not_yet_defined_function(void)
{ ...
;}
Now what about beginning elements in argument list with the character
, ? Well this is just an extension of the ; usage. If you think
about the parse-tree, you see another reason why. Each delimiter,
either , in case of arg list or ; in case of statement list, is
the root to a subtree in the parse tree (similar to a cons in lisp).
Hence, putting these operators first amounts to turning the parse tree
90 degrees counter-clockwise. In addition, this method resembles a
bulleted list, where the bullets are replaced by the delimiters.
And the comments. Why:
int
a_function
( type1 arg1
, type2 arg2
)
//Comments for a_function
{ //function defintion
}
instead of:
//Comments for a_function
int
a_function
( type1 arg1
, type2 arg2
)
{ //function definition
}
I had seen comments before a function repeat the listing of arguments.
This seemed a needless duplication. If instead, the function name and
its arguments were first introduced followed by the comments
describing the function, then there would be no need for a duplicate
listing of function arguments. In addition, since the comments are a
paraphrase of the function definition, it makes more sense that they
should come just before that definition. It seems that this should
also make it easier for a documenter, such as synopsis, to more easily
identify which comments belong where.
I'm still wondering about some of the design decisions, though.
I think there are about 4 design decisions:
1) use unbuffered streambuf
The reason for this is just to avoid the complication of dealing
with buffering. It may lead to more virtual function calls, but
I'd prefer not to do optimization until it's needed.
2) use of {attach,detach}_ostream methods
These methods keep the destination ostream's streambuf to the
head of the pipeline of ostreambuf_decorator_abs. The head is
the last ostreambuf_decorator_abs added to the pipeline. The
tail is the first ostreambuf_decorator_abs added to the
pipeline. The m_streambuf of this first ostreambuf_decorator_abs
points to the original streambuf of the ostream passed as
argument to the CTOR of this first ostreambuf_decorator_abs,
which is actually an ostreambuf_decorator_con.
3) use of ostreambuf_decorator_con to start building the pipeline
The pipeline is the linked list of ostreambuf_decorator_abs's
(The _abs suffix is for abstract. The _con suffix is for
concrete. ) This is needed in order to terminate the recursion
of the {attach,detach}_ostream methods.
I'm not sure why I used ostreambuf_decorator_impl as a superclass
of ostreambuf_decorator_con. I may just move the _impl code to
the _con class body.
4) use of fwd* methods in marg_put and ostreambuf_decorator_abs
I wanted a way to
Re: [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 am interested in functional programming in general, having studied Haskell at university. I know that there is already some support for this programming paradigm available via functional objects, Boost::Lambda and others. Given that FC++ has some problems moving to the STL/Boost world, and the availability of some FC++ facilities already, is it better to see what is not yet provided by STL/Boost and see how they can be added to Boost? I am also interested in expression templates and how these would integrate into the functional C++ environment. As an example, using template partial specialization to simulate pattern matching in Haskell to create a differentiation library. It is also worth noting that having a Math constant library where constants are expressed as struct tags (e.g. one_t) would allow that to integrate with functional, differential and expression template libraries. As a side note. On the naming side, I don't mind names being different from the Haskell versions, as long as I know how they relate. E.g. map can be emulated in C++ using std::transform and foldl as std::accumulate. Just my opinion. Regards, Reece _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes [EMAIL PROTECTED] writes: At 01:26 PM 6/27/2003, Alisdair Meredith wrote: 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. This is starting to get complicated. I wonder if separating the license from the source is really worth it. What's the upside? -- 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
Alexander Terekhov [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED]
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.
I don't understand.
Isn't the license and its copyright notice itself which protects those rights?
If we only seek to retain the copyright notice which each _copy_, as required by the
license, do we _need_ a patent? I think not.
AFAICT, a patent gives you far more rights than those expressed in the copyright
notice, and in particular, gives you right to _control_ the use of the covered subject
by,
for example, requiring a royalty for each use of it. This is far more than what we
really need, isn't it?
Maybe you saw nonsense in disallowing the boost developers ourselves
to issue a pantent on our own software. Well, the intention is to reduce
loopholes: without this provision, I might be forced to prove that I am
the orginal developer (names are far from unique).
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.
I see.
If I understood correctly, this means that the release itself prohibits
_further_ patents to be registered on the software. Is that right?
But as you say this does not apply in the USA, so a express
provision is still necesary.
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?
Nothing is wrong with that per see, it is a matter of goals.
Companies like IBM do businesses with their software, thus it makes sense
for them to seek patent protection, because patents regulates competition.
But competition is the key to evolution, so to the users and computing comunity
at large, patents are a BIG nuisance.
I don't think boost developers really want to protect themselves against comptetition,
we just want to retain credit for what we originally did, but via a simple mechanism.
Retaining _copy_ rights is far more easier than retaining _intellectual_ rights.
Currently, anyone can write from scratch the smart pointer libraries under his own
name.
We cannot protect that without a patent, right, but my guess is that boost developers
don't
really care, otherwise, we wouldn't release our work through boost.
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] thread::current() ?
Hi there, I was wondering if you were planning to implement some static thread thread::current() that returns the current thread id ( thread). That would be really useful. I vote for standardizing boost::thread if so...! Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] thread::current() ?
On Saturday, June 28, 2003, at 02:43 PM, Philippe A. Bouchard wrote:
Hi there,
I was wondering if you were planning to implement some static
thread
thread::current() that returns the current thread id ( thread). That
would
be really useful.
The thread default constructor serves this role:
void foo()
{
thread self; // current thread
...
}
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] regex possible bug
Thanks for the quick fixes on the other bug reports, John.
Here is what might be a new one. The code below indicates that no match
was found, but I was expecting it to indicate that a partial match was
found beginning at 'a'. If I don't push the space on beforehand, I do
get a partial match. Have I overlooked something?
#include boost/regex.hpp
#include iostream
#include vector
int main(void) {
typedef char value_type;
typedef std::vectorvalue_type container_type;
typedef container_type::iterator iterator_type;
boost::regex find_this(ab);
container_type search_this;
search_this.push_back(' ');
search_this.push_back('a');
boost::match_results iterator_type what_matched;
bool match_found(boost::regex_search(search_this.begin(),
search_this.end(), what_matched, find_this,
boost::match_default | boost::match_partial));
if (match_found) {
if (what_matched[0].matched) {
std::cout Full match found. std::endl;
} else {
std::cout Partial match found. std::endl;
};
} else {
std::cout No match found. std::endl;
};
};
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Interest in multiindex_set? (again)
Hi all,
A few weeks ago I prompted for interest in a multiply
indexed set container, whth alas little response from the
community. In the meanwhile, I continued working in
multiindex_set and now the library is 90% completed,
save docs. It is available at
http://groups.yahoo.com/group/boost/files/multiindex.zip
and have been checked to compile with MSVC++ 6.5 and
gcc 3.2 under cygwin.
IMHO multiindex_set is an useful resource and can help
programmers when they are in need for data structures more
complex than simple std::sets and std::multisets. In these
cases multiindex_set is a more robust solution than the usual
resort to ad hoc constructs based on containers of iterators
and stuff like that.
I am aware the complete lack of docs is a big barrier to the
evaluation of the library, so the following serves as a basic
introduction to multiindex_set that hopefully can motivate the
reader into trying the library. An extensive example of use is
provided in the URL above showing the whole set of capabilities
offered by the container.
* Usage: As std::set takes a comparison predicate to index
the elements contained, multiindex_set is instantiated with a
boost::tuple of such predicates, which we call indices.
For instance, say we have class employee with sorting
predicates based on some id (upon which employe::operator
is written), name and age. One can construct a set providing
indices to all three orderings like this:
typedef
multiindex_set
employee,
tuple
std::lessemployee,
less_byemployee,std::string,employee::name,
less_byemployee,int,employee::age
employee_set;
less_by is a facility intended to help construct a sorting predicate
based on a single member of the class. In general, one can use
whatever predicate with the right signature.
Unless explictly stated the fist index (std::lessemployee in our
example) is taken to be *unique*, while all others allow for duplicates.
This means one can insert employees with the same age but not
the same id. multiindex_set allows for specification of zero, one or
more unique indices, much in the same way as a relational table does.
So, the following constructs a multiindex_set with unique indices
for id and social security number:
typedef
multiindex_set
employee,
tuple
std::lessemployee,
less_byemployee,std::string,employee::name,
less_byemployee,int,employee::age,
less_byemployee,int,employee::ss_number ,
unique_indices0,3 // id and ss number
employee_set;
Once constructed, multiindex_set holds as many internal orderings
as indices are specified. Each index has the same interface as a
std::set container. By itself, multiindex_set inherits the functionality
of the first (primary) index.
employee_set es;
// retrieves a view based on the first index (name)
employee_set::index_type1::type i1=es.get1();
// ordered by id
std::coutby idstd::endl;
std::copy(
es.begin(),
es.end(),
std::ostream_iteratoremployee(std::cout));
// ordered by name
std::coutby namestd::endl;
std::copy(
i1.begin(),
i1.end(),
std::ostream_iteratoremployee(std::cout));
* Special lookup operations: When elements are expensive to
construct, it is a nuissance to have to build a whole object
just to search for a particular member of it. multiindex_set duplicates
the std::set lookup facilities to help you perform searchs without
supplying entire objects:
i1.find(John); // find John using the name index
For this to work the predicates must be extended to accept the
appropriate subobjects (less_by automatically does this).
One can even pass in compatible sorting predicates, where
compatible means inducing a weaker compatible ordering, as
the following example shows:
i1.lower_bound('J',employee::comp_initial()
// first employee whose name begins with J, using the
// name index and the special employee::comp_initial predicate.
* Update: given an element pointed to by a multiindex_set iterator,
one can change its contents via the update member function:
employee_iterator it=es.find(0); // employee with id==0
employee e=*it;
e.id=100; // change her ID
es.update(it,es); // and update the record.
updating is done efficiently (constant time) if the ordering
of the updated element remains the same with respect to all
indices, and logarithmically for other cases. Interestingly enough,
iterators and references to an element remain valid after updating.
update provides strong exception-safety, in the sense of
Stroustrup's TC++PL sp. ed.
* Implementation: multiindex_set has been written from scatch
with Boost in mind, so it uses a fair number of other Boost
libraries, most importantly the MPL, which helps build the internal
hierarchy of indices in compile-time. Run-time wise, multiindex_set
is optimal in terms of space and complexity, yielding results
equivalent to STL sets (wich BTW can be simulated as particular
instantiations of multiindex_set).
[boost] DLL hell
Hello everybody, I just got the boost_1.30.0 version. Some libraries (like thread) require use of a DLL. However I would like to avoid the DLL hell. >From looking at the output of the thread build it looks like a statically linkable library is not available. Is there some reason why I would not be able to create a static library for the thread library in VC7.1? Has anybody done this already? I feel this is very important because maintenance of multiple dll versionson client machines can be a really nasty problem. Regards, Martin.
[boost] Re: thread::current() ?
Howard Hinnant wrote:
On Saturday, June 28, 2003, at 02:43 PM, Philippe A. Bouchard wrote:
Hi there,
I was wondering if you were planning to implement some static
thread
thread::current() that returns the current thread id ( thread). That
would
be really useful.
The thread default constructor serves this role:
void foo()
{
thread self; // current thread
...
}
Thanks... but is it possible to obtain the initial address of the functor
object portably, given the current thread object?
Philippe
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: thread::current() ?
On Saturday, June 28, 2003, at 06:32 PM, Philippe A. Bouchard wrote: Thanks... but is it possible to obtain the initial address of the functor object portably, given the current thread object? To the best of my knowledge, no. As currently designed the thread constructor is not required to record (remember) the starting function. Such a requirement could impose constraints on the implementation that would prohibit desirable optimizations, so we should not add this without sufficient motivation. Specifically, with the current interface it is possible to implement the thread(f) constructor such that it does not need to access the heap if the type of f is a simple function pointer. However, if the thread is required to store f, then I suspect such an optimization would no longer be practical. Just shooting from the hip, one might be able to build a hash_mapthread, functionvoid() (cough excuse me, that's unordered_mapthread, fucntionvoid() ) to achieve such functionality if desired. However, I haven't actually prototyped that idea, so I can't swear it would work at this point. -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
