"Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>Inline.
>
>> already suggested that it would be worthwhile for FILE*s and file
>descriptors.
>
>I am not in position to judge their reasons --- I never had this need. Maybe
>I avoided their specific problems somehow. Or these problems are not
>frequent
On Saturday, July 19, 2003, at 7:59 AM, Bill Seymour wrote:
I've been thinking about the related issues of whether decimal should
be a template and whether the scale should be immutable.
First, I'm adamant that the user should be able to write
dollars = foo;
without magically losing pennies
On Saturday, July 19, 2003, at 3:30 AM, Gennaro Prota wrote:
--- Daryle Walker <[EMAIL PROTECTED]> wrote:
Actually, I don't think the Review Manager ever gave a final answer.
Well, he and everyone else can take a quick look. It seems that some
people around here are jumpy for a release, so we
Inline.
"John Madsen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> I fail to see how COM is a relevant analogy. The smart_handle classes
I've
> proposed will work on all major platforms unlike COM. Several people have
COM was available on all major platforms. I still remember
Inline
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >
> > Example for #1. Windows GDI has hundreds (if not thousands) API
functions.
> > New versions of Windows introduce new API functions. It doesn't make any
> > sense to cover it with functional wrapper. MFC tri
On Saturday, Jul 19, 2003, at 20:52 America/Denver, Ross Smith wrote:
On Sunday 20 July 2003 11:46, Gregory Colvin wrote:
On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote:
...
(Of course all of these could easily be unified into a single
policy-based type; unfortunately the Pow
On Sunday 20 July 2003 11:46, Gregory Colvin wrote:
> On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote:
> ...
>
> > (Of course all of these could easily be unified into a single
> > policy-based type; unfortunately the Powers That Be seem to have
> > decided that policies are to
"Gennadiy Rozental" <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I do not want to start this discussion all over again, but in the reasoning
>you presenting I did not find anything new to justify another "smart
>pointer" like component. It's only one simple case of PBSP and I do not see
>any reason not to us
"Eugene Lazutkin" <[EMAIL PROTECTED]> wrote:
>Inline,
>
>"John Madsen" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> I have little experience with X-Windows, so I can't comment on that.
>However,
>> there is absolutely *nothing* in the smart_handle library that is platform
>> spec
Ross Smith <[EMAIL PROTECTED]> wrote:
>>
>> struct win_file_handle {
>> typedef HANDLE handle_type;
>> static bool is_valid(handle_type h)
>> { return h != INVALID_HANDLE_TYPE; }
>> static void release(handle_type h)
>> { if (is_valid(h)) ::CloseHandle(h); }
>> stati
Alan Bellingham <[EMAIL PROTECTED]> writes:
>>did they give you the name of this library?
>
> Presumably this is WTL - the Windows Template Library.
That's the one.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other cha
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Years ago I worked on some general business applications involving liquid
> inventories dealing in tank dimensions, gallons, coefficients of
expansion,
> and all sorts of other non-money related data. Fixed-point arithmetic
Victor A. Wagner Jr.:
>>How do you measure failure? Certainly MFC is primitive, but tens of
>>thousands of developers use it every day. There are better
>>alternatives - Microsoft tells me they have been shipping an
>>"unsupported" library which is "what MFC would have been if we'd
>>started wit
How do you measure failure? Certainly MFC is primitive, but tens of
thousands of developers use it every day. There are better
alternatives - Microsoft tells me they have been shipping an
"unsupported" library which is "what MFC would have been if we'd
started with templates".
did they give you
On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote:
...
(Of course all of these could easily be unified into a single
policy-based type; unfortunately the Powers That Be seem to have
decided that policies are too complicated for us mere mortals to be
trusted with.)
There are no Po
On Sunday 20 July 2003 05:30, Eugene Lazutkin wrote:
> "Ross Smith" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > This is easily handled; just use boost::bind(ReleaseDC, hWindow,
> > _1) for the release function.
>
> In proposed library release functionality is handled by stat
"Bill Seymour" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I've been thinking about the related issues of whether decimal
> should be a template and whether the scale should be immutable.
>
> First, I'm adamant that the user should be able to write
>
> dollars = foo;
>
> withou
Hi,
I do not want to start this discussion all over again, but in the reasoning
you presenting I did not find anything new to justify another "smart
pointer" like component. It's only one simple case of PBSP and I do not see
any reason not to use it.
Gennadiy.
_
Peter Dimov wrote:
> Edward Diener wrote:
>> Once again I will make my request that Boost library developers put
>> out some sort of change log explaining changes made to the library
>> with each new release of Boost which is issued. While I don't expect
>> detailed change enumerations, which no do
"Eugene Lazutkin" <[EMAIL PROTECTED]> writes:
> It looks like reasonable goal. Personally I found that there are two cases:
>
> 1) If there is large existing API => use smart handles. In this case smart
> handle serves two purposes:
> a) provides invisible housekeeping (like destruction of underly
Russell Hind wrote:
Ok, but what happens if locking an already locked mutex where
undefined behaviour? This isn't this the same as the smart_ptr
case? Who knows how the actual implementation is on all the
platforms, or future platforms?
Um, wasn't the question throw vs assert? In either case
Inline.
"Jon Biggar" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> For example, on UNIX, to securely create a file, you need to use the
> O_CREAT and O_EXCL flags to ensure that nobody else created the file
> first and is just waiting for you to write to it so they can read what
"Ross Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> This is easily handled; just use boost::bind(ReleaseDC, hWindow, _1) for
> the release function.
In proposed library release functionality is handled by static function,
which is part of trait:
struct win_file_handle {
Inline,
"John Madsen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> The main uses of the library as I see it is to handle two main cases:
>
> 1) Where a programmer needs to access an API (whether it be from the OS
or a
> 3rd party C API) which uses handle-based resource manageme
John Torjo wrote:
>> On the other hand, perhaps you have a use case that clearly
>> demonstrates
> the
>> need for BOOST_HAS_CURRENT_FUNCTION?
>
> The SMART_ASSERT library clearly needs it.
>
> The idea is: when an assertion fails, in case BOOST_CURRENT_FUNCTION
> holds a meaningful value, I want t
> On the other hand, perhaps you have a use case that clearly demonstrates
the
> need for BOOST_HAS_CURRENT_FUNCTION?
The SMART_ASSERT library clearly needs it.
The idea is: when an assertion fails, in case BOOST_CURRENT_FUNCTION holds a
meaningful value, I want to show it. Otherwise, not.
Test
Please forgive me for only commenting on a few issues; I'd hoped to write a
full review, but the time just isn't there. Sorry if the issues have
already come up.
* I'm unhappy with the use of int for passing values to several functions.
This seems like a recipe for portability problems, when us
At 10:00 PM 7/18/2003, Ilya Buchkin wrote:
>"Bill Seymour" (Friday, 18 July, 2003 12:43) says:
>
>> Ilya seems to be giving me mutually contradictory requirements.
>
>I have use cases/request for TWO distinctly different needs
>that I encountered in financial applications:
> 1. storage (represent
At 09:02 AM 7/17/2003, Bill Seymour wrote:
>Somebody said, "Premature optimization is the root of all evil."
>I can't remember who that was (Knuth? Djikstra?); but somebody
>else on the list will probably tell us.
Knuth. Computing Surveys, Vol 6, No 4, December 1974, page 268.
--Bema
Edward Diener wrote:
> Once again I will make my request that Boost library developers put
> out some sort of change log explaining changes made to the library
> with each new release of Boost which is issued. While I don't expect
> detailed change enumerations, which no doubt can be retrieved thro
At Saturday 2003-07-19 07:24, you wrote:
I've added the entry below to the Boost.Threads bibliography page in CVS.
I also added the Wirth quote to the FAQ: "semaphores ... are not suitable
for higher level languages."
Wirth also designed a language (called Pascal) in which the switch/case
stat
Once again I will make my request that Boost library developers put out some
sort of change log explaining changes made to the library with each new
release of Boost which is issued. While I don't expect detailed change
enumerations, which no doubt can be retrieved through CVS in some way, a
genera
At 03:10 PM 7/18/2003, Peter Dimov wrote:
>index.html should stay so that www.boost.org/libs/utility works. Whether
>the contents should change is another matter.
Yes, exactly.
In response to requests from Nico Josuttis and others, we committed to
every library having an index.htm (or .html) fil
I've added the entry below to the Boost.Threads bibliography page in CVS. I
also added the Wirth quote to the FAQ: "semaphores ... are not suitable for
higher level languages."
IMO, this book is a "must own" for those who care about multithreading or
other concurrent programming design issues.
Daniel Frey wrote:
> On Sat, 19 Jul 2003 02:08:24 +0200, Pavel Vozenilek wrote:
>
>> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED] ...
>> SMART_ASSERT library implements BOOST_HAS_CURRENT_FUNCTION equivalent
>> (it would be ugly to print out the default text).
>
> Log
I've been thinking about the related issues of whether decimal
should be a template and whether the scale should be immutable.
First, I'm adamant that the user should be able to write
dollars = foo;
without magically losing pennies or gaining mils; and I don't
think the user should have to typ
Daniel Frey wrote:
[...]
> PS: Note that there's also a difference between the standard theretical
> world or portable, well defined behaviour and the real world. I am
> explicitly talking about the real world! Boost is not an academic
> excercise. At least I hope so... :o)
In the "real world" yo
--- Daryle Walker <[EMAIL PROTECTED]> wrote:
> Actually, I don't think the Review Manager ever gave a final answer.
> Well, he and everyone else can take a quick look. It seems that some
> people around here are jumpy for a release, so we should get this
> review resolved soon.
Actually I w
Martin Wille <[EMAIL PROTECTED]> writes:
> Misha Bergal wrote:
>
> > We use python 2.2 on win32, so you might encounter some issues due to
> > platform differences. Please let us know how it goes.
>
> I've found one problem: When the tables link to the
> cs-something-links.html file, the URL for th
Martin Wille <[EMAIL PROTECTED]> writes:
>
> - The resulting files seems to be dumped to the location named
>by the --locate-root parameter. I think this should be decoupled.
>I suggest to add another option.
We added --results-dir. The compiler_status produced files should be
in it, the g
Jon Biggar wrote:
Russell Hind wrote:
Ok, but what happens if locking an already locked mutex where
undefined behaviour? This isn't this the same as the smart_ptr case?
Who knows how the actual implementation is on all the platforms, or
future platforms?
Um, wasn't the question throw vs ass
Jan,
I think this has come along very nicely.
Since English may not be your 1st language,
would you like some proof-reading for the
documentation?
Cheers,
Nigel
The implementation can be found at
http://groups.yahoo.com/group/boost/files/circular_buffer.zip
In the latest post-review version, I fully disabled copying for the
array-based stream-buffer class. I also copied the revised version of
the library to
http://groups.yahoo.com/group/boost/files/more_io_revised.zip
so you don't need access to the Sandbox CVS to see the altered files.
This is
On the question of scale as part of the type :
My experience with my own libraries ( i.e. several iterations ) is that
:
a) scale ( and precision ) is required as part of the type
b) a common base for decimals which allows forwarding is
required
c) a common base for decima
44 matches
Mail list logo
