RE: [boost] Re: what happened to allocators in boost?
Title: RE: [boost] Re: what happened to allocators in boost? --- David Abrahams <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > >> Are you sure that >> there's no good general-purpose allocator which they can use? > >Yes, I am sure. I shipped one of my libraries to a guy who >works on various DSP chips. The native memory allocator >on one of the DSP was very slow (some specific issues with >how the DSP addresses the memory, I don't remember the details). > >This guy had to add his own new/delete operator to some of >my internal classes to get about 10 times performance improvement. > >No, I really don't think that there is a hope for general purpose allocators. If it was a system wide performance problem on that DSP wouldn't he have been better off replacing the system allocator completely rather then only for a few classes? Glen
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions From: Peter Dimov [mailto:[EMAIL PROTECTED]] >Glen Knowles wrote: >>> This is also a way we could solve the whole problem of absolute >>> paths. It's clear that "/foo" isn't an absolute native windows path. >> >> This is not at all clear. I have and will contain to argue that >> "/foo" is an absolute windows path, since it does not respect the >> current directory. > >You can argue that only because you are using the ill-defined term >"absolute" to mean "not relative to the current directory _only_, but >possibly relative to some other global per-process state". Whereas you use the term to mean "not relative to the current drive and directory _only_, but possibly relative to some other global per-process state (such as chroot)". Which is a place you can draw the line since admittedly it must be drawn somewhere. You're mostly making an arguement that changing the current drive is sufficiently more common then changing the root or drive assignments to make it different in kind. I still find it to be significantly less common then changing the current directory, but I do see the point. Glen
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions We seem to be at an impasse. To summarize, you think: >> David Abrahams wrote: It's clear that "/foo" isn't an absolute native windows path. Where as I think: >> This is not at all clear. Glen
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions From: David Abrahams [mailto:[EMAIL PROTECTED]] >Yes, an absolute URI identifies a single location in the virtual name >tree. The only way to make this like a current-drive-relative path is >to consider processes which are moved, *during execution*, across a >network of computers. I've never heard of systems which do that that, >but even if they exist I don't think they make an appropriate model on >which to define the notion of "absolute path" in a filesystem library. The point, and this is the only one that truly compells me, is that: http://localhost/blah and /blah are absolute URL paths. c:/blah is an absolute filepath and, to be consistent, /blah should be too. If you look at a drive as equivalent to a URL authority they map very well. You can try to argue that an authority such as "localhost" uniquely identifies a computer, but that really isn't true. It is normal for mailcom, wwwcom, etc to all refer to the same computer, a computer used for webhosting may have thousands of such authorities. >> If you can give me an example of a multirooted system that refers to >> paths that are absolute with respect to the current directory as > ^^ >What does that mean? >And what does it mean for a multirooted system to "refer to a path as >relative?" Do you mean in the official platform specification, or >something else? I was thinking of platform documentation, preferably an actual "is_relative()" system function. I've subsequently found enough examples to drop this as an argument. One thing that I hope we can agree on is that, irrespective of what they're called, we do need functions to distinguish between a:/foo, /foo, foo, and possibly a:foo. Glen
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions
>From: David Abrahams [mailto:[EMAIL PROTECTED]]
>>> portable_path("/foo/bar") <- throws on Windows
>>
>> Not sure why this would throw, what is the purpose of portable_path?
>> "/foo/bar" is perfectly reasonable on Windows.
>
>It's perfectly reasonable but it doesn't have a portable meaning. It
>is a relative path w.r.t. the drive of the current directory.
Almost all paths are relative w.r.t. something, the current users filesystem mapping, the computer, the network. I don't see how leaving out the drive makes it less portable then leaving out the computer name.
>>>This is also a way we could solve the whole problem of absolute paths.
>>>It's clear that "/foo" isn't an absolute native windows path.
>>
>> This is not at all clear. I have and will contain to argue that "/foo" is an
>> absolute windows path, since it does not respect the current
>> directory.
>
>If you define anything that is not relative to the current directory
>as absolute, maybe you can say that. It seems perverse to say that a
>path which is _relative_ to something other than the machine in use
>is absolute, though.
>
>> Also very important to me, this goes well with the URI definitions
>> of absolute and relative
>
>I'm pretty sure this is an illusion! URIs don't have a notion of
>"current drive" do they?
URIs are a multirooted system that have the semantics I'm advocating for file paths. To make an example, if you are looking at "http://localhost/somedir/index.html" it might have an absolute (as defined by the RFCs) href of "/foo/bar" that takes you to "http://localhost/foo/bar" and another relative (again, as defined by the RFCs) href of "foo/bar" that takes you to "http://localhost/somedir/foo/bar". This is because paths, relative or absolute, are with respect to the authority (localhost in this case).
If you can give me an example of a multirooted system that refers to paths that are absolute with respect to the current directory as relative I'd be interested, my multirooted experience is limited to CP/M, DOS, AmigaOS, OS/2, Windows, and URLs. I don't have any big system experience with them.
>> and it would be nice if the path class could support full URIs.
>
>Are we talking about native or "portable" representation now?
>There's no reason they couldn't support full URIs in their portable
>representation. It's just a question of how that gets mapped onto
>the native filesystem.
What I'm thinking of may not be in the scope of the filesystem library, I'd like a path class that could directly manipulate URLs; authoritys, fragments, options and all. Direct use of "file:/.." URLs would be good too.
Glen
RE: [boost] Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions
> portable_path("/foo/bar") <- throws on Windows
Not sure why this would throw, what is the purpose of portable_path? "/foo/bar" is perfectly reasonable on Windows.
>This is also a way we could solve the whole problem of absolute paths.
>It's clear that "/foo" isn't an absolute native windows path.
This is not at all clear. I have and will contain to argue that "/foo" is an absolute windows path, since it does not respect the current directory. Also very important to me, this goes well with the URI definitions of absolute and relative, and it would be nice if the path class could support full URIs.
Glen
RE: [boost] Re: Thoughts on fixdec
Title: RE: [boost] Re: Thoughts on fixdec
>>
>> 6. There should only be conversions from strings, and _no_
>> mixed operations with strings.
>>
>
>In the absence of decimal literals, I think it's easier for the
>user to be able to use strings as pseudo-literals in all contexts;
>and I don't see how the mixed operations do any harm. In particular,
>I'm willing to give the user credit for knowing that
>
> my_decimal += "The quick brown fox...";
>
>doesn't make any sense.
I don't have an opinion, but one other case that I've seen from people use to using std::string is:
string error = "The number " + my_decimal + " is too big";
Glen
-Original Message-
From: Bill Seymour
To: [EMAIL PROTECTED]
Sent: 7/16/03 5:55 AM
Subject: [boost] Re: Thoughts on fixdec
Daryle Walker wrote:
>
> I think this library should be accepted.
>
Thanks.
>
> 1. We have two math-related namespaces already. The boost::math
> namespace leans to theoretical work and boost::numeric leans to
> hard-core computation.
>
I don't know that there's anything particularly theoretical about
decimal representations; and the library's target audience is not
those users who do "hard-code computation," which I understand to
mean numerical programming (in the sense of scientific and
statical programming).
It's not a major issue for me; and I'll do whatever the majority
wants.
>
> You should probably pick one of those namespaces (numeric?) and
> possibly rename the class to "fixed_decimal".
>
I'm reticent to require the user to type the extra "fixed_" in
every declaration of such an object.
>
> 2. There is a header to give deficient systems
> the std::numeric_limits class template (and pass through if
> exists).
>
I had that in a previous version but wasn't satisfied with it. I can't
remember why; so I'll look at the old code and see what it was that
I didn't like.
>
> 3. Instead of playing around with determining the significand type,
> just #include , ...
>
I do.
>
> ... use boost::intmax_t and be done with it.
>
You're right. My mind got stuck on int_least64_t; and I completely
forgot about intmax_t. Also, that might solve the
problem (whatever that was) if numeric_limits::is_specialized
and numeric_limits::digits10 is a constant _expression_. I'll
check that out.
>
> 4. What, no (safe-)Boolean conversion?
>
Ack! You're right!
>
> 5. The conversion from "int" needs to check for overflow.
> The conversion from "double" needs to check also for underflow.
> The conversion from strings needs to check also for bad formats.
>
But that would require some users to pay for something they don't
need. Users who need that level of correctness can write their
own checks; and others (probably most of the library's target
audience) get better efficiency.
>
> 6. There should only be conversions from strings, and _no_
> mixed operations with strings.
>
In the absence of decimal literals, I think it's easier for the
user to be able to use strings as pseudo-literals in all contexts;
and I don't see how the mixed operations do any harm. In particular,
I'm willing to give the user credit for knowing that
my_decimal += "The quick brown fox...";
doesn't make any sense.
>
> 7. Does the scale need to be first in all constructors? If it
> can be placed second, then converting constructors can be made
> and most of the mixed operator functions can go away.
>
> [ctor examples]
>
I'd want to see use cases for all those conversions before I agreed
to add them. Remember, the library's target audience is folk who
are writing financial software. It's not intended as a general-
purpose number-crunching library.
>
> 8. The "round_down" and "round_up" functions don't seem clear
enough.
>
They're intended to be clear to accountants who deal only with
non-negative debits and non-negative credits; and whether a value
is a debit or a credit is orthogonal to the mathematical notion
of sign.
Remember the instructions on your tax return form that tell you,
if line x is less than line y, subtract line x from line y and
write the answer over here; otherwise subtract line y from line x
and write the answer over there? Sure, that's a howler for
mathematicians; but it makes perfect sense to accountants. 8-)
>
> 9. What, no "operator <<" nor "operator >>"? (The shift would
> be a power of ten.)
>
Those operators don't exist for the floating-point types, and with
good reason IMO. Their use is best reserved for twiddling bits,
not for scaling. Even for binary integers, i << 1 is not generally
the same thing as i * 2 except on 2's-complement boxes.
>
> 10. The class is no longer a template, but some of the wording
> in the code and docs act like it's still a template. (When you're
> rewording, there's some HTML errors to fix.)
>
Could you point them out?
>
> 11. ...
>
> ...
>
> class MyNum
> {
> public:
> //...
> bool is_negative(
RE: [boost] Re: Draft of new Boost Software License
Title: RE: [boost] Re: Draft of new Boost Software License From: Alexander Terekhov [mailto:[EMAIL PROTECTED]] >> The Common Public License already has a section in the wiki and fails >> the boost requirements as shown. >> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License > >Yeah. That "review process" was really entertaining. Thanks for the >reminder. "Must be simple to read and understand" is rather subjective, >don't you think? As for "Must not require that the source code be >available for execution or other binary uses of the library"... well, >what's the problem? www.boost.org was pretty stable, thus far. Now you're arguing that the boost license requirements should be changed in order to make them compatible with the CPL? That's a bit of a stretch, especially since I like the boost requirements as they are. Glen
RE: [boost] Re: Draft of new Boost Software License
Title: RE: [boost] Re: Draft of new Boost Software License From: Alexander Terekhov [mailto:[EMAIL PROTECTED]] >David Abrahams wrote: >> Unless you are prepared to depart >> from your usual "hint-dropping" style and explain why you think CPL is >> better than what we're considering, I think it's probably going to >> remain... wherever it is that droppings end up. > >Sorry, I really can't explain it better than >http://www.ibm.com/developerworks/library/os-cplfaq.html The Common Public License already has a section in the wiki and fails the boost requirements as shown. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License Glen
RE: [boost] API Review request: XML API for C++, second round
Title: RE: [boost] API Review request: XML API for C++, second round From: Stefan Seefeld [mailto:[EMAIL PROTECTED]] >>Daryle Walker wrote: >> On Tuesday, June 24, 2003, at 8:12 PM, Stefan Seefeld wrote: >> >> [SNIP] >> >>> As the wrapper objects have reference semantics, I append '_ptr' to >>> their name to stress that fact. A practical side-effect of this is >> >> [TRUNCATE] >> >> Shouldn't the type names use a suffix of "_ref" instead? (I don't need >> to know that they're [possibly] implemented as pointers.) > >it seems 'pointer' has for you a very precise (C/C++) meaning. >I just used _ptr the same way it is used in CORBA (i.e. the C++ >mapping), where it doesn't imply anything about the implementation. > >I believe _ptr and _ref are fairly equivalent. _ptr has a very specific meaning in CORBA as well, you must explicitly manage the deletion of the object yourself, like, well... a pointer. If you must use the CORBA namings this, at my first look, seems closer to _var then _ptr. At which point I also think _ref is a better choice. Glen
RE: [boost] [filesystem] "." directory-placeholder added
Title: RE: [boost] [filesystem] "." directory-placeholder added From: Beman Dawes [mailto:[EMAIL PROTECTED]] >There are a bunch of reasons - but particularly it would be creating >names that will just be rejected by many (or even most) modern operating >systems. What would be the point of that? It is the same as with requests >for allowing full URI syntax in paths; without any mechanism in the >operational functions allowing those paths, what would be the point? The point is that there is a common need for parsing, combining, and otherwise manipulating URI and other paths prior to forwarding them to another system that processes that format. This may not be a mission of the filesystem library, but it is an important use case. Glen
RE: [boost] Formal review or Variant Library (Ed B.)
Title: RE: [boost] Formal review or Variant Library (Ed B.)
From: David Abrahams [mailto:[EMAIL PROTECTED]]
>> Extract is confusing. One problem is that it is deceivingly named.
>
>The name was my suggestion, so I'm going to argue with you a bit about
>that.
>
>> It doesn't extract data from the variant at all, but rather provides
>> type-specific access to data that still resides in the variant.
>
>"Provides type-specific access to data that still resides in the
>variant" is a mouthful, but I'm still not sure what it means. How is
>it different from extracting the data?
>> It is not clear from the name or the documentation that this would
>> be bad:
>>
>> variant* v = new variant; extract i(*v); delete v;
>> return i;
>
>Ugh. Is it clear from the name that this would be bad?
>
>std::back_insert_iterator > f()
>{
> vector v;
> return back_inserter(v);
>}
Yes, because here you have an inserter, which depends on what it
inserts data into. An extract on the other hand can usually exist
on its own.
I may be missing something, but as long as its just a proxy that offers
a type specific view of the data shouldn't it be called a view or a
proxy?
Glen
RE: Re: [boost] Re: Next revision of boost::thread & OS error code.
Title: RE: Re: [boost] Re: Next revision of boost::thread & OS error code. From: William E. Kempf [mailto:[EMAIL PROTECTED]] >> ... what() // from std::runtime_error. Implementation provides >> // a very explicit message, including who(), path1(), >> // path2(), and message reported by O/S (which is >> // subject to locale on some O/S's. >> >> int native_error() const; >> // a return of 0 implies a library (rather than system) error >> >> error_code error() const; // filesystem defined error code >> >> const std::string & who() const; // name of func throwing exception >> >> const path & path1() const; // argument 1 to func; may be empty() >> const path & path2() const; // argument 2 to func; may be empty() >> >> That's pretty heavyweight, but each function has important uses. > >This description brings a better understanding than what I had >previously, but doesn't fill in all the gaps. > >What's the purpose of a non-native error code? For that matter, if >what() includes a translated message for the error code, what >purpose is there for the native error code? When there is not a one to one mapping of library errors and native errors having both may be useful for platform specific recovery. >> For Boost.Threads, path1() and path2() obviously don't apply, but I >> wouldn't be surprised if a string identifying the thread in some way >> wasn't a possible need. > >The thread will always be the current thread, so there's no need to >carry that payload. It could be potentially be useful in a scheme where exceptions can be propagated across threads to the joiner. Glen
RE: [boost] Re: #pragma once
Title: RE: [boost] Re: #pragma once From: Alberto Barbati > Yet I'm stuck with MSVC anyway, as many other programmers out there, > and #pragma once may have a significant effect on compilation time on > that compiler. You may want to check this hypothesis, in the limited experimentation I did with MSVC6 there was essentially no difference in compile times, at least not with c++ code. What would be helpful is changing the rule as Gennaro mentioned to make single inclusion per translation unit the default. Glen
RE: [boost] Filesystem Library mini-review
Title: RE: [boost] Filesystem Library mini-review 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 "complete" reference directory. Is there such a > >"make_relative" function? Would it be hard to add? Note that I do not > >ned it at this time and there is thus no hurry. I am mostly curious if > >others might have similar needs, and how hard it would be to add it? > >Have you looked at path::relative_path()? > >You could use it like this: > > a.root_path() / b.relative_path() > >To compose a new bath based on a's root information and b's relative >information. Or did I misunderstand what you needed? I think what he might be asking for is something like: make /my/full/path relative to /my/base/dir produces ../../full/path Glen
RE: [boost] Formal review: Optional library
Title: RE: [boost] Formal review: Optional library From: Fernando Cacciola [mailto:[EMAIL PROTECTED]] >> >> * I'm unsure about the presence of "initialized()". On the one hand, the >> duplication in features (compared to "get/peek() == 0") is something I >> think designs should generally avoid. On the other hand, this name is >> more meaningful for what precisely "get/peek() == 0" signifies. I guess >> I'm +0 on this one. >> >To be honest, I dislike it too :-) >But some people found the alternative spellings ugly, >so I figured that a member function would make them happy. How about using !empty() instead of initialized() ? Just a thought, Glen
RE: [boost] Call for Volunteers [license review]
Title: RE: [boost] Call for Volunteers [license review] >From: David Abrahams [mailto:[EMAIL PROTECTED]] >> As a paying licensee of SleepyCat I can atest that it is more unsuitable >> then you indicated. The "free" license requires that all the source code of >> your program that uses BerkeleyDB be made available. > >If you feel this is important information, please add it to the Wiki page! Done. I like having all the answers start with "Pass" or "Fail", makes it easier to skim. Glen
RE: [boost] Call for Volunteers [license review]
Title: RE: [boost] Call for Volunteers [license review] From: Anthony Williams [mailto:[EMAIL PROTECTED]] >The SleepyCat license is convered here: As a paying licensee of SleepyCat I can atest that it is more unsuitable then you indicated. The "free" license requires that all the source code of your program that uses BerkeleyDB be made available. Glen
RE: [boost] Re: relative/absolute paths in filesystem library
Title: RE: [boost] Re: relative/absolute paths in filesystem library >From: Beman Dawes [mailto:[EMAIL PROTECTED]] > > >>is_absolute() - true if the directory (sans drive) starts with > > >>a / (c:/, /, /blah are absolute; c:blah, blah, ../blah are not) > > > > > >That's been added too. > > > > > >Hum... On multi-rooted operating systems like Windows, "/" and > > >"/blah" are relative to the current drive, and thus not considered > > >absolute. AFAIR, that was mentioned several times and was not > > >controversial. What was your rationale? > > > >I don't know if it was controversial, but I did bring this up during > >the review and I do think its very important. The basic definition > >of an absolute path should be a path that overrides the base path > >during a resolve. To rephrase, 'foo' is relative because it is an > >adjustment from the current directory, '/foo' on the other hand > >takes precendence over the current path. To re-rephrase, '/foo' is > >relative to the current drive, but not to the current directory. > >That seems like a stretch to me. With your definition, "absolute" isn't >equivalent to "not relative", and that seems counter intuitive. I must have been unclear, absolute is the same as not relative. A path is either absolute or relative with respect to its root. So my last example above where I essentially said that "an absolute path is relative to its root" may have been misleading. resolve() could be considered a bit odd, but I find it somewhat baffling that the make_absolute() seems strange to you, it is the way windows, urls, and every other system I've ever used that has the concept of drive or authority has worked. Some examples that use the make_absolute semantics I've described: 1. "dir " from the windows command line. 2. The .NET GetAbsolutePathName(pathspec) function 3. GetFullPathName(...) from the Windows SDK 4. Basically any windows or os/2 system function that takes a path Actually #2 might be an indicator that I'm in the minority by call "/path" sans drive absolute. . . on the other hand the URL rules clearly specify "/path" as absolute so maybe not. >There has also been so consideration of providing has_xxx query functions, >which would express the above as: > > foo.has_root_directory() -snip- >If has_xxx query functions are provided, then there isn't really a need for >a separate absolute query, since foo.has_root() (or >foo.has_root_directory(), for those who prefer your definition.) > >Not having a function named absolute() might be safest, too, because it >would force users to choose exactly the has_xxx function they wanted, >rather than jumping to a conclusion about the semantics of absolute(). That works. -snip- >Understood. AFAIK, it is going to be possible to write both your >make_absolute() and resolve() functions in a portable manner using path >member functions. Good, this is what's important. Glen
RE: [boost] Re: relative/absolute paths in filesystem library
Title: RE: [boost] Re: relative/absolute paths in filesystem library From: Beman Dawes [mailto:[EMAIL PROTECTED]] >>current_directory() - returns the current directory (and drive if >>windows) > >That's been added, per the formal review. The actual names for it >and its sibling function will be current_path() and initial_path(), >to reflect the fact that a path rather than just a directory name >are returned. I'm not sure what initial_path() is, but I believe current_path() should be current_directory() because: 1. It is the common name for it. 2. What I want is a directory (the current one), a path might not be a directory. I agree that current_directory_path() is better then current_directory_name(), but the fact that its a directory is what's important. What would be the name for current_drive() ? >>is_absolute() - true if the directory (sans drive) starts with >>a / (c:/, /, /blah are absolute; c:blah, blah, ../blah are not) > >That's been added too. > >Hum... On multi-rooted operating systems like Windows, "/" and >"/blah" are relative to the current drive, and thus not considered >absolute. AFAIR, that was mentioned several times and was not >controversial. What was your rationale? I don't know if it was controversial, but I did bring this up during the review and I do think its very important. The basic definition of an absolute path should be a path that overrides the base path during a resolve. To rephrase, 'foo' is relative because it is an adjustment from the current directory, '/foo' on the other hand takes precendence over the current path. To re-rephrase, '/foo' is relative to the current drive, but not to the current directory. I deal with URLs as much as with file paths and this does color my thinking. The way I have outlined it I am able to use windows drives and URL authorities with exactly the same semantics. >>make_absolute() - prepends current drive if no drive is defined, >>inserts current directory after the drive if it is not an absolute >>path > >If I understand you correctly, make_absolute() and resolve() differ >in that the source of the "base" path in make_absolute() is hardwired. >Because the "base" path is always absolute with make_absolute(), >result is always absolute. There is more to it then that. make_absolute() uses the authority (windows drive) given in the path if it is present, otherwise using the current drive. So make_absolute(a:foo) is different from resolve(c:/bar, a:foo) where c:/bar is the current directory, because make_absolute(a:foo) is a request to make it absolute with respect to the current directory of drive A. Referring to resolve. . . >These semantics seem carefully worked out, and there are probably >cases where they are exactly what is required. > >On the other hand, these semantics are complex, and may cause >confusion. It is easy to incorrectly assume the result is always >absolute. The preconditions and postconditions seem unclear. Are >exceptions are being thrown for what are really preconditions? There are really two basic rules. Resolving from one authority or drive to another is illegal, and a path starting with a / is absolute with respect to its authority. >Thomas Witt pointed out that with a full set of decomposition functions >to grab portions of a path, it becomes easy to write code like: >These semantics aren't the same as your resolve() or make_absolute(), >but may be what is required for some applications. The semantics I'm arguing for are mandated for urls (RFC 1808 to name one of many) and work well for file paths. If I haven't said it before, thanks for all of your work on the filesystem library (and boost in general), it is an important piece missing from the standard. Glen
RE: [boost] Re: relative/absolute paths in filesystem library
Title: RE: [boost] Re: relative/absolute paths in filesystem library I'm dealing with filesystem paths and urls and the way we ended up implementing it is with the following functions (we are not currently using boost::filesystem, these are from an internal library): current_directory() - returns the current directory (and drive if windows) make_absolute() - prepends current drive if no drive is defined, inserts current directory after the drive if it is not an absolute path is_absolute() - true if the directory (sans drive) starts with a / (c:/, /, /blah are absolute; c:blah, blah, ../blah are not) resolve(base, rel) - returns a path that is 'rel' resolved relative to 'base' according to the following table: base rel result - base rel base/rel base /rel /rel base c:rel ... throws exception base c:/rel c:/rel /base rel /base/rel /base /rel /rel /base c:rel ... throws exception /base c:/rel c:/rel c:base rel c:base/rel c:base /rel c:/rel c:base c:rel c:base/rel c:base c:/rel c:/rel c:base a:rel ... throws exception c:base a:/rel a:/rel c:/base rel c:/base/rel c:/base /rel c:/rel c:/base c:rel c:/base/rel c:/base c:/rel c:/rel c:/base a:rel ... throws exception c:/base a:/rel a:/rel This attempts to follow the same phliosophy as the url resolution rules and has worked out well so far. During the review I argued for make_absolute to behave like resolve(current_directory(), rel) but now I believe that two separate functions is the best way to do this. Just wanted to get this off before it was too late, Glen
RE: [boost] Re: Proposed Boost Assert -- once again
Title: RE: [boost] Re: Proposed Boost Assert -- once again > From: Eric Woodruff [mailto:[EMAIL PROTECTED]] > > In my opinion, assertions indicate enfrorcement of pre/post conditions, that > are separate from the algorithmic logic of a function. What happens from the > result of the assertion, an exception or an abort is a separate issue. > > Consider (if assert takes a boost::function0): > > assert (!harddrive.isFragmented (), boost::bind (&HardDrive::defrag, > &harddrive)); > > In this case, it there is a simple remedy to the failed pre-condition. The > alternative is: assert (!harddrive.isFragmented (), std::abort); In the first case you're not talking about a failed precondition, because the logic (of which the assert is a part) is designed to handle both cases. I don't like the idea of using assert in that way at all and would strongly encourage it be replaced with: if (!harddrive.isFragmented()) harddrive.defrag(); I really agree with Peter here, assert shouldn't have a canned option for throwing. When you really need logic errors to throw you have to put a non-trivial supporting infrastructure in place and very likely a more complex protocol then a simple throw. I've spent the last year working on a server with a "can't stop" requirement and the objects it throws may include information about the subsystem that's been affected and the scope of the problem. Glen
RE: [boost] Re: Re: Re: Property_map docs
Title: RE: [boost] Re: Re: Re: Property_map docs From: Edward Diener [mailto:[EMAIL PROTECTED]] > OK, I am missing something in these docs which I expected to see and it is > not there for me. Evidently it is for everybody else and they consider it to > be adequate. I will say that no matter how poor the documentation seems to > me, it is probably on another level which I don't understand and which > others can easily figure out without any more specific explanation. I > apologize to all concerned and will simply bypass such implementations in > the future when the language of it is beyond my understanding. I thought > that by criticizing there would be others who might agree that the > documentation is not adequate for an intelligent C++ programmer to grasp, > and there would be an effort by either Mr. Siek, or someone else who > understands property map, to improve it and make it more understandable. I > was wrong and will leave it at that and wish everyone good luck in their > programming and documentation endeavors. If you're asking for the documentation to include more descriptions of the concepts that it builds upon, beyond links to other documents, you may well be asking for too much. Especially if you want an introduction to a subject area where much has already been written. OTOH, if there are things that seem out of place, or sections of the docs that leave you particularly confused, point them out -- preferrably suggesting alternative verbage where you can. Lets all take a deep breath and try to keep it as constructive as we can. Glen
