are putting into the submission, Daryle.
I'm encouraged that you'll be able to drive the library addition the last few steps
necessary to ensure it is up to the high Boost standards.
Ed Brey
Review Manager for More-I/O Library enhancements
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Arkadiy Vertleyb wrote:
> If I understand correctly, with your approach:
>
> (a, b, null) == (a, b, c1), and
> (a, b, null) == (a, b, c2), but
> (a, b, c1) != (a, b, c2)
>
> If this is correct, I am afraid that whether or not such a predicate
> works correctly may depend on a particular implement
Arkadiy wrote:
> Right now we are using a sorted vector instead of a set, to implement
> our relational tables, because set doesn't allow us to search on a
> prefix of a key. Like if a table is indexed on a, b, c, we are not
> able to use equal_range on a, b with the set.
I was able to successful
Alexander Terekhov wrote:
>>> * Suppose I create a product containing executables that make use of
>>> compiled boost libraries (only - no uncompiled boost source). I
>>> consider the CD and its content to be the "work" and I copyright it
>>> as such. It is a work derived from the Software (Boost
Peter Dimov wrote:
>
> I'd like also to point out that it seems to me that the old "in all
> copies" form is better than the new one; the legal system is
> sufficiently flexible
> to reliably recognize a "copy" (i.e. a password protected RAR archive
> of an mp3 encoded song). The new wording seem
Paul A. Bristow wrote:
>>
>> For example, VC 7.1 discards d1 if it is not referenced, so there is
>> no issue with paying for what you don't use when using that method on
>> that compiler.
>
> This is good news. What optimisation did you chose?
/O2
>> It would be useful to know what compilers
Paul A Bristow wrote:
> A Mini-recapitulation of the _long_ saga so far:
>
> 7 There are dozens of constants that some users rate 'essential'.
> Splitting into several #include files still risks violating the
> "don't pay for what you don't use" principle.
> 10 There is evidence that some compil
Daryle Walker wrote:
>>> I fixed up the I/O library I had reviewed a few months ago. It was
>>> some little things last week, but some big documentation and testing
>>> this week. It's in the sandbox if you want to try it out.
>>
>> Looking at today's version in the sandbox, I still see the foll
Paul A. Bristow wrote:
>>
>> cout <<
>> "My first line" "\n"
>> "My second line";
>
> Are you sure that this is more efficient?
>
> cout <<
>"My first line" << endl <<
>"My second line";
>
> has proven LESS efficient and I suspect the flush caused by
> encountering \n will have the
Thomas Witt wrote:
>
> 1. std::endl was and is still abused heavily. I think there is a
> reason for this. Most c++ programmers are taught to stay clear of
> ugly low-level c things and to use the new shiny c++ facilities
> instead. And that's what they do, replace '\n' with std::endl.
> Personall
e are lower-level issues remaining, too, but these are more appropriate to address
after the high-level issues are resolved.
Ed Brey
Review Manager for I/O Library update
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gennaro Prota wrote:
>
>> Mis-use of endl doesn't seem to be adequet justification for a new
>> end-of-line specifier. However, a difference in behavior between
>> '\n' and endl does.
>
> Indeed. And there are obvious differences:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/17737
I
Daryle Walker wrote:
>> Stream-buffer-wrapping:
>>
>> - Why are these facilities provided? What are their uses? What do
>> they do better than the Standard Library's current classes?
>
> I don't think the Standard Library has classes like these. The
> standard streams (string, file, etc.) prob
I'd like to thank those who took time to review the update to the Boost I/O Library
during the review period, which ended several days ago. The reviewers raised
important questions about the usefulness of the new portions of the library.
As review manager, I am pending my determination regardin
First, a reminder that today is the last day for sumbitting a review for the update to
the I/O library.
This is my review of the I/O library, which is separate from my role as review manager.
I vote that the library update be accepted into boost. I examined the documentation
and code. The new
Keith Burton wrote:
>
> In lieu of a zip file , I would vote for inclusion on the basis of
> previous use of the io state savers
The subject of this review is the delta between the previous accepted I/O library and
Daryle's updated version. The state savers are part of the existing and are not
Paul A. Bristow wrote:
> For those of us who find CVS difficult, a zip of the whole
> modest-sized package would be more friendly.
Daryle has posted a zip file containing the submission at this URL:
http://groups.yahoo.com/group/boost/files/more_io.zip
__
The formal review for the updated Boost I/O Library begins today and runs through
March 7.
The I/O library contains various components for use with the standard I/O library.
The components are as follows:
State-saving classes for various IOStream attributes.
Class templates to ease making s
Rozental, Gennadiy wrote:
>> This is an excellent point. One doesn't go looking for a class
>> named "smart_ptr" or a library named "Boost.SmartPointer" when
>> looking to manage the lifetime of some arbitrary resource. When
>> one uses pointers, it makes sense.
>
> I would be searching namely f
Joel de Guzman wrote:
>
> I'll also be needing variant a lot from inside template code. I
> dislike the template keyword that gets in the way. IMO, the way to go
> is the
> C++ cast style syntax: extract(v). There should only be one way
> to do this. Not two. And FWIW, there's a precedent. Althou
Eric Friedman wrote:
>
> I lifted the copyright notice from other Boost libraries (see MPL and
> Boost.Threads). I am happy to change the notice if necessary, but
> should these other libraries follow suit?
Yes, they should, and there was another thread out there at one time discussing the
detai
David Abrahams wrote:
> "Ed Brey" <[EMAIL PROTECTED]> writes:
>
>> Unfortunately, that data point is of limited use, since Python has a
>> lot of names leaving something to be desired (generally those
>> borrowed from C and Unix). When I was a Python newb
David Abrahams wrote:
> "Ed Brey" <[EMAIL PROTECTED]> writes:
>
>> Eric Friedman wrote:
>>>
>>>> The area would be helped by renaming extract to access.
>>> I tend to agree the name is confusing. So shall we call it
>>> boost:
Eric Friedman wrote:
>
>> The area would be helped by renaming extract to access.
>
> I tend to agree the name is confusing. So shall we call it
> boost::access<>? Input?
Dave A.'s comment that access is confusing because it is a noun and a verb is well
taken. Of course, the same can be said f
I vote that variant be accepted into boost. I read all the documentation, and tried
out the code in a simple test under VC7. I am very pleased with this library.
Following are a comments I have that can help make it even better:
*Design:*
Please consider incorporating a "blank" type. This
I reviewed the version of optional available in the boost files area as of today. I
vote for its acceptance into boost. I read the documenation and source for optional
(but not the alignment utility). I am quite happy with its interface and
(fortunately, I guess) have very little of substance
26 matches
Mail list logo
