Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Hi Beman,
I've some comments:
1. The name 'root_directory' is confusing for me. 'directory' implies
you can stick anywhere dir there, whilie only / is allowed.
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Hi Beman,
In a couple of hours I changed all our codes that depend on
boost::filesystem. Although I did not perform a through review, I had
no problem using the library. I found
Dear Serialization-Boosters,
In the past weeks I have been to busy at work to contribute much to the
serialization debate, but I managed to find some time now. It seems to
me that the discussion is drifting too far into semantic debates and I
would like to refocus by proposing to split the
Hi Boosters,
given the Standard's wording in 3.9/1:
... There are two kinds of types: fundamental types and compound types.
...
isn't the current implementation of is_compound overly complex? Can't we
just change it to basically match:
is_compound = !is_fundamental
given a working version
From: Dave Gomboc [EMAIL PROTECTED]
I would guess (handwaving alert ;-) that the traditional mechanism for
indicating an optional value uses a pointer because that was more
convenient than passing a separate flag alongside the value.
A pointer can be used in situations where value+flag
On Monday 16 December 2002 01:39 am, Greg Dehaas wrote:
//Macros for binding functions + methods
#define BINDMETHOD5(object,function)
boost::bind(function,object,_1,_2,_3,_4,_5)
#define BINDFUNCTION5(function) boost::bind(function,_1,_2,_3,_4,_5)
#define BINDMETHOD4(object,function)
We've got two cases where it would be very useful to be able to easily
extract the library name from a header file:
* Generating a dependency analysis based on library names rather than than
header names.
* Reporting problems (tabs in files, etc.) with an automatic scanning tool.
We currently
Robert Ramey [EMAIL PROTECTED] writes:
The fundamental problem that Serialization addresses is the
reversable deconstruction of an arbitrary set of C++ objects to a
stream of bytes. That's all it is. We know that it is useful for
certain things, but that doesn't mean its going to be useful
On Monday 16 December 2002 09:17 am, Beman Dawes wrote:
I'd like to propose changing that (particularly for headers) to:
// See http://www.boost.org/library-name for documentation.
I assume you mean http://www.boost.org/libs/library-name;?
and require that it be the first instance of
At 03:05 AM 12/16/2002, Vladimir Prus wrote:
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Hi Beman,
I've some comments:
1. The name 'root_directory' is confusing for me. 'directory' implies
you can stick anywhere dir
At 08:35 AM 12/16/2002, Peter Dimov wrote:
To clarify: the current situation requires the filesystem library to
interpret system-specific error codes. Adopting the POSIX values would
eliminate that need on some important platforms, with no downsides.
Just to be sure that I understand your
At 12:34 PM 12/13/2002, Kevin Lynch wrote:
Iain K.Hanson wrote:
We already have a standard
portable
error
scheme. Why reinvent the wheel? Will we do any better?
We might. The POSIX errno scheme doesn't seem all that strong to me.
Agreed. I've given a fair ammount of though to this over the
Fernando Cacciola said:
William E. Kempf [EMAIL PROTECTED] escribió en el mensaje
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Fernando Cacciola said:
[snip William's comments about the interface with operator T]
I agree with your comments about the interface with operator T.
I show it
At 06:59 AM 12/13/2002, John Maddock wrote:
No, and the toolset hasn't changed recently either. __BORLANDC__ is
reporting 0x0560 as the version, and bcc32 at the command line reports
version 5.6. The CD-ROM it came on says C++ Builder 6 Personal. I
checked
the web site, and don't see any
From: Beman Dawes [EMAIL PROTECTED]
At 08:35 AM 12/16/2002, Peter Dimov wrote:
To clarify: the current situation requires the filesystem library to
interpret system-specific error codes. Adopting the POSIX values would
eliminate that need on some important platforms, with no downsides.
At 11:58 AM 12/16/2002, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 03:05 AM 12/16/2002, Vladimir Prus wrote:
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been
committed to the CVS main trunk.
Hi Beman,
I've some comments:
At 12:12 PM 12/16/2002, Glen Knowles wrote:
From: Beman Dawes [mailto:[EMAIL PROTECTED]]
While doing so one missing function
came to my mind (or did I just overlook it). It came to my mind that
some time in the future I might want to create a relative path, given
a
complete path and a
I think that we also need to consider the problem of translating a
filesystem_error to a localized error message.
In particular, consider this example of a what() string:
File system error: move_file(): nonexistent, something_else: The system
cannot find the file specified.
generated by
Gennadiy Rozental wrote:
What's the easiest way of converting an MPL sequence into a
tuple type? I seem to recall Dave Abrahams needed this
functionality as well. Do I need to construct a bare cons
list?
Use inherit_linearly like in it's example.
Which example is that? Is
From: Beman Dawes [EMAIL PROTECTED]
At 11:15 AM 12/16/2002, Douglas Gregor wrote:
On Monday 16 December 2002 09:17 am, Beman Dawes wrote:
I'd like to propose changing that (particularly for headers) to:
// See http://www.boost.org/library-name for documentation.
I assume you mean
On Monday, December 16, 2002, at 06:41 PM, Beman Dawes wrote:
At 12:12 PM 12/16/2002, Glen Knowles wrote:
I think what he might be asking for is something like:
make /my/full/path relative to /my/base/dir produces ../../full/path
Ah... Thanks...
The practical problem is determining if two
Which example is that? Is inherit_linearly documented somewhere?
-Dave
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/
inherit_linearly.cpp?rev=1.1content-type=text/vnd.viewcvs-markup
___
At 01:10 PM 12/16/2002, Peter Dimov wrote:
From: Beman Dawes [EMAIL PROTECTED]
At 11:15 AM 12/16/2002, Douglas Gregor wrote:
Sounds good. I think we should try to do the conversion
automatically,
at
least for all files in subdirectories (e.g., the file
boost/xxx/yyy.hpp
would be assumed
Over the weekend I realized just what strange and wonderful things
tuples are. This message is as much to get my thoughts recorded as it
is a request for discussion about the various classes and bits of
code presented within. Some of this stuff may be useful for Boost and
some may not. I'd like
Over the weekend I had a bit of free time so I wrote up a
spanning_iterator based on the iterator_adaptors framework. To throw
in a bit more complication, I wanted something generic enough that I
could span different kinds of container. There should be a way to
span a std::vector and a
Rozental, Gennadiy wrote:
Over the weekend I had a bit of free time so I wrote up a
spanning_iterator based on the iterator_adaptors framework. To throw
in a bit more complication, I wanted something generic enough that I
could span different kinds of container. There should be a way to
In-Reply-To: [EMAIL PROTECTED]
On Mon, 16 Dec 2002 10:52:45 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
Thus to summarize, I propose to split the serialization archive into a
serialization engine, doing the serialization of the basic types, and
an archive class which takes the engine as
In-Reply-To: [EMAIL PROTECTED]
On Sat, 14 Dec 2002 10:18:32 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
The fundamental problem that Serialization addresses is the reversable
deconstruction of an arbitrary set of C++ objects to a stream of bytes.
I agree that will be the main reason to add
William Kempf wrote:
Some people, mostly _me_, argued that this is not a good idea
because code would change meaning if optional is replaced
by a pointer.
But it's going to change in any event, because optional _isn't_ a
pointer.
But in generic code you must follow the semantics of the
Augustus Saunders [EMAIL PROTECTED] writes:
William Kempf wrote:
But in generic code you must follow the semantics of the concept,
and optional isn't useable when a SmartPointer concept is
required. Define the concept well enough, and optional becomes
useful in generic code.
I'm with Bill.
Paul Mensonides [EMAIL PROTECTED] writes:
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
I understand what you're saying, but I think inline if doesn't
reflect what it's doing and IIF is still not memnonic.
It ultimately from (don't laugh) VB's version of the ternary
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
I understand what you're saying, but I think inline if doesn't
reflect what it's doing and IIF is still not memnonic.
It ultimately from (don't laugh) VB's version of the ternary
operator--called iif.
Ha har hee hee
Terje Slettebø [EMAIL PROTECTED] writes:
Well, he asked for a boost::tuple, and this gave a boost::tuple, with the
exact same type. The reason I provided it was that he seemed to not be
satisfied with a type that behaves the same way as boost::tuple, but don't
have the same type. This could
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
We've got two cases where it would be very useful to be able to easily
extract the library name from a header file:
* Generating a dependency analysis based on library names rather than than
header
Hi boosters,
I installed version 7.0 of the intel compiler for the nightly linux
regression. I still have version 6.0 installed as I will be running the
regression on that compiler too. But it seems that for some reason that I
haven't been able to track down, Boost.Build always picks version
From: Paul Mensonides [EMAIL PROTECTED]
From: David Abrahams [EMAIL PROTECTED]
I understand what you're saying, but I think inline if doesn't
reflect what it's doing and IIF is still not memnonic.
It ultimately from (don't laugh) VB's version of the ternary
operator--called iif.
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Another comment.
I notice that the
symbol is not allowed in paths, (as you says previously). But
'
is allowed. Should it?
- Volodya
- Original Message -
From: Terje Slettebø [EMAIL PROTECTED]
I've been converted. I swear! When I was young, I had to walk to
school
in three feet of snow uphill both ways--and, worse yet, I had to program
in
Visual Basic! It doesn't get any more wordy than this:
Public
38 matches
Mail list logo
