[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
Pavel Vozenilek wrote:
> "Edward Diener" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Extremely dangerous and error prone. I can't even imagine a non-POD
>> type where flagging it for memcpy_copyable and memcpy_moveable can
>> be right.
> Can
>> you give an example ?
>>
> It is error prone but many other constructs are too.
>
> Example of moveable object:
>
> struct string_buffer {
> unsigned size;
>char* data; // allocated buffer
> };
According to my understanding, this is a POD type. It would be unnecessary
to flag this. But even for a POD type such as this, copying would lead to
errors if the char * data were dynamically allocated since a double delete
would probably be done. And adding a copy constructor to deal with it would
remove it from POD category and make your memcpy_copyable and
memcpy_moveable irrelevant for it.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
Pavel Vozenilek wrote: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > ... >> >> I don't believe you can use memcpy to move any non-POD types >> portably, >> i.e. without special knowledge of the compiler. >> > Thats my point - you may flag some types as safely moveable and then > use > this knowledge in algorithms. User has the responsibility to do the > decision. Extremely dangerous and error prone. I can't even imagine a non-POD type where flagging it for memcpy_copyable and memcpy_moveable can be right. Can you give an example ? Also, "flagging it" introduces some more complication on the user's part. How would you propose the user do this ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.30.2 is released
David Abrahams wrote: > This release was managed by Dave Abrahams with the generous and > dedicated help of Aleksey Gurtovoy and Misha Bergal of > Meta-Communications, Inc., and of Martin Wille. > > We expect this to be the last release in the 1.30.x chain; see our CVS > repository or its mirrors for new developments expected to appear > shortly in 1.31.0. Congratulations to all. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [Filesystem] Exact type of name checking function?
Beman Dawes wrote: > At 02:08 PM 8/18/2003, Edward Diener wrote: > > >... one of the reasons, as I understand it, for > >boost::function and boost::bind is so the end-user has the benefit > of >defining his callback as he sees fit and not have it more rigidly > dictated > >by the implementation. That is the main reason I support such a > callback >for boost::filesystem checking for pathname validity; it > gives the > end-user > >maximum flexibility while letting the internals of > boost::filesystem deal >with the result of the callback as it sees > fit. Inevitably, somewhere > down > >the road, programmers will say that the callback system is too > rigid for >their needs, no matter how simple is seems as if it > should be now. With >boost::function such a complaint is very close > to impossible. I am not >trying to create more work for the > implementor, only suggesting that the >most flexible callback > implementation done now will save possibly more > work > >in the future and be beneficial to end-users. > > Edward, > > If we loaded Boost.Filesystem up with every feature which would be > beneficial to some user at some future time, it would be full of > caches, allocators, path translators, vast numbers of compound > operations, file system virtualizers, generation dataset emulators, > partitioned dataset emulators, and a lot of other stuff. Some, like > wide-character path names, I'd dearly love to add. Everything on that > list is useful, sometimes very useful. You are confusing the use of choosing a callback method with adding a new feature. If you are already determined to add a callback method, as a new feature, to allow the end user to specify what is a valid filepath name, why not use the callback method which is already a part of the Boost libraries ? Of course you can choose a simpler, less flexible callback method if you like. But I truly don't see how that can be better from a design point of view than allowing the user to pass in a boost::function as his callback. I am not advocating using boost::function because its there. I'm advocating using it because it cleanly solves what you want to do: allow the user to pass a callback method to you to determine the valid filepath name. Nor do I understand the overhead involved. However you design boost::filesystem to use your callback, the callback "pointer", if you will, will get passed into some functionality, you will store it away somewhere, and later when your functionality has to determine whether or not a filepath name is valid, you grab the pointer from wherever you have stored it and call the callback function for an answer. What is the difference whether the pointer is some variation of C++ function pointers or is a boost::function, which can encompass them all ? To your internal design it should be the same. But to the end user boost::function gives him the maximum flexibility of binding in whatever he likes. So where is the downside to using it over some more constrained method ? Surely secreting away a boost::function is just as easy as doing so for any specific type of callback pointer. And calling a callback function through boost::function is likewise. The only thing I can think of is that you don't want boost::filesystem to rely on this other implementation at all. Fine, if it isn't as portable as boost::filesystem is and using it will reduce your portability, I can understand that. But boost::function will almost certainly be in the next C++ standard, and C++ compilers are catching up to standard C++. So I expect that compilers in the near future will do so too. I used boost::function and boost::bind to provide event handling in my own library for VC6, one of the least compliant libraries around. So it is really hard to believe that any compiler that can't use boost::function and boost::bind, with all the excellent workarounds that the implementors of those created to get around compiler weaknesses, is worthy of being targeted by boost::filesystem. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Filesystem] Exact type of name checking function?
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>>
>>> FWIW, Boost.Function is overkill for many simple cases. This might
>>> be a case where the FS library should just provide a class with a
>>> virtual function:
>>>
>>> struct checker
>>> {
>>> virtual ~checker() {}
>>> virtual bool operator()( std string const& ) = 0;
>>>
>>> shared_ptr next; // suggested.
>>> };
>>
>> Boost.Function makes things simpler for the user.
>>
>> enum check_type { check_posix, check_windows, ... };
>> bool my_name_checker(std::string const & s, check_type t);
>>
>> Compare
>>
>> bind(my_name_checker, _1, check_posix)
>>
>> against
>
>
>
> So I left out a few bits
That's all very nice but one of the reasons, as I understand it, for
boost::function and boost::bind is so the end-user has the benefit of
defining his callback as he sees fit and not have it more rigidly dictated
by the implementation. That is the main reason I support such a callback for
boost::filesystem checking for pathname validity; it gives the end-user
maximum flexibility while letting the internals of boost::filesystem deal
with the result of the callback as it sees fit. Inevitably, somewhere down
the road, programmers will say that the callback system is too rigid for
their needs, no matter how simple is seems as if it should be now. With
boost::function such a complaint is very close to impossible. I am not
trying to create more work for the implementor, only suggesting that the
most flexible callback implementation done now will save possibly more work
in the future and be beneficial to end-users.
I am a bit surprised that Boosters themselves do not seem to want to support
one of their own key libraries. Maybe because I am used to the C++ extension
callback and event systems invented by Microsoft and Borland for their
frameworks, anything less or more restricted seems primitive to me. That is
why I am quite happy with the excellent work done on boost::function,
boost::bind, and boost::signals by their implementors.
The latter reminds me to ask, although off-subject for this thread, why
boost::signals wasn't submitted for TR1. The C++ standard library sorely
needs an event model and boost::signals is a good one with kudos to Mr.
Gregor.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Filesystem] Exact type of name checking function?
Beman Dawes wrote: > In discussions about being able to specify a function to check the > validity of path element names, a simple function pointer has been > used: > >typedef bool (*name_check)( const std::string & name ); > > Alternately, boost::function could be used. The boost::function docs > mention several advantages over function pointers; the advantage that > might particularly apply is that: > > "Boost.Function allows arbitrary compatible function objects to be > targets (instead of requiring an exact function signature)." > > That can be a really powerful advantage in some applications, but > usage of name checking in boost::filesystem seems likely to be > limited to very > simple cases where plain function pointers will do just fine. I'd > also like to avoid the dependency on an additional library, since > Boost regression > test reporting breaks if boost::filesystem::path breaks. > > So unless someone comes forward with a killer argument, a simple > function pointer will be used. > > Comments? I disagree. You have a magnificent implementation in boost::function, which can be bound to many different callback types, and yet you don't want to use it simply to reduce a dependency. Why restrict the end-user to a global function and go back to C++ programming of years ago simply because you are afraid of being dependent on another implementation ? My callback function may well be dependent on another class within which I may be using the boost::filesystem, and to now have to fool around with global functions instead of allowing a class member function to handle the callback is archaic. Why create event handling and callbacks via boost::function, boost::bind, and boost::signals if Boost implementors themselves don't want to use these ideas when they create their libraries ? It's a rhetorical question but it is well-meant. Give the end-user the widest possible latitude, and just bite the bullet of what you need to do to make your library as effective as it can be. That's my opinion, for what it is worth. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: boost::filesystem file restrictions
Title: RE: [boost] Re: boost::filesystem file restrictions /blah is not an absolute path under Windows. It is relative to the current drive ( or the drive of the current directory, which is the same ). Any file system paths in Windows are absolute when specifying a drive letter, else they are relative. There is no distinguishing /foo and foo under Windows other than to say that /foo is relative to the current drive while foo is relative to the current directory. That is not to say that a generic filesystem may not want to distinguish between the two but it needs to be clarified under Windows what these mean "Glen Knowles" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... 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
[boost] Re: boost::filesystem file restrictions
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> A path on windows that starts with '/' is a set >>> of instructions which begins: "go to the root of the current >>> directory path". >> >> Correction. It does not mean that. It means go to the root directory >> of the current drive. > > Is the current drive not the same as the root of the current > directory? AFAICT, they are locked together. IOW, I think we were > saying the same thing. I just wanted to additionally make it clear > that even these paths are, in a sense, relative to the current > directory. I agree that current drive and current directory are tied to each other and that your description is technically correct. In fact, to further support you, the Windows API does not have a current drive call but rather a GetCurrentDirectory call. The VC++ and BCB RTLs do have _getdrive() calls to get the current drive, most probably from the current directory. Still the meaning of '/' in Windows refers commonly to a the root of a drive ( or volume ), and when no drive letter is given, the current drive is chosen. My "correction" should have been an elucidation. It still supports your notion that any path on Windows which does not specify a drive letter is considered a relative path and any path which does specify a drive letter is considered an absolute path. I am excluding in that all URI paths. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
David Abrahams wrote:
> Glen Knowles <[EMAIL PROTECTED]> writes:
>
>>> 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 find that somewhat compelling... but in the end it doesn't hold up.
>
>> I don't see how
>> leaving out the drive makes it less portable then leaving out the
>> computer name.
>
> It's less portable because how it is to be interpreted *with respect
> to the filesystem* can change dynamically. Remember the name of this
> library, "filesystem"? ;->
>
> Filesystems belong to computers. A computer's filesystem is accessed
> via an infinite tree of names (**). How those names which correspond
> actual storage are mapped can be modified dynamically in any number of
> ways: you can have symbolic and hard links, mount drives, remote
> computers can come online or go away, non-storage devices can be
> mounted at locations in the tree etc. The one constant is the
> structure of the tree of names which allows us to access a virtual
> location in the filesystem (as opposed to physical).
>
> A path is a set of instructions for traversing the name tree. By any
> reasonable definition, an absolute path identifies a single virtual
> location in a filesystem's name tree, not one that can change based on
> the process state. A path on windows that starts with '/' is a set
> of instructions which begins: "go to the root of the current
> directory path".
Correction. It does not mean that. It means go to the root directory of the
current drive. It is still not an absolute path since the current drive
changes. If one specified 'a:/', then that is an absolute path as defined
under Windows. Even if 'a:' were a removable disk, and thus could be
physically changed, it would be considered an absolute path.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: boost and DLL's
E. Gladyshev wrote: > --- Edward Diener <[EMAIL PROTECTED]> wrote: >> Exporting/importing C++ classes is completely >> implementation dependent, due >> mainly to name mangling, and requires a DLL for a >> particular >> platform/compiler/release to be built. > > There are several issues with DLL and C++, to name > few: > 1. Name mangling > 2. Using inline methods in the exported class. > 3. Global class instanses in the DLL. > > How does boost ensure that inline methods don't > conflict with the exported methods. The conflict can > be platform specific. > > Is it allowed to have global instances of a class in > boost's DLLs? > > Are there any development policies on how exported C++ > classes should be implemented/tested in boost? Good questions, but as I have never attempted to export classes with inline methods or have global instances of classes in a DLL in my own non-Boost work, Boost implementors will have to answer you on these items. I admit that I have stayed away from "inline" in my career, and no doubt I will soon be castigated by all those who will tell me why "inline" speeds up code execution. As for global objects, like many C++ programmers I use them as little as necessary, and would never think to export a global object itself as opposed to class definitions and their member functions. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
Ross Smith wrote: > George A. Heintzelman wrote: >>> Given that I have a string 's' from somewhere, I'd like to create a >>> regular expression where some part must match that string. The >>> problem is, the 's' could contain characters that have a special >>> meaning in regular expressions. Is there some support function that >>> can provide an escaped version of 's'? Something that transforms >>> "my.*string" into "my\.\*string"? If there isn't, would it be >>> possible/easy to provide one? >> >> Second that request. I just had a need for this, though I wound up >> ignoring the problem rather than fixing it... > > There must be something in the air; I just had a need for this too. My > quick-and-dirty solution was to simply replace every non-alphanumeric > character with a hex escape sequence (\xNN). > > Having it just add escapes to a list of special characters wouldn't > work as a general solution, because the list of characters depends on > the > flags passed to the regex functions. That is a good point. However you always know what flags are passed to the regex function since they are available. That's not arguing against such a function as being part of the library itself but it is still doable by you. Furthermore you can set the flag mode you like to simplify your escaping, but of course this is not a general solution as the rest of the regular expression may require particular flags set. > Of course there are settings > where > my hex-escape solution won't work either. I don't think a general > solution is possible without making it part of the library; it needs > access to the innards of the regex objects in order to know the exact > syntax they recognise. That is not true. One just needs to read and understand the documentation on the particular flags and what they mean. There are no "secret innards" which retain information about escaping characters which you can't find for yourself by testing the flags. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SRPM 1.30.1 available
David Abrahams wrote: > "Neal D. Becker" <[EMAIL PROTECTED]> writes: > >> I have modified the 1.30.0 SRPM for 1.30.1. Pretty simple, except >> you need a patch to fix the version number or the RPM build will >> fail. >> >> Should I upload the SRPM somewhere? > > Probably not. 1.30.1 is completely broken; there are scads of files > missing. Suggest you somehow remove the 1.30.1 release from SourceForge, to keep end users from downloading it, until you can fix it or put up a 1.30.2 release instead. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
Edward Diener wrote: > Ross Smith wrote: >> George A. Heintzelman wrote: >>>> Given that I have a string 's' from somewhere, I'd like to create a >>>> regular expression where some part must match that string. The >>>> problem is, the 's' could contain characters that have a special >>>> meaning in regular expressions. Is there some support function that >>>> can provide an escaped version of 's'? Something that transforms >>>> "my.*string" into "my\.\*string"? If there isn't, would it be >>>> possible/easy to provide one? >>> >>> Second that request. I just had a need for this, though I wound up >>> ignoring the problem rather than fixing it... >> >> There must be something in the air; I just had a need for this too. >> My quick-and-dirty solution was to simply replace every >> non-alphanumeric character with a hex escape sequence (\xNN). >> >> Having it just add escapes to a list of special characters wouldn't >> work as a general solution, because the list of characters depends on >> the >> flags passed to the regex functions. > > That is a good point. However you always know what flags are passed > to the regex function since they are available. That's not arguing > against such a function as being part of the library itself but it is > still doable by you. Furthermore you can set the flag mode you like > to simplify your escaping, > but of course this is not a general solution as the rest of the > regular expression may require particular flags set. > >> Of course there are settings >> where >> my hex-escape solution won't work either. I don't think a general >> solution is possible without making it part of the library; it needs >> access to the innards of the regex objects in order to know the exact >> syntax they recognise. > > That is not true. One just needs to read and understand the > documentation on the particular flags and what they mean. There are > no "secret innards" which retain information about escaping > characters which you can't find for yourself by testing the flags. Let me add to my remark by saying that it is true that you can change the characters of a regular expression using localization with a dll or message catalog, but again you know what changes have been made and should be able to escape the appropriate characters. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Beman Dawes wrote: > At 09:58 PM 8/4/2003, Alisdair Meredith wrote: > > >There is a problem with the Borland BCB6 compiler... > > What is the status of the Borland compiler as far as fixes and > updates go? Have they announced any plans? Although they have not announced anything further about more BCB6 service packs, it is easy to guess that there will not be any more. All indications are that Borland is working on a BCB7 release but, in true Borland fashion, there is no date given when it will be released until it happens. Borland has reiterated they are committed to 100% Ansi C++ standard compatibility, and have said that they are working on a new compiler engine that will better support both their Windows and Linux C++ offerings, but again there is no date or roadmap as to when that might be achieved. Borland almost never announces any dates for doing anything and, at the most, they mention general plans with very few specifics. That is evidently just their normal company policies. Given all the BCB6 bug reports that were put up on their Quality Central bug tracking system by Mr. Meredith, many other developers, and yours truly, many of them compiler bugs taken from Boost tests etc., it is disappointing as per usual that they rarely see it as a necessity to make there current release better, but at least they have a roadmap for the many things which will hopefully be fixed in BCB7. I believe that Boost developers and users can also access their Quality Central bug tracking system and add their own reports if they like. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
Daniel Frey wrote: > Hi John, Hi .*, > > Given that I have a string 's' from somewhere, I'd like to create a > regular expression where some part must match that string. The problem > is, the 's' could contain characters that have a special meaning in > regular expressions. Is there some support function that can provide > an escaped version of 's'? Something that transforms "my.*string" into > "my\.\*string"? If there isn't, would it be possible/easy to provide > one? You can turn on the literal flag type. All characters in your regular expression are treated as literals. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Beman Dawes wrote: > At 06:03 AM 8/14/2003, Walter Landry wrote: > It would be trivial to add an additional path constructor that takes a > checking function or function object. > > But that would kill ease-of-use. It is one thing to require an > additional constructor argument in the fairly limited use "native" > case, but the portability checking is applied to each and every path > object constructed, including the many path temporaries created by > the automatic conversions > from char * and string. You could have the checking functor as a pointer to a boost::function which is a default argument initialized to 0. That wouldn't kill ease of use or change anything for the users who are very happy with the current posix default. > > (That "kill ease-of-use" point might be hard to understand if you > haven't actually written code using the library. The automatic > conversions really > do allow "script-like" programming ease, and are reasonably safe > given the conversion result is class path.) > > Also, the portability checking policy often needs to propagate to > called functions such as third party liberties. Adding overloads of > functions to take an additional argument is also too messy, and > doesn't provide for automatic pass-through to lower level functions. I think this is an excuse for a certain amount of additional rewriting of the library. How you propagate the functor pointer is your own business but we all have been faced with problems like this when adding a new feature to an implementation. Internally, do what you need to do but for the end-user I think you need to consider what is best and most flexible for him. > In most (but not all) programs it really would be convenient if > portability checking policy was a global. But of course we all know > that "global variables are consider harmful". There are also several > valid use cases where a program needs to switch back and forth > between portability policies. Yes, not all portability policies need to theoretically be the same. There are cases when an OS accepts a file name in one instance, such as iteratoring through wildcard names, whereas another instance it does not accept the same notation, such as determining whether or not a specific file exists. So I think you need to allow portability policies on an instance by instance basis. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [regex] Escaping a search string?
John Maddock wrote:
>> Front end localization could change this also, I believe. For
>> instance if
> a
>> dll or message catalog substitutes '!' for '$' wouldn't I need to
>> escape
> '!'
>> instead of '$' in order to use '!' as a literal in an expression ?
>
> Yes, I was afraid you would bring that up :-)
Since I support the same localizations using your regex++ library in my
components, I have to.
>
>> In this regard it would be helpful if the end-user could obtain back
>> at run-time the substitutions that are made due to localization. I
>> didn't see this as a function of the regex_traits class reference
>> but maybe it is there.
>
> No it's not - the internal data simply isn't structured in a way that
> allows that kind of query - however as you yourself said already -
> the end user
> *knows* what the special characters are (if they have been changed).
This is true. I was really suggesting it to forestall the objection that the
changes are normally in a file set up manually, such as a resource DLL, so
it is difficult to read the file back in and load the substitutions etc.
etc. to figure out what changes were made. Of course one needs to know what
the localization changes are to present valid regular expressions so the
objection is a weak one.
>
> The worst case scenario: the user has substituted a traits class that
> uses different characters for the \ x { and } regular characters, so
> that escape sequences like: \x{32} don't work anymore.
You forgot that the digit characters themselves can be changed also.
I think, given the difficulty, but not the impossibility, for an end-user to
do it, you might consider a function in reg_expression which returns an
escaped string, like your example escape_regex function, for any regex
string passed to it, taking into account all the currently set flag
possibilities and possible localization changes.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
Daniel Frey wrote: > Edward Diener wrote: >> You can turn on the literal flag type. All characters in your regular >> expression are treated as literals. > > That doesn't help. Maybe an example clarifies what I need: > > std::string s = "1.30.0"; > boost::regex r( "^(.*)\s+(?:[Vv](?:ersion)?\s+" + s + ")\s*$" ); > > I need a way to convert 's' to '1\.30\.0', not to escape the whole > regex. No such function exist in the regex++ library but it should be easy enough to build one for yourself. In the regex++ doc, under the syntax topic there is a list of all the characters that aren't literals. Put them in a static string and write a transformation function which checks each character in your source string and if it matches one in the static string, added a backslash in front of it before putting it in a result string. BTW, in your example above, you of course need two backslashes for every backslash that occurs in your string literal. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
John Maddock wrote:
>> Given that I have a string 's' from somewhere, I'd like to create a
>> regular expression where some part must match that string. The
>> problem
>> is, the 's' could contain characters that have a special meaning in
>> regular expressions. Is there some support function that can provide
>> an escaped version of 's'? Something that transforms "my.*string"
>> into "my\.\*string"? If there isn't, would it be possible/easy to
>> provide one?
>
> Good question, no there isn't, but how about:
>
> std::string escape_regex(const std::string& s)
> {
> static const std::regex e("[\\[\\]$\\^|.+*?(){}]");
> return regex_merge(s, e, "$&");
> }
>
> Just off the top of my head and untried
>
> I'll try and think up something more general that works with all the
> flag settings though...
Front end localization could change this also, I believe. For instance if a
dll or message catalog substitutes '!' for '$' wouldn't I need to escape '!'
instead of '$' in order to use '!' as a literal in an expression ?
In this regard it would be helpful if the end-user could obtain back at
run-time the substitutions that are made due to localization. I didn't see
this as a function of the regex_traits class reference but maybe it is
there.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Pavel Vozenilek wrote: > "Edward Diener" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Beman Dawes wrote: >>> At 09:58 PM 8/4/2003, Alisdair Meredith wrote: >>> >>> >There is a problem with the Borland BCB6 compiler... >>> >>> What is the status of the Borland compiler as far as fixes and >>> updates go? Have they announced any plans? >> >> Although they have not announced anything further about more BCB6 >> service packs, it is easy to guess that there will not be any more. >> All > indications >> are that Borland is working on a BCB7 release but, in true Borland > fashion, >> there is no date given when it will be released until it happens. > ... > > Something is happening right now - announcement and beta invitation > is on http://bdn.borland.com/article/0,1410,30279,00.html. Good. I don't think it is really much more than I implied, but it is good to see that Borland is committed to C++ for more years. Now they need to deliver and produce an Ansi C++ compatible compiler. This will also mean many less headaches for Boost developers and Boost users who use C++ Builder. I hope I can afford this wondrous new compiler when it comes out, that's all . ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost and DLL's
E. Gladyshev wrote: > I was wondering, has the boost comunitiy had a > discussion about exporting/importing C++ classes from > a DLL? Exporting/importing C++ classes is completely implementation dependent, due mainly to name mangling, and requires a DLL for a particular platform/compiler/release to be built. I know regex++ does this for it's C++ classes, and I imagine all other implementors who export/import C++ classes in their libraries also enable their code to be built for the particular implementations they support using make files or bjam. What discussion about exporting/importing from a shared library do you want to have ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: GUI/GDI template library
Terje Slettebø wrote: >> From: "Edward Diener" <[EMAIL PROTECTED]> > >> Add to this the fact that nearly every C++ programmer already works >> with a framework library depending on his implementation of choice. >> On Windows alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, >> and no doubt > others >> about which I have no knowledde, each tied very closely to a >> particular > C++ >> compiler, IDE, and implementation. > > I just wanted to point out that several of these, Qt and wxWindows, > are cross-platform, so they are not tied to any specific compiler or > platform. wxWindows is also Open Source, and I've good experience > with the little I've used it. It's very easy to get up and running > with it (at least it was on Windows). snipped... I see you are supporting my main point which was that re-inventing a GUI framework for Boost, with both many platform dependent and cross-platform frameworks already in place and very popular with most C++ programmers, will be duplicating functionality which already exists. I do realize that most of these frameworks do not use template techniques but that doesn't make them necessarily any less popular with their many users. Also, as I pointed out, the amount of work necessary to implement an effective GUI framework is enormous, given the differences in GUI controls and GDI-like functionality on the major OSs. I am certainly not against the OP trying to do something like this for Boost but I think that is naive to assume that one can create such a Boost templated cross-platform framework without a tremendous amount of work and time spent invesigating the GUI and graphics APIs of a number of OSs. OTOH if the consensus is that such a framework will work only by having the end user plug-in to it classes with the appropriate functionality for a generic idea, such as a listbox let's say, there will be enormous amount of work for the end-user to do and even then the templated listbox may provide hooks into only a very small amount of functionality which listboxes represent on that user's particular OS. As you have pointed out in the rest of your post, it may prove more worthwhile to work with the developers which already exist for a free cross-platform framework like wxWindows, in order to encourage them to use more modern C++ idioms which will make using their framework easier for end-users, than attempting to recreate one all over again. Boostifying wxWindows and having Boost developers and wxWindows talking to each other about better techniques for making wxWindows easier to program may be much more worthwhile than re-creating yet another GUI/Graphics framework. As someone who has worked with numerous GUI frameworks on the Windows platform, I know that the sophistication of such an interrelated set of classes is enormous even just for the Windows API, let alone cross-platform work, and the effort to create such a framework has almost certainly taken the talents of teams of programmers from such big companies as Microsoft and Borland. That is not to say that the talents of many programmers who have contributed to a free framework should be denigrated in the least, only that one should not in any way underestimate the time and effort involved, and the continuing work it takes to chart changes and additions in OS APIs. In my career I have seen and worked with a few cross-platform frameworks from the past, and many have come and gone to be replaced by others. I am sure people must remember Zinc and Zapp and XVT and I am sure there were many, many others whose names I have forgotten by now. I believe the difficulty of just maintaining cross-platform workability effectively may have sunk most of these commercial efforts, but the general effort and support involved was probably enormous. Of course most all of these frameworks were also going against established GUI frameworks from Microsoft, Borland , and other major corporations. If one just charts the questions on the Borland and Microsoft and Sun NGs and forums regarding VCL and MFC and .NET GUI and Swing and AWT every day, one sees the difficulty even for huge corporations in maintaining an effective framework API. If Boost can create such a templated API which works for a decent number of C++ programmers, without even considering the numbers of C++ programmers who might leave their very comfortable RAD environments for a Boost GUI API, I say bravo. But do not underestimate the difficulties involved and do consider working to improve free frameworks which may already exist like wxWindows instead. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: GUI/GDI template library
E. Gladyshev wrote: >> Are you aware that the pImpl idiom is used for many >> different things > > It defenitly has its place but not in modern C++. > >> or have >> you just decided its not modern C++ at all because >> you don't use it for the >> things you want to do ? > > In my opinion modern C++ is more oriented toward > program specifications and generic (compile-time) > programming. In modern C++, the program functionality > can be customized by specifying custom data types and > using them in a generic way (library). It is more > like a type oriented programming not implementation > driven. pImpl doesn't fit there. The pImpl technique is an idiom for hiding the private methods and data members of a class from the view of the user of that class. It has aesthetic appeal for me. It makes the user of the class see only what is relevant in the class, while putting the implementation details of the class interface somewhere else. That it also speeds up compilation by not having the class, as the compiler sees it, change when the internal class as represented by its private pImpl pointer changes, is a side benefit to it but not one I consider overridingly important. I agree that it achieves little other than an aesthetic view of class internals and a speed up in build times when a class's implementation, as opposed to its end-user interface, changes. As such there is no pragmatic design reason why it is necessary. These are the major reasons, as I understand it, why the pImpl idiom is generally used and why I have used it. But there may be other reasons. I don't understand what this has to do with modern C++ as you see it. But I think that your view of modern C++, a term perhaps taken from Mr. Alexandrescu's fine book on template programming and metaprogramming techniques, and nurtured by some of the equally fine work done by Boost implementors, may be severely limited. I only hope that you don't get into the habit of seeing all of modern C++ programming as template programming only, and view all other programming and design idioms from that perspective. To me this ioos what you are doing by syaing that the pImpl is not part of modern C++. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote: >> Not quite. pImpl is really bad when you have >> multiple interacting >> concrete types. I think you'll find yourself doing >> a lot of >> polymorphic_downcast<>s. > > Another good point against the pImpl idiom. I'd > suggest to overwrite some of the boost libaries that > use the pImpl thing. It is not like a modern C++ at > all. Are you aware that the pImpl idiom is used for many different things or have you just decided its not modern C++ at all because you don't use it for the things you want to do ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote: >> Microsoft has a Windows Template Library, WTL, for >> Windows specifically, >> which is template-based but which they barely >> support for their VC++ users. > > The main point of the proposed library is not a > wrapper. WTL is just a Win32 wrapper. > The main idea is to simplify the use of STL containers > as data sources for UI widgets (in a portable way). > See my ListControl sample in a prev. message. > Also the proposed library will help to organize the > GUI/GDI elements and controlling data structures in a > consistent (with the C++ standard) way using the > 'iterator' paradigm. I understand that. > > It seems to me that in our practicle life, we ended up > with two different worlds in our hands. One is the > nice and clean C++ template world which works great to > program algorithms and data strucures and another one > is the dirty GUI world that we have to use to present > our nice data structures. Most of the time when we try > to bring these two together, the nice structure of C++ > template programming doesn't look so nice anymore. Again I see what you want to do. > > It is a big project but at the end, it should bring > these two worlds together (at least bit). I am not trying to discourage you on working on such a project but the differences in GUI widgets and GDI functionality between operating systems is still very great. As a very simple example, realizing that most examples will be much more complex, items in a listbox may be representable by a std::vector or even a std::map in one operating system but may have much more complex requirements in another OS. Besides the issue of mere representation of the items in the listbox is the way the listbox gets populated with data and the way one reads data from the listbox back into your containers. This also varies from OS to OS. Some OS's use messages to transport data, some use callbacks, some use direct API calls, some use enumerations, some use asynchronous I/O, and there may be other mechanisms for all I know. And this is just a listbox, a very simple widget, and yet you are going to have to write code for this that works for Windows, Linux, Unix flavors, MacIntosh, VMS, OS2, and whatever else OSs Boost supports. Think of more complicated widgets which have been developed like tree views, page controls, list views, track bars, toolbars, edit controls, combo boxes, and many others. On the GDI side there is the drawing of bitmap images, geometrical figures, text, regions, vector images, low-level APIs like OpenGl and DirectX, the list goes on and on. The task is daunting. Add to this the fact that nearly every C++ programmer already works with a framework library depending on his implementation of choice. On Windows alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, and no doubt others about which I have no knowledde, each tied very closely to a particular C++ compiler, IDE, and implementation. While there may well be C++ programmers looking for a cross-platform GUI/GDI from Boost, most programmers are already very comfortable with the framework which comes with their C++ compiler and with the IDE features and tools that make using their "widgets" very easy. Some of these frameworks, hooked to dialog editors or window placement tools, allow the programmer to literally draw or place the widget exactly where it should go and specify both the widget's physical representation and data representation, and even the structures by which the data will be passed from and to the widget. The amount of code which must be written often becomes negligible by the programmer after the design time interfaces have been set up. Yes, the data structures are pretty primitive compared to C++ template containers and whatever other good things you might create, but it will be very hard for most C++ programmers to give up their RAD and RAD-like tools for manipulation of a library entirely by code. Finally many C++ programmers, being the creators that they are, have already invented C++ template-based mechanisms to use on top of the GUI/GDI framework of choice which their compiler and implementation provides. They may be very loath to use another more general template-based framework no matter how good it is. I am not trying to argue you against pursuing your goal but simply trying to point out the difficulties that exist and the barriers against many C++ programmers adopting your implementation as opposed to what they have already been using. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI/GDI template library
E. Gladyshev wrote: > I was thinking about designing a GUI/GDI template > library. > > The main ideas are: > 1. Create a portable template abstraction for standard > GUI/GDI elements and dialog boxes. > 2. Design an "iterator-like" interface. > 3. The most important goal is design a natural > connection between STL containers and GUI elements, so > that STL data can be easily presented in the GUI > environment. Microsoft has a Windows Template Library, WTL, for Windows specifically, which is template-based but which they barely support for their VC++ users. There are other cross-platform frameworks which seek to encapsulate GUI/GDI in classes but few of them are template-based as far as I know. I think you have a big job attempting to create a cross-platform C++ GUI/GDI framework considering the different operating systems which Boost supports and therefore the different GUI/GDI elements on those systems. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Changes with new release
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> "Edward Diener" <[EMAIL PROTECTED]> writes: >>> >>>> David Abrahams wrote: >>>>> "Edward Diener" <[EMAIL PROTECTED]> writes: >>>>> >>>> I am always surprised when programmers, such as yourself in this >>>> instance, react so vehemently to those who suggest that >>>> documentation can be better in any respect. I don't think of >>>> writing documentation as easy, and I am sure my own is as flawed >>>> as much other documentation is, but the merest suggestion to >>>> improve documentation standards for programmers always meets with >>>> a similar response which you have given here. >>> >>> Not from me. I'm always one for better documentation, and you'll >>> note that I instituted just such a changelog for Boost.Python not >>> long ago; it's a good idea. What I was reacting to was the >>> insulting suggestion that library authors who don't publish the >>> ChangeLog you want are poorly educated. >> >> I didn't say that at all and I do not think it is reasonable in any >> way to infer that from my remarks. > > I think: > > "I have never quite understand why so many good, and often > brilliant programmers, take it so hard when others suggest that > they document what they do in easily understandable > sentences. There must be something wrong in the educational > systems of the countries from which most programmers come when > they can not, or do not, want to write clearly." > > speaks for itself. If you meant something else by that remark, > perhaps you'd like to clarify? You have no doubt read something into a general remark which I did not intend. Clearly that was not targeted to "library authors who don't publish the ChangeLog" or I would have been much more specific about it. Nor do I accuse anyone of being poorly educated. I am critical, again in general, about the unwillingness of many programmers to want to communicate their ideas in clear and cogent prose, and about educational systems, in general, that do not feel it is their responsibility to educate students so that basic writing proficiency is met. But that is my right in a free society, to think for myself and have my own opinions and beliefs about those things. I still do not understand the brouhaha which is often caused when someone suggests that things be documented as a help to other programmers. When someone says that an implementation might be improved by changing something in some way, programmers discuss this rationally and reasonably in most cases, usually no matter how assertive people are in their suggestions as long as it remains a technical issue. When someone suggests, let's have better documentation of something, programmers get very defensive in most cases and hostile in some others. It appears to be sacrosanct ground one is treading upon when one seeks to improve things in the programming world by encouraging better documentation, and argues for that improvement even in a low-key way. > >>> This is hardly first time we've been over this >>> ground: >>> >>> http://lists.boost.org/MailArchives/boost/msg38799.php >>> http://lists.boost.org/MailArchives/boost/msg38801.php >>> http://article.gmane.org/gmane.comp.lib.boost.devel/11576 >> >> These are irrelevant to the present post. > > Except that I'll be much more likely to "react vehemently" to posts I > perceive as aggressive if there's a history of similar offensive > behavior behind it. I don't see offensive behavior in those posts. That's not a fair way of criticizing positions with which someone doesn't agree, by calling it offensive. But even if you do really feel it is offensive by your standards, past interpretations of actions should not be used to view judge present situations. We are getting nowhere in this discussion, however, and I don't think we are really disagreeing with each other. I can only attest that my remarks were meant to encourage Boost programmers to better document changes in their libraries so that users could better understand how each new release affects their own programming endeavors with Boost. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Changes with new release
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> "Edward Diener" <[EMAIL PROTECTED]> writes: >>> >> I am always surprised when programmers, such as yourself in this >> instance, react so vehemently to those who suggest that >> documentation can be better in any respect. I don't think of writing >> documentation as easy, and I am sure my own is as flawed as much >> other documentation is, but the merest suggestion to improve >> documentation standards for programmers always meets with a similar >> response which you have given here. > > Not from me. I'm always one for better documentation, and you'll note > that I instituted just such a changelog for Boost.Python not long ago; > it's a good idea. What I was reacting to was the insulting suggestion > that library authors who don't publish the ChangeLog you want are > poorly educated. I didn't say that at all and I do not think it is reasonable in any way to infer that from my remarks. > This is hardly first time we've been over this > ground: > > http://lists.boost.org/MailArchives/boost/msg38799.php > http://lists.boost.org/MailArchives/boost/msg38801.php > http://article.gmane.org/gmane.comp.lib.boost.devel/11576 These are irrelevant to the present post. > >>> It is difficult and time-consuming enough to write coherent >>> user-level documentation as required by Boost that IMO it's >>> unreasonable to demand implmentation documentation at the same >>> level. >> >> All I asked for is that when changes were made between releases to a >> library a small amount of documentation be given which elucidates >> what those changes were in a general way. It would help both users >> of a Boost library and 3rd party developers of a Boost library, as >> it would enable both parties to track general changes and adapt >> their understanding of the library from within their own code to >> those changes. > > That said, I thought you were asking for something else, and I > probably overreacted a bit: I'd been up all night and my nerves were a > bit frayed. OK, I am not out to create more work needlessly for developers and I am not targeting any individual here in my remarks. Encouraging programmers to document what they are doing better shouldn't be something which generates such antipathy simply because many programmers see it as unnecessary and needless effort. I do not know how to explain it better but I think that the ability of programmers to explain their ideas and thinking clearly is of great importance, not only for them but for the users of their software. My remark was just a suggestion, not an attempt to establish a rule. But if it leads to having library implementors documenting the major changes that occur in their library from release to release, I think it will do an important service to the many users of those Boost libraries in the C++ community. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Changes with new release
Gennaro Prota wrote: > On Sun, 20 Jul 2003 17:39:05 -0400, "Edward Diener" > <[EMAIL PROTECTED]> wrote: > >>>> If I were a >>>> library implementor, whether Boost or otherwise, I would want to >>>> explain my ideas to the outside world as a way of promoting good >>>> technology. >>> >>> Ahehm... :-) >> >> An extra 'h' maybe . Or is it just extra phlegm that got stuck in >> your throat when you typed it . > > I'm not sure what you are hinting at, anyway I just felt a little > ridiculous at thinking I was documenting/promoting "good technology". I missed the mark. I meant to write "phleghm", in which I was trying to be linguistically funny and clever about your spelling of 'ahehm' for 'ahem', and at the same time actually make semantic sense. And why would you feel ridiculous that you are promoting good "technology" ? I certainly think that Boost is good technology and I certainly see it as a worthy thing for Boost implementors to promote it through normal non-code methods. Is it too grandiose an idea that Boost is promoting good "technology" ? > > >> Actually I am quite serious with my preceding paragraph. I have >> never quite understand why so many good, and often brilliant >> programmers, take it so hard when others suggest that they document >> what they do in easily understandable sentences. There must be >> something wrong in the educational systems of the countries from >> which most programmers come when they can not, or do not, want to >> write clearly. > > Wow, what an energetic paragraph :-) Honestly, after reading this I > went reading the whole thread (which I didn't before) looking for some > negative answer that could justify your impression, but didn't find > any. I see that Peter, for instance, agrees with the idea. Also, > lexical_cast has a concise and clear summary of the changes. I meant no derogatory remark with that paragraph. It is just that when programmers are asked to document anything outside of the actual code they write they seem to inevitably take offense at it as if the asker has no right to even suggest that they might do that. To me the inability, or unwillingness, to use language to explain one's ideas or communicate what one has done to other people bespeaks a failure in education. > > Of course it's true that many libraries don't have it, and I agree > that it is something users may have a need for, if nothing else to > decide whether upgrading or not. Basically this requires a little > preventive "organization" on the authors' part, because when it's time > to write the change section you are likely to not remember all the > significant changes you have done; and, of course, you don't write the > section _while_ doing the changes, because should they reveal > inadequate you have wasted time both with the code and with the > documentation I think it takes very little time writing down general changes. My original post was not asking developers to write down specific changes but to generalize the major points of difference from one release to the next. Peter Dimov's suggestion that a CVS change log be generated is great, but that is not really what I was suggestion as change documentation. Something more along the lines of: 1) Class such-and-such has changed member function so-and-so to take such-and-such parameter instead of so-and-so parameter. and other items along these lines which may affect end-users. > (this "I don't remember" issue is not a joke... due to > lack of time my changes to dynamic_bitset spans about one year; > fortunately I've noted the rationale for almost everything I've done > because I did know that then Jeremy would have asked me about it, but > people who are the only authors of their library could not do the > same). Also, filtering the "internal" changes from changes that could > interest the user is quite a work too (it also depends on the level of > the user, of course. And you have to make a choice, based on your > personal idea of the inexistent "average" user - in the end you will > probably collect many of these little improvements under a generic > "several bug fixes" entry). It's up to the implementor to specify what has changed and decide what the end-user may want to know. But I really don't see it as overwhelming. > > Summarizing, I agree with you that the work should be done but don't > underestimate it: if you take it seriously it requires time. Everything takes time but I think the time spent for this is worth it. It is the same idea about documenting functionality so that others can use one's programming ideas. It is a worthy thing for an implementor to be willing to communicate one's ideas and make it easier for an end-user to work with those ideas. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Changes with new release
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >>> Not hard, no, but it certainly takes more time than it might appear. >>> FWIW, I've started such a section for dynamic_bitset. The doc file, >>> for now, is in the boost sandbox, subfolder /libs/dynamic_bitset. >> >> I am glad to see you doing that. I still don't understand all the >> pain that many others seem to feel in documenting what they are >> doing. >> >>> >>>> If I were a >>>> library implementor, whether Boost or otherwise, I would want to >>>> explain my ideas to the outside world as a way of promoting good >>>> technology. >>> >>> Ahehm... :-) >> >> An extra 'h' maybe . Or is it just extra phlegm that got stuck in >> your throat when you typed it . >> >> Actually I am quite serious with my preceding paragraph. I have >> never quite understand why so many good, and often brilliant >> programmers, take it so hard when others suggest that they document >> what they do in easily understandable sentences. There must be >> something wrong in the educational systems of the countries from >> which most programmers come when they can not, or do not, want to >> write clearly. Yet many of the Boost implementors do write well when >> they attempt to do so. > > Maybe you should try writing a library as a volunteer sometime and see > what happens to your standards for others' work. I have written a library but not a Boost library ( http://www.tropicsoft.com/Components/RegularExpression ). I am always surprised when programmers, such as yourself in this instance, react so vehemently to those who suggest that documentation can be better in any respect. I don't think of writing documentation as easy, and I am sure my own is as flawed as much other documentation is, but the merest suggestion to improve documentation standards for programmers always meets with a similar response which you have given here. > It is difficult and > time-consuming enough to write coherent user-level documentation as > required by Boost that IMO it's unreasonable to demand implmentation > documentation at the same level. All I asked for is that when changes were made between releases to a library a small amount of documentation be given which elucidates what those changes were in a general way. It would help both users of a Boost library and 3rd party developers of a Boost library, as it would enable both parties to track general changes and adapt their understanding of the library from within their own code to those changes. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Changes with new release
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 doubt can be retrieved through >> CVS in some way, a general explanation of the changes made would be >> enormously helpful to end users and 3rd developers who use Boost >> libraries. > > I like the idea in principle, but perhaps we should use an automated > tool like > > http://www.red-bean.com/cvs2cl/ > > to produce the change log? My only objection to that is not that it will not produce the necessary CVS information, but that it will not produce a good overview of the changes. I would still like to see library implementors explain from an implementors point of view any more general changes in functionality. If this is going to be in a CVS log, perhaps as comments in the source, I think that is fine. But more often than not, I think the CVS log will not show these things, and to have users of Boost libraries poring through CVS change logs to see what actual functionality has changed seems like information at the wrong level for many. The CVS log will be a boon for 3rd party developers who use Boost libraries in their own implementations. Is it really so hard for a library implementor, who has made changes in how his library works between releases, to write a paragraph or a page explaining the change(s) in functionality so that others can see where the library is going and what new or different usage it entails ? If I were a library implementor, whether Boost or otherwise, I would want to explain my ideas to the outside world as a way of promoting good technology. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Changes with new release
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 general explanation of the changes made would be enormously helpful to end users and 3rd developers who use Boost libraries. Of course if no changes are made between releases, or if the changes made are internal and private and do not need to be documentated, no changes will appear in such a log. But if there are significant changes either in functionality or internal design which could affect other developers it would be helpful if these were documented in a regular way. I do realize that many library implementors already do this but I would like to encourage all implementors as a rule to do this when significant changes from one release to another are made, whether this is a major release or a point release like the proposed 1.30.1. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: functors for taking apart std::pair?
Andy Sawyer wrote: > From: Andy Sawyer <[EMAIL PROTECTED]> > To: Boost mailing list <[EMAIL PROTECTED]> > Subject: [boost] Re: functors for taking apart std::pair? > Date: Thu, 10 Jul 2003 22:10:42 +0100 > >>>>>> "ED" == Edward Diener <[EMAIL PROTECTED]> writes: > >> Marshall Clow wrote: > >> I recently had a need for a functor to return a component of a > >> std::pair, and I was surprised to see that they didn't exist > >> either in the standard library or in boost. > >> Matt Austern lists in his excellent book "Generic Programming >> and the STL" the functors select1st and select2nd for getting a >> pair's "first" and "second" members repsectively. His note to >> both says that they were in the original HP STL and in the SGI >> STL although they are not present in the current C++ Standard >> Library. > > Marshall's "first" and "second" are slightly different to the HP > versions: > > template > struct first: std::unary_function< std::pair , T1> > ... > > vs. > > template > struct select1st > : std::unary_function< Pair, typename Pair::first_type> Yes, I see it now. Marshall's version seems a little more redundant since one has to specify both types while the HP version just has one specifying a single pair type. > ... > > The HP version has the advantage of working for "pair-like" pairs > other than std::pair, and (IIRC) it returns a reference to (rather > than a copy of) the selected member. Agreed. > > FWIW, I've found both versions (or their moral equivalent) useful over > the years. > > I think these disappeared from the standard around the same time as > project1st/project2nd? (or at least, didn't make it in at around the > same time :) Yes, Austern's book also mentions project1st and project2nd. I believe one can build an even more flexible function object which returns an object of any type among multiple types using the Boost Tuple implementation. Of course one would have to pass an index to such a function object, which makes it a little more complicated to use than the pair implementations being discussed. Or one could have tuple_select1st... through tuple_selectxxx function objects up to some arbitrary limit. Maybe Jaakko Jarvi can add such a function object to the Tuple library if others find it useful. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost Bibliography?
John Maddock wrote: >> Attached is a quick draft of a "Boost Bibliography" page. Each entry >> is bookmarked so it can be referenced directly from other web pages. >> >> Comments? > > A good idea, can you add to that the article in > libs/type_traits/c++_type_traits.htm which was in the October 2000 > issue of Dr Dobb's Journal, I don't have an issue number to hand > though. Issue #317. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: functors for taking apart std::pair?
Marshall Clow wrote: > I recently had a need for a functor to return a component of a > std::pair, and I was > surprised to see that they didn't exist either in the standard > library or in boost. Matt Austern lists in his excellent book "Generic Programming and the STL" the functors select1st and select2nd for getting a pair's "first" and "second" members repsectively. His note to both says that they were in the original HP STL and in the SGI STL although they are not present in the current C++ Standard Library. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: tokenizer comments
[EMAIL PROTECTED] wrote: >> From: Edward Diener [mailto:[EMAIL PROTECTED] >> >> More than a month ago I posted a correction to the tokenizer >> documentation >> to which no one replied: > > Sorry about that. > >> "The Tokenizer documentation for char_separator tokenizer >> function states >> that the default argument for the second template type is >> "char_traits". This is incorrect. The source code in >> token_functions.hpp clearly shows that the default argument is >> "std::basic_string::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_string::traits_type will always be > std::char_traits. 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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: tokenizer comments
More than a month ago I posted a correction to the tokenizer documentation
to which no one replied:
"The Tokenizer documentation for char_separator tokenizer function states
that the default argument for the second template type is
"char_traits". This is incorrect. The source code in
token_functions.hpp clearly shows that the default argument is
"std::basic_string::traits_type". Could this please be corrected ?"
You obviously have more charm than I do since you received some replies. So
maybe the above can be added to your corrections below of the tokenizer
documentation.
Vladimir Prus wrote:
> I have a few comments regarding the tokenizer library.
>
> 1. The documentation says that char_delimiters_separator is default
> parameter to 'tokenizer' template, and at the same time says that
> 'char_delimiters_separator' is deprecated. I think that's confusing
> and default parameter should be changed to 'char-separator'.
>
> 2. The token interator description is very brief. Specifically, it
> does not say what that iterator is usefull for, or when it's
> preferrable to direct use of tokenizer. The only way to construct the
> iterator is via make_token_iterator function which takes two
> interators as arguments. The meaning of those arguments is not
> documented.
>
> Lastly, the usage example
>
>typedef token_iterator_generator::type Iter;
>Iter beg = make_token_iterator(s.begin(),s.end(),f);
>Iter end = make_token_iterator(s.end(),s.end(),f);
>for(;beg!=end;++beg){
>
> appears to be just longer than tokenizer use:
>
>typedef tokenizer< offset_separator > tok_t;
>tok_t tok(s, f);
>for(tok_t::iterator i = tok.begin(); i != tok.end(): ++i) {
>
> so I *really* wonder what this iterator is for. OTOH, if it could be
> used like:
>
>for(token_iterator< offset_separator > i(s, f), e; i != e; ++i) {
>}
>
> it would be definitely simpler and easier. Is something like this
> possible?
>
> 3. The 'escaped_list_separator' template could have default argument
> for the first parameter, "Char".
>
> 4. I almost always try to use tokenizer when values are separated by
> commas. Believe me or not, I'm always confused as to which tokenizer
> function to use. This time, I read all docs for char_separator and
> only then used escaped_list separator -- which does the work out of
> the box. Maybe, a different name, like "csv_with_escapes_separator"
> or "extended_csv_separator" would help?
> It would make immediately clear what this separator is for.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: PP interest in facilities for variable lengthargumentlists
Josh Dybnis wrote: >>> Is there interest in adding support for variable length >>> argument lists to the preprocessor library. >> >> Not to the Boost library version. At least, not until variadics and >> placemarkers are part of C++. > > But variadics are a part of C. Though this is a bit outside of Boost's > mission, the PP lib is arguably even more useful to C programmers than > it is to C++ programmers. I don't see any harm in targeting C > programmers for this particular library, since they could be an > important user base; as long as it doesn't compromise the library's > usefulness for C++ programmers. The problem is that very few C++ compilers support C variadics. Boost features need a fighting chance to work with the vast majority of C++ compilers and this is done by staying as close as possible to the current C++ standard. C variadics are not part of the current C++ standard. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Managing boost dependencies
Rene Rivera wrote: > [2003-06-10] Edward Diener wrote: > >> Alisdair Meredith wrote: >>> Edward Diener wrote: >>> >>>> I was able to log on to the Boost CVS repository, but I have no >>>> idea >>>> how to display the file structure in WinCVS. Is there a way to do >>>> this or am I supposed to issue CVS commands and look into a command >>>> line window to see what is there ? >>> >>> OK, copy/pasting from the web-site: >>> >>> Type the following into the Admin | Command Line box >>> >>> cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/boost >>> login >>> >>> Now you are logged in. I think this is all you have done so far? >>> >>> Next you must enter the second line, which is a second request to >>> Admin >>>> Command Line (don't worry, this is the same session as before) >>> >>> cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/boost co >>> modulename >>> >>> modulename is the name of the folder on your PC where you want to >>> check >>> out the boost repository to. > > Actually the modulename is "boost", not your local directory. With that information, everything is finally working and I won't bother anyone on this NG anymore with CVS related problems. Thanks to you, Alistair, and Dave for all your help. And now I will read some doc on CVS . ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
Alisdair Meredith wrote: > Edward Diener wrote: > >> I was able to log on to the Boost CVS repository, but I have no idea >> how to display the file structure in WinCVS. Is there a way to do >> this or am I supposed to issue CVS commands and look into a command >> line window to see what is there ? > > OK, copy/pasting from the web-site: > > Type the following into the Admin | Command Line box > > cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/boost login > > Now you are logged in. I think this is all you have done so far? > > Next you must enter the second line, which is a second request to > Admin >> Command Line (don't worry, this is the same session as before) > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/boost co > modulename > > modulename is the name of the folder on your PC where you want to > check > out the boost repository to. Ah, that is where I was fooled. Now I recall that "module" has a special meaning to CVS which I normally don't associate with the term. Is the "folder" a full path or is it just a folder name under the CVS HOME directory ? When I put a full path, I get "can not find module 'c:\MyPath'". Ditto for a folder name under the CVS HOME directory. What an incredible program ! I am sure it works somehow, but it just can't be as hard as I am encountering, or else thousands of programmers wouldn't be using it. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
Alisdair Meredith wrote: > Edward Diener wrote: > >> Do realize that people are different and that my programming >> preference is almost always to use a GUI interface over command >> lines as long as the GUI interface lets me do what I want to >> accomplish. Of course I write actual code in a fancy editor just >> like everyone else ?g?. I will dig into the .pdf version of the link >> first, although my initial reaction to CVS was not joyful, but I am >> sure it can not be that arcane to use. > > I am the same, guess I come from the GUI generation > [Which probably means I learned to write code on Windows] > > I had no problem bringing down the boost libraries through WinCVS > though. I simply copy/pasted the 2 commands given with the > SourceForge > docs into the Admin | Command line box. I don't care so much what > they > did (I can work this out if necessary) but from now on I can > snchronize > with a single click, and never need visit the command line options > again > > As Dave says, I am missing a lot of the power of CVS hiding behind the > GUI, but for now I am not desperately missing those features either. > Maybe if I needed write access? I was able to log on to the Boost CVS repository, but I have no idea how to display the file structure in WinCVS. Is there a way to do this or am I supposed to issue CVS commands and look into a command line window to see what is there ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Managing boost dependencies
Rene Rivera wrote: > [2003-06-09] David Abrahams wrote: > >> "Edward Diener" <[EMAIL PROTECTED]> writes: >> >>> Attempting to use the first command from WinCVS I get: >>> >>> "cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/boost login >>> Logging in to >>> :pserver:[EMAIL PROTECTED]:2401:/cvsroot/boost cvs >>> [login aborted]: Error reading from server cvs.sourceforge.net: 0: >>> No such file or directory" >>> >>> No doubt something else is set up incorrectly, but I have no idea >>> what. >> >> Most likely you just need to do it over and over until you succeed. >> It's being really unreliable for me too. > > Most likely this is the cause: > > ( 2003-05-29 15:41:59 - Known bugs ) As documented in Support Request > 721915, the SourceForge.net team is currently working to resolve > long-term CVS performance issues. Anonymous pserver-based connections > to CVS are currently capped (some connections will be rejected, when > we hit a certain threshold of simultaneous connections systemwide). Thanks, I will try again at some later time. I though it had something to do with my use of WinCVS and CVS . ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
Alisdair Meredith wrote: > Edward Diener wrote: > >> Do realize that people are different and that my programming >> preference is almost always to use a GUI interface over command >> lines as long as the GUI interface lets me do what I want to >> accomplish. Of course I write actual code in a fancy editor just >> like everyone else ?g?. I will dig into the .pdf version of the link >> first, although my initial reaction to CVS was not joyful, but I am >> sure it can not be that arcane to use. > > I am the same, guess I come from the GUI generation > [Which probably means I learned to write code on Windows] > > I had no problem bringing down the boost libraries through WinCVS > though. I simply copy/pasted the 2 commands given with the > SourceForge > docs into the Admin | Command line box. I don't care so much what > they > did (I can work this out if necessary) but from now on I can > snchronize > with a single click, and never need visit the command line options > again > > As Dave says, I am missing a lot of the power of CVS hiding behind the > GUI, but for now I am not desperately missing those features either. > Maybe if I needed write access? Attempting to use the first command from WinCVS I get: "cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/boost login Logging in to :pserver:[EMAIL PROTECTED]:2401:/cvsroot/boost cvs [login aborted]: Error reading from server cvs.sourceforge.net: 0: No such file or directory" No doubt something else is set up incorrectly, but I have no idea what. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Managing boost dependencies
John Maddock wrote: >> Do realize that people are different and that my programming >> preference is almost always to use a GUI interface over command >> lines as long as the GUI interface lets me do what I want to >> accomplish. Of course I write actual code in a fancy editor just >> like everyone else . I will dig into the > .pdf >> version of the link first, although my initial reaction to CVS was >> not joyful, but I am sure it can not be that arcane to use. > > Check out TortoiseCVS: it integrates with the windows shell and is > pretty much wonderful and easy to use. It does lack the power > features of WinCVS > or the command line, but that can sometimes be a good thing. One > caveat however: I've never tried to use it in pserver (read only > access) mode. I don't use Windows Explorer but a 3rd party file management tool, so TortoiseCVS is out. The doc for it was also abysmal, probably because it is too easy to use to need documentation . Thanks anyway ! ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> "Edward Diener" <[EMAIL PROTECTED]> writes: >> I will look at the WinCVS site to see if there are NGs or mailing >> lists that might help me out. > > Suit yourself; I'm trying to suggest that you not waste your time, at > least as first, and instead dig into http://cvsbook.red-bean.com/ Thanks for the link. Do realize that people are different and that my programming preference is almost always to use a GUI interface over command lines as long as the GUI interface lets me do what I want to accomplish. Of course I write actual code in a fancy editor just like everyone else . I will dig into the .pdf version of the link first, although my initial reaction to CVS was not joyful, but I am sure it can not be that arcane to use. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> How does one get the latest Boost CVS source ? I have WinCVS but >> have never been able to figure out how to use it to get CVS source >> on the Internet anywhere. Would anyone like to run me through it ? I >> know it has something to do with server access but I am dumbfounded >> by the WinCVS doc, > > The easiest and most reliable way to use CVS to get the Boost CVS > sources is to use the cvs command-line tool (a cvs.exe is part of your > WinCVS installation) and to simply follow verbatim the instructions > for anonymous CVS access at: > >http://sourceforge.net/cvs/?group_id=7586 > > Using "boost" for the modulename. It's only two lines you need to > type. OK, thanks ! Those two lines should get me started. > > I know WinCVS is supposed to make things easier, but for many jobs it > really doesn't - you have to figure out how the instructions everyone > else uses can be translated into equivalent checkboxes and menu items > in WinCVS, and eventually you need to understand how the command-line > works because the abstraction layer provided by WinCVS always "leaks" > the underlying implementation details. I will use the command lines above but I am still thinking that there must be a way to do things via WinCVS which allows me to access Boost CVS from within WinCVS's GUI environment. I will look at the WinCVS site to see if there are NGs or mailing lists that might help me out. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
Bravo, John ! I have been hoping someone would come up with a way by which developers could figure out fairly easily what part of Boost might need to be distributed if only a single or a few Boost libraries were being used. John Maddock wrote: > Folks, > > I've put together a small tool for managing boost dependencies called > bcp (for boost copy). > > The bcp utility is a tool for extracting subsets of Boost, it's > useful for Boost authors who want to distribute their library > separately from Boost, > and for Boost users who want to distribute a subset of Boost with > their application. > > Examples: > ~~~ > >bcp scoped_ptr /foo > > Copies boost/scoped_ptr.hpp and dependencies to /foo. > >bcp boost/regex.hpp /foo > > Copies boost/regex.hpp and all dependencies > including the regex source code (in libs/regex/src) and build files > (in libs/regex/build) to /foo. Does not copy the regex > documentation, test, or example code. > >bcp regex /foo > > Copies the full regex lib (in libs/regex) including > dependencies (such as the boost.test source required by the regex test > programs) to /foo. > >bcp regex config build /foo > > Copies the full regex lib (in libs/regex) plus > the config lib (libs/config) and the build system (tools/build) to > /foo including all the dependencies. > > Syntax: > ~ > >bcp --list [options] module-list > > Outputs a list of all the files in > module-list including dependencies. > >bcp [options] module-list output-path > > Copies all the files found in > module-list to output-path > > Options: > ~~ > >--boost=path > > Sets the location of the boost tree to path. > >--scan > > Treats the module list as a list of (probably non-boost) files to scan > for boost dependencies, the files listed in the module list are not > copied (or listed), only the boost files upon which they depend. > >--cvs > > Only copy files under cvs version control. > >--unix-lines > > Make sure that all copied files use Unix style line endings. > > module-list: > > > When the --scan option is not used then a list of boost files or > library names to copy, this can be: > > 1.. The name of a tool: for example "build" will find "tools/build". > 2.. The name of a library: for example "regex". > 3.. The title of a header: for example "scoped_ptr" will find > "boost/scoped_ptr.hpp". What does this mean, the "title" of a header ? > 4.. The name of a header: for example "scoped_ptr.hpp" will find > "boost/scoped_ptr.hpp". Difference between 3 and 4 ? > 5.. The name of a file: for example "boost/regex.hpp". > > When the --scan option is used, then a list of (probably non-boost) > files to scan for boost dependencies, the files in the module list > are not therefore copied/listed. > > output-path: > > > The path to which files will be copied (this path must exist). > > Dependencies > > File dependencies are found as follows: > > C++ source files are scanned for #includes, all #includes present in > the boost source tree will then be scanned for their dependencies and > so on. > > C++ source files are associated with the name of a library, if that > library has source code (and possibly build data), then include that > source in the dependencies. > > C++ source files are checked for dependencies on Boost.test (for > example to see if they use cpp_main as an entry point). > > HTML files are scanned for immediate dependencies (images and style > sheets, but not links). > > ~ > > As usual comments etc are most welcome, also should a utility/tool > such as this go through the review process, before eventually living > under > tools/bcp? > > The source is available from: www.regex.fsnet.co.uk/bcp.zip > > This requires the latest boost cvs source to build, so there is also > a file containing bcp's dependencies (obviously produced using bcp!): > www.regex.fsnet.co.uk/bcp_deps.zip How does one get the latest Boost CVS source ? I have WinCVS but have never been able to figure out how to use it to get CVS source on the Internet anywhere. Would anyone like to run me through it ? I know it has something to do with server access but I am dumbfounded by the WinCVS doc, ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Better Intel-Win32 support
John Maddock wrote: >> That will certainly work, but you shouldn't have to do that since the >> compiler itself defines _WCHAR_T_DEFINED. Since I made the fix >> earlier > this >> afternoon I am able to compile some non-boost code correctly which >> had previously be failing. > > Just let me jump in here: you absolutely can not use _WCHAR_T_DEFINED > to detect native wchar_t support: the windows headers will define > this when wchar_t has been defined as a typedef (and wchar_t is not a > native type). There appears to be no way to actually tell whether > wchar_t is a native type or not with Intel. > > One other point: turning wchar_t support on may cause linker errors > because you have now changed the name mangling of functions that take > wchar_t as an argument - I don't know for sure but I would expect > this to affect the std lib. I don't know about Intel-Win32 but I brought much of this up regarding MSVC 7.0+ and most everybody yawned. I am glad that some people have woken up to the fact that there is a problem using wide characters with compilers which support both the native C++ wide character and a previous typedef for wchar_t. A disappointing aspect of this in regards to MSVC 7.0+ is that there is no preprocessor macro ( as of 7.0, I haven't checked 7.1 yet ) which MSVC defines for distinguishing native C++ wide character from the previous typedef for wchar_t. And as you have said, serious linker errors will occur for Boost libraries with wide character usage if they are built for one or the other version of wide character and the end-user sets the opposite version of wide character in their Makes or projects. Although this is not a C++ problem or a Boost code problem directly, but rather an implementation problem affecting a wide base of programmers, I think Boost needs a clear strategy for dealing with it for any Boost library built with wide character support and that all such libraries conform to that strategy. Of course it's a PITA, and of course MS brought it on themselves by supporting a non-C++ version of wchar_t for many years ( and I am guessing that Intel, in order to be a plug-in for VC++ followed suit ), but it still needs to be dealt with in some logical manner. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Better Intel-Win32 support
Randy Bowen wrote: >> A disappointing aspect of this in regards to MSVC 7.0+ is >> that there is no preprocessor macro ( as of 7.0, I haven't >> checked 7.1 yet ) which MSVC defines for distinguishing >> native C++ wide character from the previous typedef for >> wchar_t. > > The MS-specific macro _NATIVE_WCHAR_T_DEFINED indicates the presence > of > the native type in MSVC 7.0+. However, use of this can cause a number > of problems with existing MS libraries (and especially anything that > deals with COM). The documentation is very confusing regarding this. First we have under Predefined Macros: "_WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED Defined when wchar_t is defined. Typically, wchar_t is defined when you use /Zc:wchar_t or when typedef unsigned short wchar_t; is executed in code." which implies that both the macros above are defined in both cases. Next we have under the compiler switch "/Zc:wchar_t (wchar_t Is Native Type)": "When /Zc:wchar_t is specified, _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED symbols are defined; see Predefined Macros for more information." which simply reiterates the first part of the previous topic. Testing this out, both VC++ 7.0 and VC++ 7.1 yield the same result which confirms what you have written above. When the /Zc:wchar_t switch is used, both of the above macros are defined. When the /Zc:wchar_t is not used, only the _WCHAR_T_DEFINED macro is defined. So I was definitely wrong in thinking that there was no way to test for the difference. Perhaps the previous documentation which I read didn't explain the _NATIVE_WCHAR_T_DEFINED macro or perhaps I just missed it. But this is good for Boost. Now there is a way to determine whether which of the wchar_t types in VC++ are being used at compile time. My suggestion for Boost is that it use library implementors use this in order to alert the end-user at compile time that a particular usage of wchar_t is not supported, or use it to correctly link in the correct version of the library when both are supported. For VC++, the #pragma comment(lib,"SomeLib") specifies the name of the library to link, either import or static. I know John Maddock does this in Regex++ but the general usage for our wchar_t, reiterated here, would be: #if defined(_NATIVE_WCHAR_T_DEFINED) #pragma comment(lib,"NativeWchartVersion.lib" #elif defined(_WCHAR_T_DEFINED) #pragma comment(lib,"VCWchartVersion.lib") #endif Of course I expect Boost may want to create BOOST_ macros for these VC++ specific macros in the correct configuration file and use them instead, but one gets the general idea from this. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Upcoming ISO/IEC ... and -> transition ;-)
Alexander Terekhov wrote: > Hardcore POSIX folks don't really "think C++", unfortunately. The only > way to get it done is to deliver POSIX threading API implementation > "on > top" of Boost.Threads to them, I think. Well, this would also mean a > whole bunch of extensions to the current POSIX threading -- things > like parameterized pthread_once() and TSD destructors (to support > shared_ptr > like "custom deleters" without too much overhead), etcetera. > > What do you think? What I think is that it is about time that C++ stop trying to accomodate the C programming language in any respect, and develop itself using C++ idioms and ideas even if it means leaving the C language completely behind. This is what Boost is currently doing and I see attempts to accomodate C as crippling the vitality of C++ and blocking the attempt to create a more dynamic C++ language for the future. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: ENFORCE
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >>> I browsed the article (I confess to not having read everything, so >>> please correct any misapprehensions). My sense is that the >>> technique >>> is oriented towards detecting programmer errors and responding via >>> an exception. >> >> I don't think ENFORCE is oriented toward that at all. There's no >> orientation involved other than to throw an exception based on a >> condition. I agree with you that direct programming errors should >> generally not throw exceptions but should ASSERT so that the >> programmer can fix the error. However I don't think ENFORCE has >> anything to do with this debate about when to ASSERT and when to >> throw exceptions. Perhaps the examples give the impression which you >> have > > I think so. > >> but I think the problem is just choosing better examples in which >> one would want to throw an exception and not a technical issue as to >> the benefits of using ENFORCE in order to simplify exception >> throwing. > > Can you show me a better example? This is not a challenge. Really, > if this ENFORCE idea is a useful one I want to understand it. A typical example might be a 3rd party library in which an end-user passes a std::string, call it "s", which must contain some valid data and not be empty. In this case I would throw an exception since it is not my error but my end-user's error. Say my exception, derived from std::runtime_error is eSomeEmptyString. I could then write: Enforce(!s.empty(),"My Message"); To me this is a nice shorthand notation for throwing an exception when the "s" string is empty, ie. contains no data. I believe Mr. Alexandrescu developed Enforce as a nice way of regularizing the code when an exception must be thrown based on a condition. The code becomes more readable and easier to understand. For me such constructs, although not revolutionary in and of themselves, are important in making cleaner and more understandable coding and I appreciate Mr. Alexandrescu's efforts in such an area. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ENFORCE
David Abrahams wrote: > "Andrei Alexandrescu" <[EMAIL PROTECTED]> writes: > >> By the way, I believe what would be more interesting for Boost is the >> recent article (http://www.cuj.com/experts/2106/alexandr.htm), >> written by Petru Marginean and myself. (Warning - the article has >> recently been >> updated.) >> >> We have good experience in reducing source code size by using >> enforcements. There are a number of interesting techniques used out >> there, and I believe ENFORCE would be quite useful as a Boost >> library. > > I browsed the article (I confess to not having read everything, so > please correct any misapprehensions). My sense is that the technique > is oriented towards detecting programmer errors and responding via an > exception. I don't think ENFORCE is oriented toward that at all. There's no orientation involved other than to throw an exception based on a condition. I agree with you that direct programming errors should generally not throw exceptions but should ASSERT so that the programmer can fix the error. However I don't think ENFORCE has anything to do with this debate about when to ASSERT and when to throw exceptions. Perhaps the examples give the impression which you have, but I think the problem is just choosing better examples in which one would want to throw an exception and not a technical issue as to the benefits of using ENFORCE in order to simplify exception throwing. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Oughtn't filesystem::path acc ept the"*"and"?" wildcards?
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> I still feel that a fixed width Unicode encoding has to be an >> advance over variable width encodings like MBCS for any character >> set. > > I guess that depends on how important random access over the > characters of a string is to you. To me, it seems like an edge case. Random access means that the algorithms for string manipulation and comparison are much easier and faster with fixed width encoding. It's the tradeoff of size vs. speed again, with speed this time also meaning much easier and clearer code. I'll go for the latter. I realize that variable width encodings can save space, but it hardly seems worthwhile to me given the algorithmic downside and complexity of the former. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Oughtn't filesystem::path acc ept the "*"and"?" wildcards?
Beman Dawes wrote: > At 09:03 PM 4/21/2003, Edward Diener wrote: > > >Beman Dawes wrote: > >> ... > >> Once the portable case is handled, then I'm willing to see if > native >> format paths with wild-cards can be accommodated. But > solving the >> portable case seems to me to be most important. > > > >I can see the theoretical importance of a portable regex-based > filter but >the practical importance of providing non-portable > filters for specific > OSs > >in the filesystem library. > > Well, if you think it is that important, why don't you try to come up > with > a specific proposed solution? That's much more likely to result in > action than just urging other people to do the work. The solution > would have to > have a portable grammar, plus at least the Windows and POSIX wild-card > grammars. There would have to be specification of which functions > support wild cards, and a bunch of portable, Windows, and POSIX test > cases. My proposed solution for native Windows wildcards is that "*" and "?" only be supported, and that the Windows API FindFirstFile(Ex)/FindNextFile be used to do the filtering. Other native solutions are best left to experts in other OSs. If I think of something good for a portable wildcard solution, I will be glad to convey it on this NG. Finally I am not urging others to do the work, I am just making suggestions. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Oughtn't filesystem::path acc ept the "*"and"?" wildcards?
Beman Dawes wrote: > At 09:03 PM 4/21/2003, Edward Diener wrote: > > >Beman Dawes wrote: > > I do > >not believe that C++ should attempt to legislate what wide > characters go >into a wide character file name as different locales > will have their own >idea of what constitutes a valid wide character > name. > > Operating system and program interoperability requirements drive the > character validity, encoding, and conversion specifications. That > doesn't leave much room for either the C++ standard or user supplied > specifications. For example, if an operating system function rejects > a > path as being invalid, there is nothing either the C++ standard or > the user can do about it. All the more reason to allow wide character file names to be implementation and OS dependent and not attempt to legislate what a wide character file name is, other than a serquence of wide characters. Current C++ standard says practically nothing about what the characters of a narrow character filename should be in the ifstream and ofstream classes. That doesn't mean I am against your attempt to include wide character filenames in your filesystem library, only that the decision as to what are legitimate wchar_t s should be as wide as possible ( pardon the pun ). > > > Neverthless I am > >willing to be wrong about this as long as the C++ standards commitee > >realizes that it is important to add to the C++ standard library > wide >character filename support of some kind, so that cultures > whose normal >language encoding is a wide character one can use the > C++ standard > library > >to specify wide character names for their I/O functionality on OSs > which >support wide character filenames. > > Remember that the C++ committee includes active long-time members from > Japan, and that as one of the ten or twelve voting delegations to the > WG21 ISO portion of the committee, their views carry a great deal of > weight. > Even if everyone else is asleep, the Japanese delegation will politely > remind us of the importance of internationalization, and particularly > character-width, issues. I am happy to hear about that, the work you and others are doing to bring wide character filenames to C++, and the work you are doing to bring it to the filesystem library. When I argued about this on comp.std.c++ I got the distinct impression, from people such as Mr. Plauger and Mr. Kanze, that the C++ committee was trying its best not to feel it necessary to add wide characters filenames to the C++ standard library functionality. I felt, and feel, this is a mistake. Bringing in the entire international community, and making it possible that the C++ standard library will support their character sets, is of utmost importance for the health and growth of the language. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Oughtn't filesystem::path acc ept the "*"and"?" wildcards?
Beman Dawes wrote: > At 09:35 PM 4/22/2003, David Abrahams wrote: > >Beman Dawes <[EMAIL PROTECTED]> writes: > > > >> Remember that the C++ committee includes active long-time members > from >> Japan, and that as one of the ten or twelve voting > delegations to the >> WG21 ISO portion of the committee, their views > carry a great deal of >> weight. Even if everyone else is asleep, > the Japanese delegation will >> politely remind us of the importance > of internationalization, and >> particularly character-width, issues. > > > >On the other hand, everyone I've spoken to who's had to do serious > >internationalization for Japanese environments has said that Unicode > >was ultimately useless for them -- what they really needed was to be > >able to deal with the various variable-length encoding schemes that > >have evolved there over the years. > > I think what they mean is that the UTF-32 or UTF-16 encodings are > useless > to them as an external encoding of Unicode. Rather, they need UTF-8, > shift-JIS, or other MBCS external encodings of Unicode. > > That doesn't mean that UTF-32 or UTF-16 Unicode encodings are useless > as internal program data types. In fact, the main complaint about > wchar_t is that it doesn't handle UTF-32 or UTF-16 reliably. I'm > under the impression that Mori, the author of the C language Unicode > TR proposal which is > supposed to remedy that, is from Japan and that his proposal has wide > support there. My offhand guess, from my own small experience in dealing with internationalization issues for a program which had to run in Japan, is that MBCS and other non-Unicode encodings were used in Japanese programming for many years before Unicode encodings like UTF-16 and UTF-32 became a reality. Now with Unicode able to handle the various Japanese ideographic sets, the Japanese themselves do not want to move to Unicode encodings in their programs as they have become so used to identifying their previous encodings. But I am no expert in this area and I am sure others have the definitive reason why UTF-16 and UTF-32 are useless as external encodings. I still feel that a fixed width Unicode encoding has to be an advance over variable width encodings like MBCS for any character set. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Oughtn't filesystem::path acc ept the "*" and "?" wildcards?
Beman Dawes wrote: > At 02:17 PM 4/20/2003, Edward Diener wrote: > >Beman Dawes wrote: > >> At 08:22 AM 4/9/2003, Christian Engström wrote: > >> > >> >In my application I need to handle paths that contain wildcards, > >> such as >for example "foo/chapter?.txt" or "bar/*/index.html". > >> > >> I think that your need is both valid and commonplace, but that the > >> way to handle it isn't necessarily to modify the filesystem > library. >> > >> Rather, think about using a filter iterator. See > >> www.boost.org/libs/utility/filter_iterator.htm > >> > >> There are a couple of caveats: (1) I haven't actually tried it, so > >> don't > >> know if it is a practical solution, and (2) Dave, Jeremy, and > Thomas >> are working on a major update to iterator adaptors so > details may >> change once they are done. > > > >What good is a filter iterator adaptor supposed to accomplish in > this >situation ? > > The idea is that rather than directory iteration returning iterators > for > all path entries, it would only return those which passed a predicate > which was driven by the pattern. For some uses, the pattern might > more flexibly > be a regular expression rather than the traditional (but non-portable) > wildcard patterns provided by various operating systems. Yes, that would work but would consume extra time when done from the end-users point of view rather than the implementors. First one has the usual directory iterator returning all files, then one filters it for the files one wants. At the native API level, admittedly non-portable, functions already exist to filter the entries based on wildcard patterns as the OS searches the disk directory. Finally trying to filter an already existing file list can be far more difficult than letting the OS use its built-in heuristics and understanding of wildcards to automatically do it for you. Don't get me wrong, iterator adaptors are great and the filter adaptor is a great example of using it, but in this case it is probably not what an end-user wants. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Oughtn't filesystem::path acc ept the "*" and "?"wildcards?
Beman Dawes wrote: > At 08:22 AM 4/9/2003, Christian Engström wrote: > > >In my application I need to handle paths that contain wildcards, > such as >for example "foo/chapter?.txt" or "bar/*/index.html". > > I think that your need is both valid and commonplace, but that the > way to handle it isn't necessarily to modify the filesystem library. > > Rather, think about using a filter iterator. See > www.boost.org/libs/utility/filter_iterator.htm > > There are a couple of caveats: (1) I haven't actually tried it, so > don't > know if it is a practical solution, and (2) Dave, Jeremy, and Thomas > are working on a major update to iterator adaptors so details may > change once they are done. What good is a filter iterator adaptor supposed to accomplish in this situation ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Threads Lib and DLL Issues
David Brownell wrote: > While this will work (although it is discouraged in the documentation > of redist.txt), my preference is to ship only one DLL (the thread > dll) and my exe. Anyone know how to tweak bjam to do this? I would be wary of any code which has both static and dynamic versions of RTL routines in different modules. I can't say for sure why this mix seems to cause problems, but personally I go with either all static or all dynamic solutions. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Thread Lib and DLL
David Abrahams wrote: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >> Russell Hind said: >>> I'd been wondering this, and heard about TLS issues. The issues are >>> only on Windows it appears. Search for the thread >>> >>> "Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on >>> 18/02/2003 >>> >>> Specifically, the many posts by William Kempf and Edward Diener >>> discuss the problems on windows with TLS cleanup. >>> >>> I do have a question on this issue: If this problem is only to do >>> with TLS cleanup when a thread exits, then if all threads are >>> created when the program starts and only destroyed when the program >>> exited, then, in practice, could this really be an issue? I.e. if >>> we only work like this, could building thread as a static lib cause >>> problems providing that we don't let threads exit in the middle of >>> the program? We're currently really trying to stay clear of any >>> DLLs. >> >> Theoretically at least, I don't see why this would cause a problem. >> You intentionally leak, but the leak is benign since it occurs only >> right before the application exits. But most users won't code this >> way, nor do I want to have to deal with the support >> requests/questions this would cause. So, unless you have some >> suggestion as to how I can enable this usage with out causing >> confusion, I'm not sure I'd care to re-enable static builds. But >> you could probably fairly easily hack things to build that way >> yourself. > > I don't really understand the issues here, but I was wondering if you > could reclaim "leaked" TLS resources lazily somehow, by looking for > unused TLS the next time new TLS is requested. Just a thought... The problem lies in the fact that the TLS API only gives one access to the storage slot for the thread which is being executed. One does not use any "tag", or identify the thread in any way, when gaining access to a storage slot for a particular thread. Therefore it is not possible using the Windows TLS API to gain access to the storage slot for another thread other than the one currently executing. Of course one might be able to roll's one own thread local storage implementation, probably using std::map<> to map a thread-id against storage areas for a particular thread, etc. etc. which would allow one to gain access to another thread's storage areas for thread specific data in order to do lazy reclamation, but one would have to do a good bit of work in order to accomplish what TLS automatically gives you. Also, of course, one's own implementation of TLS would not be compatible with the end-user's normal thread-local storage if that matters. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> Terje Slettebø wrote: >>>> From: "Rozental, Gennadiy" <[EMAIL PROTECTED]> >>> >>>>> Even if none of the above looks sound for you I still argue that >>>>> lexical_cast *should not force* inclusion of typeinfo. It's not >>>>> "inconvinience" - it's showstopper. It's much more important >>>>> than providing >>>>> specific type info. In majority of the cases one knows it anyway. >>>>> >>>>>> Kevlin >>>>> >>>>> Gennadiy. >>>> >>>> So. Are we gonna stuck with typeinfo in lexical_cast? >>>> >>>> Could we have at least some discussion about this? >>> >>> I'd certainly be open to make the type_info part optional. A >>> question >>> is how to do it. >> >> Type_info is part of the C++ standard. I don't understand the >> turning off of this in C++ code, but even it is done for an >> implementation, I don't think that Boost should now have to worry >> about not supporting it in a library because end-users can turn it >> off. Should Boost stop using exceptions in order to accomodate those >> who can turn off exception handling in their C++ implementations as >> some implementations allow ? > > > There's some precedent for it. grep for BOOST_NO_EXCEPTIONS. I didn't even realize that Boost catered to it although I should have since I have dealt with Regex++ enough. OK, if you allow end-users to build parts of Boost without exception handling, I guess you can allow end-users to build parts of Boost without RTTI support. I admit that if I were a Boost library implementor, I would find such limitations on my natural use of C++ annoying. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
Terje Slettebø wrote: >> From: "Rozental, Gennadiy" <[EMAIL PROTECTED]> > >>> Even if none of the above looks sound for you I still argue that >>> lexical_cast *should not force* inclusion of typeinfo. It's not >>> "inconvinience" - it's showstopper. It's much more important >>> than providing >>> specific type info. In majority of the cases one knows it anyway. >>> Kevlin >>> >>> Gennadiy. >> >> So. Are we gonna stuck with typeinfo in lexical_cast? >> >> Could we have at least some discussion about this? > > I'd certainly be open to make the type_info part optional. A question > is how to do it. Type_info is part of the C++ standard. I don't understand the turning off of this in C++ code, but even it is done for an implementation, I don't think that Boost should now have to worry about not supporting it in a library because end-users can turn it off. Should Boost stop using exceptions in order to accomodate those who can turn off exception handling in their C++ implementations as some implementations allow ? The same goes for any other part of the C++ standard. It's the end-users problem if they turn off something in their implementations, and then can't use it, which is part of the C++ standard. OTOH I do understand completely the great effort Boost has made to accomodate implementations which just don't support some area of the C++ standard completely. But I view the two issues as completely separate. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Thread Lib and DLL
William E. Kempf wrote: > Edward Diener said: >> William E. Kempf wrote: >>> David Brownell said: >>>> I am curious as to why the new version of the Thread library does >>>> not provide a static library in the 1.30 version of boost. After >>>> reading some initial posts, I have seen references to thread local >>>> storage, but haven't seen anything that documents why this makes a >>>> static library impossible. All thing considered, I find a static >>>> library is much more desirable than a dll. >>> >>> It has been discussed numerous times on this list, as well as on the >>> Users list. TLS cleanup can only be done on the Win32 platform with >>> code in the thread itself (which won't work for threads created >>> outside of Boost.Threads) or with code in DllMain. >> >> A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a >> member function call in the thread class which should only be used >> for those who are using a static library version of the library. The >> member function must be called before the thread function exits in >> the static library version. For the DLL version, the member function >> must be ignored or you can simply not have the member function call >> in the DLL version. The onus would be on those using the static >> library version to always make this call before their thread >> function exits, but would at least provide them wioth the >> possibility of using a static library version. Of course there may >> be other >> ramifications which cause this idea not to work, or even getting it >> to work properly would be too much trouble, but I thought I would >> suggest it anyway. > > Workable, if the user makes absolute certain he calls this method from > every thread that accesses TLS. However, he may not know this, for > example when a library function uses Boost.Threads internally and > allocates TLS with out the user knowing. The user can just call the method for every thread which uses Boost.Threads in a static library implementation. If a library ( LIB ) function uses Boost.Threads internally, then it is up to the library function implementor to document this and iteratively define a function which can be called which calls the Boost.Threads function before the thread ends or, if the library function itself controls the ending of the thread, it must do it itself. > This is just a variation on > the "you must use this thread creation routine if you use our > libraries" solution that MS uses for the C RTL and MFC. I think it's > fragile... and many users fail to understand the issues here and thus > do the wrong thing. I don't doubt its general fragility as far as the end-user goes but if it enables an end-user to use Boost.Threads in a static LIB version, it may be still justifiable for them. It is easy enough to explain to the end-user that because Boost.Threads can not track when the thread ends in a static LIB, as it can automatically do in a DLL, the end-user must do the "manual" tracking by notifying Boost.Threads about the thread ending via the function. There is hardly an end-user involved with Windows DLLs who does not know about the attaching and unattaching of processes and threads which runs through DllMain. It would be completely understandable to offer the more difficult to use static LIB version with an explanation of why this notification must be done manually for the static LIB as opposed to the DLL. > >> It may not be worth thinking about possible solutions of building a >> static library version of Boost.Threads. I know that for myself I >> always creates DLLs when distributing applications but as a 3rd >> party developer I always leave open the possibility that there are >> people who like to distribute the applications as a single EXE which >> uses static libraries and the static library version of their >> compiler's RTL. > > Yes, and for that reason I certainly dislike the DLL only packaging of > Boost.Threads. But it seems the safest and most viable solution. Well, it is up to you. As I say, I generally never use static LIB versions in my own application software. However, if I distribute 3rd party components I feel bound to be able to distribute versions as both a DLL and a static LIB whenever it is functionally possible to do so. So if I were a 3rd party developer who was using Boost.Threads for my own implementation of something, I might not want to do so because the proposed static LIB version of my own software could not use a static LIB version of Boost.Threads. Although I could theoretically use the DLL version of Boost.Threads in the static LIB version of my own software, I
[boost] Re: Thread Lib and DLL
William E. Kempf wrote: > David Brownell said: >> I am curious as to why the new version of the Thread library does not >> provide a static library in the 1.30 version of boost. After reading >> some initial posts, I have seen references to thread local storage, >> but haven't seen anything that documents why this makes a static >> library impossible. All thing considered, I find a static library is >> much more desirable than a dll. > > It has been discussed numerous times on this list, as well as on the > Users list. TLS cleanup can only be done on the Win32 platform with > code in the thread itself (which won't work for threads created > outside of Boost.Threads) or with code in DllMain. A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a member function call in the thread class which should only be used for those who are using a static library version of the library. The member function must be called before the thread function exits in the static library version. For the DLL version, the member function must be ignored or you can simply not have the member function call in the DLL version. The onus would be on those using the static library version to always make this call before their thread function exits, but would at least provide them wioth the possibility of using a static library version. Of course there may be other ramifications which cause this idea not to work, or even getting it to work properly would be too much trouble, but I thought I would suggest it anyway. It may not be worth thinking about possible solutions of building a static library version of Boost.Threads. I know that for myself I always creates DLLs when distributing applications but as a 3rd party developer I always leave open the possibility that there are people who like to distribute the applications as a single EXE which uses static libraries and the static library version of their compiler's RTL. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: boost::optional feature request.
Rozental, Gennadiy wrote: >> Therefore to justify >> boost::optional as a key in an associative container, as >> opposed to its >> direct type, I believe one has to justify a situation where >> the "non-actual" >> value is really being used as a key. > > Let say I have mapping of state to action. Now I want to support the > case where current state is undefined. So I am using optional > as a key. Does this example fit for the situation? It fits the situation. A good example. OK, I'm sold. My imagination on this was too limited. I can see where one can use the undefined value along with a number of defined values as keys in containers or as values in a sorted container, both needing the operator < . I assume that operator < would of course have undefined values always false when compared against another undefined value as being <. The decision that needs to be made is how an undefined value compares against defined values. Is the undefined value always < all defined values, or is the undefined value always > all defined values, or is it user decided via some boolean switch. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: boost::optional feature request.
David Abrahams wrote: > "Edward Diener" <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> Douglas Paul Gregor <[EMAIL PROTECTED]> writes: >>> >>>> On Mon, 24 Mar 2003, Edward Diener wrote: >>>> >>>>> Do you really want the key to an associative container to be an >>>>> optional value ? I would be hard-pressed to find a use for that. >>>> >>>> FWIW, the Signals library actually does this internally (although >>>> with boost::any objects instead of boost::optional objects). >>>> However, I would contend that the need is too specialized to >>>> warrant adding an operator<. >>> >>> Seems entirely reasonable to me to add it. It looks like at least >>> two people have needed exactly those semantics. What's the cost? >> >> I am not trying to shoot down the request but could someone give me a >> practical example of the case where an optional value which does not >> exist ( I hope that's the right term for when an optional value has >> no valid value ) serves as a key in an associative container ? > > I guess you can look at how boost::any is used in the signals library > for an example. The boost::any idea is not the same as boost::optional. The main difference, as I understand it, is that boost::optional is able to present a "non-actual" value for a type in a way that makes it easy to check. My whole point is that boost::any contains "actual" values, making its use as a key in an associative container very reasonable, while boost::optional's main purpose is to present the normal range of "actual" values along with a "non-actual" value and the "non-actual" value possibility is the reason for using boost::optional as opposed to the direct type. Therefore to justify boost::optional as a key in an associative container, as opposed to its direct type, I believe one has to justify a situation where the "non-actual" value is really being used as a key. My reading of boost::optional shows good examples where it could be used, all to be able to check whether a "non-actual" value could exist, but I can't understand how being a key in an associative container could be one of them. Or is the justification something like, 'I am using a bunch of optionals in other ways to check for a "non-actual" value and want to be able to use my results as a key in an associative container without having to extract the actual values' ? While that is possible, it must be very rare indeed, especially as the actual values can be extracted rather than boost::optional with a minimum of extra code. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: boost::optional feature request.
David Abrahams wrote: > Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > >> On Mon, 24 Mar 2003, Edward Diener wrote: >> >>> Do you really want the key to an associative container to be an >>> optional value ? I would be hard-pressed to find a use for that. >> >> FWIW, the Signals library actually does this internally (although >> with boost::any objects instead of boost::optional objects). >> However, I would contend that the need is too specialized to warrant >> adding an operator<. > > Seems entirely reasonable to me to add it. It looks like at least two > people have needed exactly those semantics. What's the cost? I am not trying to shoot down the request but could someone give me a practical example of the case where an optional value which does not exist ( I hope that's the right term for when an optional value has no valid value ) serves as a key in an associative container ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::optional feature request.
Do you really want the key to an associative container to be an optional value ? I would be hard-pressed to find a use for that. Joe Gottman wrote: >It would be nice if boost::optional had operator< defined > whenever operator< was defined for T. This would allow us to use > optional as the key of an associative container. I suggest the > following semantics: > > bool operator<(optional const &x, optional const &y); > > Returns: If y is uninitialized, false. If y is initialized and x is > uninitialized, true. If x and y are both initialized, (*x < *y). > > > >This results in a strict weak ordering with uninitialized > optional objects being sorted first. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 release postmortem
Beman Dawes wrote: > In many ways the preparation Boost 1.30.0 went very well, and the > resulting release seems very high quality to me. > > There were rough edges of course, and we'll try to make some > improvements > in coming months. Mostly just procedural stuff like making sure we > have an active maintainer for all libraries, and getting maintainers > to make major changes earlier in the process. > > The worst problem seems to me to be that our bug and patch tracking is > totally dysfunctional. I would like to add an idea that I have mentioned in the past; which is that each library have some documentation on the changes made from release to release, at least on the order of major things happening such as features being added or changed or deleted, so that the end user has some idea of what is different in the new release for that library. I find the idea that such documentation does not exist really disturbing. I believe library implementors have to take responsibility for such documentation although I imagine a patch tracking system would help. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost MPL problem
The help gives:
"
recursive type or function dependency context too complex
A template definition was recursive or exceeded complexity limits. For
example:
template class Factorial : public Factorial
{
public:
operator int ()
{
return Factorial ::operator int () * n;
}
};
Factorial<7> facSeven; // error on this line"
In the example above there is no specialization for Factorial<0>, which is
why it is endlessly recursive. I have no idea what MS really means by
"function dependency context too complex" except as a way of saying that
their compiler has some limit regarding template definitions which has been
overstepped.
I have no idea why "operator AUX_WRAPPER_VALUE_TYPE() const { return
this->value; }" would cause this, but perhaps it is some other construct.
Maybe Mr. Gurtovoy can shed some light.
Jaap Suter wrote:
> Hi,
>
> Since I started using the latest version of the MPL, the one that
> shipped with 1.30.0, I've been getting the following error a lot:
>
> e:\library\boost\boost\mpl\aux_\integral_wrapper.hpp(78) : fatal
> error C1202: recursive type or function dependency context too complex
>
> I'm using MSVC 7.0.
>
> It's really to find out what is causing it, because it only happens in
> really deep and complex compile-time calculations. I wasn't getting
> them before, and Intel and GCC work fine as well.
> I understand this message is probably too vague, but any help or
> advice
> would be greatly appreciated.
>
> Regards,
>
> Jaap Suter
>
>
>
> ___
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Regex and STLPMT.LIB
An easier way to solve this problem is to start a command processor with just the PATH environment you want and build. You can do this by creating a batch file which sets your path as appropriate and invoke the Make file from within the batch file. That is how I do all my regex builds. Then there is no reason to rename folders or fiddle around with the global PATHs under Windows. Malcolm Smith wrote: > Yes, I renamed my BCB6 folder as an interim fix - all OK now. > > Malcolm Smith > Analyst Programmer > Comvision Pty Ltd > http://www.comvision.org > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Russell Hind > Sent: Tuesday, 18 March 2003 23:30 > To: [EMAIL PROTECTED] > Subject: [boost] Re: Regex and STLPMT.LIB > > > John Maddock wrote: >> >> It looks more likely that you actually compiled with Builder 6, as >> that ships with (and uses) that lib. >> > > I ran into this problem. Builder 6 puts itself at the head of the > path, > so when you run make (for building regex), I ended up building with > BCB6 make, and then tried linking it with a BCB5 project and hit this > exact problem. > > Russell > > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Regex and STLPMT.LIB
Malcolm Smith wrote: > I cannot find 1.30. Where ? The 1.30 release is the upcoming one but one could download it from SourceForge as a beta. I thought you might be trying that. Evidently you are building with 1.29 or earlier. I don't see any STLPMT.LIB in the bcb5.mak so you are picking it up from somewhere strange for bcb5 and not from the regex make file for bcb5. > > I may have not used an explicit path for the MAKE operation. I will > rebuild it again. > > Thanks. > > Malcolm Smith > Analyst Programmer > Comvision Pty Ltd > http://www.comvision.org > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Edward Diener > Sent: Tuesday, 18 March 2003 13:01 > To: [EMAIL PROTECTED] > Subject: [boost] Re: Regex and STLPMT.LIB > > > Malcolm Smith wrote: >> Hi all, >> >> >> I just compiled the regex library under C++Builder 5. >> >> I've tried to compile an application and it complains about not being >> able >> to find STLPMT.LIB - I can find no information on this LIB. > > It's a BCB6 library for the stlPort implementation of the C++ standard > library. You shouldn't be getting it for a BCB5 regex build, however. > In the Boost 1.29 implementation, the bcb5.mak has no mention of > STLPMT.LIB. Are you using the Boost 1.30 implementation ? If so and > bcb5.mak does have STLPMT.LIB in it, it may be an error in the file. > > > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Regex and STLPMT.LIB
Malcolm Smith wrote: > Hi all, > > > I just compiled the regex library under C++Builder 5. > > I've tried to compile an application and it complains about not being > able > to find STLPMT.LIB - I can find no information on this LIB. It's a BCB6 library for the stlPort implementation of the C++ standard library. You shouldn't be getting it for a BCB5 regex build, however. In the Boost 1.29 implementation, the bcb5.mak has no mention of STLPMT.LIB. Are you using the Boost 1.30 implementation ? If so and bcb5.mak does have STLPMT.LIB in it, it may be an error in the file. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast and boost-1.30
Kevlin Henney wrote: > In article <[EMAIL PROTECTED]>, Edward Diener > <[EMAIL PROTECTED]> writes >> >> I am not trying to change lexical_cast at this late date since it >> must get out the door with 1.30, but this goes back to a comment I >> made quite a while ago about the two different versions of wchar_t >> on VC7 and the possible need to support both in Boost. I think it >> was briefly discussed by others but, more or less, shelved as an >> important issue. > > I think the issue is not really related to lexical_cast. lexical_cast > works just fine on VC7 supporting non-native wchar_t. However, to be > sure of more universal support using the BOOST_ config macros, any > compiler that does not have a native wchar_t is excluded from wide- > character support under the current version of lexical_cast. Will lexical_cast work correctly if the VC7+ end-user changes the option to C++ native wchar_t ? If not, you might get some complaints from end-users who are migrating away from the MS version of wchar_t to the C++ standard version on VC7+. I think others also brought up the fact that they want Boost to support C++ as much as possible vs. a compiler's non-standard version of C++. Again I realize it is probably too late to change things for 1.30, as everyone wants to get this out without further delays, but for the future this issue needs to be addressed. For better or worse, there are many VC++ programmers out there and MS is definitely pushing VC7.1 as a Boost compatible implementation. > > In the next version we can perhaps be more precise, but for the moment > the default is that lexical_cast compiles in the most conservative > way. > >> The only reason I bring this up again is that Boost may have some >> pretty angry MS programmers when they find out, at linker time for >> library implementations and at compile time for non-library >> implementations if a blocking Boost macro is in place, that wchar_t >> support does not exist for a given implementation. >> >> Perhaps this issue should be addresses once 1.30 gets out the door. > > Sounds reasonable. Which Boost libraries currently use wchar_t but are > not 100% header based? I know of Regex++. There may be other Boost libraries which other people know about. I am pretty sure John Maddock is aware of the issue, but other library implementors who use wchar_t may not be. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast and boost-1.30
Kevlin Henney wrote: > In article > <[EMAIL PROTECTED] > a>, Dave Gomboc <[EMAIL PROTECTED]> writes >> >> I would vote to fix lexical_cast before release. > > Looking at the regression tests from last night, that appears to have > happened. > >> Frankly, wchar_t support in lexical_cast isn't as important as >> fixing the space problem, I'd rather the fix go in even if it >> regresses in this area >> -- unless someone pipes up to say they are actually USING wchar_t and >> lexical_cast on a compiler that won't grok the new code. And if >> there is such a person, then I'd appreciate the ugly hack of >> including both >> versions with #ifdefs. > > My sense is that only a few people have commented on lack of wchar_t > support, whereas space is the final frontier that has hit many more. > > At the cost of a little duplicate code and a #ifdef the newer version > is > much more reticent about its support for wchar_t. Any compiler that > does > not fully support built-in wchar_t, wstring and wide-character streams > does not receive any support at all for wchar_t, even though the code > might kind of work in some cases, eg VC7 compiled without native > wchar_t support no longer offers support for wide-character > lexical_cast, even > though the tests pass 100% in that case. So if anyone now complains > about apparent lack of wchar_t support in lexical_cast, they should > contact their compiler and library vendors rather than the Boost list > ;-) I am not trying to change lexical_cast at this late date since it must get out the door with 1.30, but this goes back to a comment I made quite a while ago about the two different versions of wchar_t on VC7 and the possible need to support both in Boost. I think it was briefly discussed by others but, more or less, shelved as an important issue. The default in VC7 is still the Microsoft version as opposed to the C++ standard version of wchar_t. For header-file only implementations, whichever option is used when the header file is included in a module should theoretically work in Boost implementations. However if Boost has a macro for VC7 which says that wchar_t is not supported natively, then wchar_t may not work in Boost implementations. For library implementations which use wchar_t in any way, my original comment had to do whether different versions of libraries for VC7 should be built for supporting the two different versions of wchar_t in VC7. If one distributes a library with support only for one of the two versions of wchar_t in VC7, it will not work with modules built with the other version of wchar_t in VC7 ( lots of linker mismatches and error messages ). Of course instructions may be given to rebuild the library manually so that it works. Yes, it's a PITA because of MS's long-standing non-support for the native C++ wchar_t in their VC++ compiler. I believe the same problem will exist for 7.1 and until, if ever, MS pulls the plug on their non-standard wchar_t support. The only reason I bring this up again is that Boost may have some pretty angry MS programmers when they find out, at linker time for library implementations and at compile time for non-library implementations if a blocking Boost macro is in place, that wchar_t support does not exist for a given implementation. Perhaps this issue should be addresses once 1.30 gets out the door. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast(Was: FYI)
A very quick, but probably irrelevant, thought from someone who doesn't know the internals of lexical_cast or of the test: Remember that VC7 now supports two different types for wchar_t, depending on the option used when building a module. Could this by any slight chance be causing a problem ? Kevlin Henney wrote: > In article <[EMAIL PROTECTED]>, > Beman > Dawes <[EMAIL PROTECTED]> writes >> >>> Just to let you know that a new version is now in CVS. >>> >>> However, it appears to break under the regression test. I expected >>> it to break for VC6, but it is apparently failing to compile under >>> VC7 and >>> Intel 7.0... which is more than a little bizarre because I have been >>> using VC7 as the main test compiler and Terje checked it against >>> Intel >>> 7.0. Both compile and run cleanly. >> >> VC++7 is not giving trouble with any tests other than >> lexical_cast_test. On it, the message begins: >> >> D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: >> 'InputStreamable' : undeclared identifier > > Which of course, is not the case :-> The problem does not appear to be > with the code. > >> The error messages from various date_time library fails for both >> Intel >> and VC++ 6.0 are similar. Here is the Intel message: >> >> D:\boost\site-RC_1_30_0\boost/lexical_cast.hpp(137): error: no >> operator "<<" matches these operands operand types are: >> std::basic_stringstream, >> std::allocator> << const std::basic_string> std::char_traits, std::allocator> return stream << input; > > This suggests that the compiler has deduced wchar_t as being the > appropriate type for the stream when it should be char. This relies on > rather straightforward full template specialisation, which would seem > odd to get wrong. > >> Plus Robin Hu's posting: >> >>> A word on the lexical_cast_test.cpp: everything will be ok if you >>> commented all tests about std::wstring and wchar_t with >>> >>> #ifndef BOOST_NO_STD_WSTRING >>> #endif >> >> Both seem to indicate a wstring/wchar_t problem. > > The problem is related to wstring and wchar_t, but is not related to > compiler/library support for them. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Jamfile patches for Borland
Beman Dawes wrote: > At 09:07 PM 3/11/2003, Edward Diener wrote: > > >While I realize it may be the only answer to the problems you > mention, >making libraries link to the static RTL where they would > normally link to >the dynamic RTL is IMHO a bad general solution. My > reason for thinking > this > >is the problems which always seem to occur when modules mix static > and >dynamic RTL routines in their linkage to other libraries. I > can't prove >this always causes problems but I have seen where using > either all >dynamic RTL or > >all static RTL when creating an executable and accompanying > libraries is >always a safe run-time solution, at least as far as > reusability of the > RTL > >is concerned. > > While I understand this argument against "making libraries link to the > static RTL where they would normally link to the dynamic RTL", the > patch Alisdair provided doesn't alter any object libraries. It > affects regression tests only, or am I missing something? My error. I looked at the comment and misinterpreted it rather than understanding that the patch was about testing rather than generating libraries. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Jamfile patches for Borland
While I realize it may be the only answer to the problems you mention, making libraries link to the static RTL where they would normally link to the dynamic RTL is IMHO a bad general solution. My reason for thinking this is the problems which always seem to occur when modules mix static and dynamic RTL routines in their linkage to other libraries. I can't prove this always causes problems but I have seen where using either all dynamic RTL or all static RTL when creating an executable and accompanying libraries is always a safe run-time solution, at least as far as reusability of the RTL is concerned. Alisdair Meredith wrote: > Borland fails several tests due to missing exports from in > its > dynamic runtime library. > > The following two patches will use static linking on the problem > libraries (for borland only) snip... ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Singleton class
Mr. Alexandrescu has an impressive singleton class template in Loki and explained in "Modern C++ Design". Aashit Soni wrote: > hi , > Do we have singleton class? > if we dont have that and think to have it - i'd designed one simple > _singleton<> that works good to make parameter class singleton.. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Re: Thread-Local Storage (TLS)andtemplates
William E. Kempf wrote: > Edward Diener said: >> William E. Kempf wrote: >>> Edward Diener said: >>>> William E. Kempf wrote: >>>> I still don't think it is a TLS issue but rather a thread cleanup >>>> issue and the restrictions imposed by MS's design of that >>>> situation. So I can well understand your chagrin at the tricks you >>>> must do in order to cleanup internal thread data when a thread >>>> exits under Windows. >>> >>> That's a minor fine hair your splitting. What's the difference >>> between "a TLS issue" and a "thread cleanup issue" of TLS data? >> >> Because it is a thread cleanup issue of any thread specific data, not >> just TLS. No matter what the data that exists for a thread when the >> thread is exited, it musty be cleaned up efficiently. A user could >> have objects associated with only a particular thread and if the >> thread ends, it must be able to cleanup while other threads continue >> running. The fact that MS says no to this in DLL_THREAD_DETACH, that >> you are effectively blocking other threads in the process until you >> exit the DllMain routine, is for me the central weakness. > > What forms of "thread specific data" are there besides TLS? How does > DllMain play into how you clean up such data? One could dynamically create an object in a DLL that exists for one thread and not another, depending on what the thread is doing, and hold a pointer to that data mapped to a particular thread. Then when the thread exits in the DLLMain routine, one could look to delete that object which may in tuern have other consequences. I am not saying that this is the usual way of using threads, but just posing the idea that TLS itself may not represent all of the data which a thread wants to delete when it exits. If it is supposed that it is the only reliable way of creating thread-specific data, and any other method of using thread-specific data is bad and prone to error, then I agree with you that TLS under Windows can be considered as part of the issue of cleaning up data when a thread exits. Again we are nitpicking over an issue in which I think we both agree that the cleanup of thread-specific data, however we define it which at present is essentially TLS, when a thread ends is not designed effectively in Windows. DllMain comes into it because MS's design for passing through DllMain when a thread exits is that no other thread can run until your code in DLL_THREAD_DETACH in DllMain is finished. If another thread could run, either because of blocking on synchronization or just pre-emption, then synchronization and LoadLibrary issues probably wouldn't come into effect and the headaches you are experiencing in Boost.Threads wouldn't be happening. Again my guess, without knowing the gory details of Windows DllMain code and probably not caring to know, is that DllMain, and its internal code, is not reentrant and therefore the only guarantee that keeps another thread from entering it while one thread is already in the midst of it, is the draconian anti-effective-cleanup measures of which you are familiar. > >>> And >>> if you look back, I said I wouldn't call it "broken", just that the >>> "implementation has serious design issues". So it looks like we're >>> in agreement now. >>> >>> Want to join in my mini campaign to convince MS to fix this one? >> >> As long as the suggested fix is to allow thread cleanup without the >> current restructions on synchronization or DLL loading/unloading, >> sure. I don't think you are going to change anything in the way that >> TLS currently works nor should you. I am going to guess that MS is >> aware of this issue of thread cleanup and that the main fix on their >> part would be to allow re-entrancy in the current DllMain routine, >> which of course may be a big job on their part given the amount of >> underlying intertwined code. > > I have to disagree. First, I don't think you *can* solve the > reentrancy problems with DllMain. Second, even if you could, DllMain > is the wrong solution for cleanup. Something as simple as a thread > exit routine would be a much better "partial" solution, though it's > silly not to add this directly to TlsAlloc() (or a TlsAllocEx() to > keep backwards compatibility). While I agree with you that an effective thread exit routine rather than DllMain's DLL_THREAD_DETACH is a better design, I think you must realize that you are dealing with a company with millions and millions of developers and any serious change in the way things are designed will be very slow to happen. In the meantime
[boost] Re: Re: Re: Re: Re: Thread-Local Storage (TLS) and templates
William E. Kempf wrote: > Edward Diener said: >> William E. Kempf wrote: >> I still don't think it is a TLS issue but rather a thread cleanup >> issue and the restrictions imposed by MS's design of that situation. >> So I can well understand your chagrin at the tricks you must do in >> order to cleanup internal thread data when a thread exits under >> Windows. > > That's a minor fine hair your splitting. What's the difference > between "a TLS issue" and a "thread cleanup issue" of TLS data? Because it is a thread cleanup issue of any thread specific data, not just TLS. No matter what the data that exists for a thread when the thread is exited, it musty be cleaned up efficiently. A user could have objects associated with only a particular thread and if the thread ends, it must be able to cleanup while other threads continue running. The fact that MS says no to this in DLL_THREAD_DETACH, that you are effectively blocking other threads in the process until you exit the DllMain routine, is for me the central weakness. > And > if you look back, I said I wouldn't call it "broken", just that the > "implementation has serious design issues". So it looks like we're > in agreement now. > > Want to join in my mini campaign to convince MS to fix this one? As long as the suggested fix is to allow thread cleanup without the current restructions on synchronization or DLL loading/unloading, sure. I don't think you are going to change anything in the way that TLS currently works nor should you. I am going to guess that MS is aware of this issue of thread cleanup and that the main fix on their part would be to allow re-entrancy in the current DllMain routine, which of course may be a big job on their part given the amount of underlying intertwined code. The other solution(s) involves some sort of callback as you suggested, or some other way to ensure that a thread can be exited cleanly without blocking other threads from running in the meantime, whether in an executable, a static LIB, or a DLL. Knowing MS from their track record, a campaign to get them to change anything entails working closely with one or more of their techies who can actually understand the issues involved and get the changes to be seriously considered. Just voicing displeasure in any public way won't do anything. If there is a VC++ rep who now works closely with Boost to ensure VC++ .NET conformance, he's the guy I would "badger" first, and then through him you might be able to get to other MS techie employees. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Thread-Local Storage (TLS) and templates
William E. Kempf wrote: > Edward Diener said: >> William E. Kempf wrote: >>> And it's full of issues. >>> You are quite limited in what you can safely do within DllMain. Any >>> calls to synchronization routines is likely to deadlock the entire >>> process. >> >> I agree that this is so. You can't sit and wait until some other >> thread has done something, via a Windows synchronization primitive, >> when you are processing DLL_THREAD_DETACH. What is the situation >> where this is necessary ? > > There are numerous situations where this is necessary. For example, > the cleanup mechanism in both Boost.Threads and pthreads-win32 use > mutexes, which can potentially cause *process* deadlock. If the TLS > data is shared across threads, or references data shared across > threads, or simply calls a routine that does synchronization in the > cleanup, all of which are not that uncommon, and some of which are > hard for the programmer to avoid (do you know what routines do > synchronization internally?), you risk deadlock. My understanding of TLS data is that it is thread specific and not meant to be shared across threads. The whole idea is that every thread in a process gets their own copy of the same data. Why then do you say that "TLS data is shared across threads, or references data shared across threads" ? The last issue of doing synchronization in the cleanup I can understand but not that the data which needs to be synchronized is TLS data itself. I completely agree with you that there is a serious problem in the DLL_THREAD_DETACH attempting to do synchronized cleanup, but I am guessing that you may be using TLS data itself in ways in which it was not intended. I don't believe TLS data was ever intended as a way to share data between threads but was intended, as its name implies, to create data that is specific only to a single thread. > >>> As is calling any routines that load/unload a DLL. >> >> The workaround is not to dynamically load/unload a DLL as part of >> thread processing. > > Do you know what routines do this as part of their implementation? To > quote the MSDN "Calling imported functions other than those located in > Kernel32.dll may result in problems that are difficult to diagnose." > And since a very large number of Win32 API functions are imported... > I think you see the issue. I see the issue and although I haven't investigated what Windows API functions may load/unload a DLL dynamically, something tells me that MS must publish such a list somewhere so that one knows what to avoid at DLL_THREAD_DETACH time at least within their own Windows APIs. > >> Yes, it is cleaner to do so when one only needs a DLL for a >> specific time but the overhead of statically linking a DLL into a >> process instead is minimal, although I agree that dynamic loading is >> often a cleaner design. I do agree with you that the inability to >> dynamically load and unload a DLL at >> DLL_THREAD_ATTACH/DLL_THREAD_DETACH is an unfortunate imposition and >> that this is poor design on MS's part. I am still not clear whay >> this is so and why this limitation exists on Windows. > > I honestly don't care. The only time I've ever found this design to > be unusable is when dealing specifically with the cleanup of TLS > data, which would be much better implemented as a registered cleanup > routine in the first place. Fix this, and I don't care about this > artifact of the DLL system on Win32 platforms. OK, given that a registered cleanup routine would not have the restrictions which DLL_THREAD_DETACH has. I still don't think it is a TLS issue but rather a thread cleanup issue and the restrictions imposed by MS's design of that situation. So I can well understand your chagrin at the tricks you must do in order to cleanup internal thread data when a thread exits under Windows. > >>> There's >>> also the issue of forcing the use of a DLL with this scheme, which >>> many users rightfully dislike (this is why there are so many thread >>> creation routines on Windows). >> >> I could be mistaken but I believe that TLS works just as effectively >> in static LIBs as it does with DLLs. The difference is that one must >> do manual initialization routines and finalization routines of TLS >> data for different threads, as opposed to what one may do >> automatically using DLL_THREAD_ATTACH/DLL_THREAD_DETACH. But >> certainly one is not forced to use only DLLs or only static LIBs if >> the implementation supports both. > > Initialization isn't really an issue, as you can do lazy > initialization (synchronization issues aside, as they
[boost] Re: Re: Re: Thread-Local Storage (TLS) and templates
William E. Kempf wrote: > Edward Diener said: >> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> >>> Edward Diener said: >>>> "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message >>>> news:[EMAIL PROTECTED] >>>>> >>>>> Ken Hagan wrote: >>>>>> >>>>>> Alexander Terekhov wrote: >>>>>>> >>>>>>> I, for one, believe strongly that "&k" is nothing but >>>>>>> >>>>>>> "static_cast(pthread_getspecific(__k_key));" >>>>>>> >>>>>>> It *isn't* a compile-time constant (just like &errno isn't a >>>>>>> compile time constant). >>>>>> >>>>>> MSVC has no pthread_getspecific(), so I venture to suggest that >>> your >>>>> belief probably isn't valid for that compiler. >>>>> >>>>> Uhmm. In return, I venture to suggest that MS-TLS can and shall be >>> characterized as ``utterly busted.'' >>>>> >>>>> "If a DLL declares any nonlocal data or object as >>>>> __declspec(thread), it can cause a protection fault if >>>>> dynamically loaded." >>>> >>>> This is well-known by many and has never been hidden by MS. It >>> doesn't mean __declspec(thread) is busted, it just means that it is >>> limited to only those cases in which the DLL is not dynamically >>> loaded, which is the vast majority of cases. Of course to make TLS >>> completely foolproof, one does not use __declspec(thread) but >>> instead one uses the Win32 TLS API functions instead. >>> >>> Where you run into issues with TLS cleanup ;). >> >> Such as ? >> >> You can clean up your own TLS index ( or indices ) in your DllMain >> routine when the seond parameter is DLL_PROCESS_DETACH, meaning that >> your process is being exited. AFAIK this is the standard way to do >> this. > > (Note: The issue is more with cleaning up TLS data then with cleaning > up TLS indices/slots. So we're really talking about > DLL_THREAD_DETACH here.) Then perhaps the weakness is not really with TLS on Windows but rather with limitations to actions one can perform at DLL_THREAD_DETACH time. Would you describe these issues specifically ? > > This is the MS way, not the "standard" way. "This" referring to what above ? > And it's full of issues. > You are quite limited in what you can safely do within DllMain. Any > calls to synchronization routines is likely to deadlock the entire > process. I agree that this is so. You can't sit and wait until some other thread has done something, via a Windows synchronization primitive, when you are processing DLL_THREAD_DETACH. What is the situation where this is necessary ? > As is calling any routines that load/unload a DLL. The workaround is not to dynamically load/unload a DLL as part of thread processing. Yes, it is cleaner to do so when one only needs a DLL for a specific time but the overhead of statically linking a DLL into a process instead is minimal, although I agree that dynamic loading is often a cleaner design. I do agree with you that the inability to dynamically load and unload a DLL at DLL_THREAD_ATTACH/DLL_THREAD_DETACH is an unfortunate imposition and that this is poor design on MS's part. I am still not clear whay this is so and why this limitation exists on Windows. > There's > also the issue of forcing the use of a DLL with this scheme, which > many users rightfully dislike (this is why there are so many thread > creation routines on Windows). I could be mistaken but I believe that TLS works just as effectively in static LIBs as it does with DLLs. The difference is that one must do manual initialization routines and finalization routines of TLS data for different threads, as opposed to what one may do automatically using DLL_THREAD_ATTACH/DLL_THREAD_DETACH. But certainly one is not forced to use only DLLs or only static LIBs if the implementation supports both. > >>> I won't be as critical as Alexander, but I will agree that the MS >>> TLS implementation has serious design issues which need to be >>> corrected. >> >> OK, this isn't the place to debate Windows TLS, but I have not run >> into such design issues myself. > > You have, you just weren't necessarily aware of it ;). No, I haven't for what I was doing but that doesn't mean you or othe
[boost] Re: Re: Thread-Local Storage (TLS) and templates
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Edward Diener said: > > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > >> > >> Ken Hagan wrote: > >> > > >> > Alexander Terekhov wrote: > >> > > > >> > > I, for one, believe strongly that "&k" is nothing but > >> > > > >> > > "static_cast(pthread_getspecific(__k_key));" > >> > > > >> > > It *isn't* a compile-time constant (just like &errno isn't a > >> compile time constant). > >> > > >> > MSVC has no pthread_getspecific(), so I venture to suggest that your > >> belief probably isn't valid for that compiler. > >> > >> Uhmm. In return, I venture to suggest that MS-TLS can and shall be > >> characterized as ``utterly busted.'' > >> > >> "If a DLL declares any nonlocal data or object as __declspec(thread), > >> it can cause a protection fault if dynamically loaded." > > > > This is well-known by many and has never been hidden by MS. It doesn't > > mean __declspec(thread) is busted, it just means that it is limited to > > only those cases in which the DLL is not dynamically loaded, which is > > the vast majority of cases. Of course to make TLS completely foolproof, > > one does not use __declspec(thread) but instead one uses the Win32 TLS > > API functions instead. > > Where you run into issues with TLS cleanup ;). Such as ? You can clean up your own TLS index ( or indices ) in your DllMain routine when the seond parameter is DLL_PROCESS_DETACH, meaning that your process is being exited. AFAIK this is the standard way to do this. > > I won't be as critical as Alexander, but I will agree that the MS TLS > implementation has serious design issues which need to be corrected. OK, this isn't the place to debate Windows TLS, but I have not run into such design issues myself. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread-Local Storage (TLS) and templates
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Ken Hagan wrote: > > > > Alexander Terekhov wrote: > > > > > > I, for one, believe strongly that "&k" is nothing but > > > > > > "static_cast(pthread_getspecific(__k_key));" > > > > > > It *isn't* a compile-time constant (just like &errno isn't a compile > > > time constant). > > > > MSVC has no pthread_getspecific(), so I venture to suggest that > > your belief probably isn't valid for that compiler. > > Uhmm. In return, I venture to suggest that MS-TLS can and shall be > characterized as ``utterly busted.'' > > "If a DLL declares any nonlocal data or object as __declspec(thread), > it can cause a protection fault if dynamically loaded." This is well-known by many and has never been hidden by MS. It doesn't mean __declspec(thread) is busted, it just means that it is limited to only those cases in which the DLL is not dynamically loaded, which is the vast majority of cases. Of course to make TLS completely foolproof, one does not use __declspec(thread) but instead one uses the Win32 TLS API functions instead. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread-Local Storage (TLS) and templates
"Ken Hagan" <[EMAIL PROTECTED]> wrote in message b32951$hn8$[EMAIL PROTECTED]">news:b32951$hn8$[EMAIL PROTECTED]... > Reading various replies, we appear to have a couple of things that > aren't completely pinned down: the type of "&k" and the implementation > of TLS.rest snipped... You have pointed out what I have said right from the beginning. Depending on the implementation, &k can be different things, and therefore the TLS problem is essentially implementation-defined. Of course I still am gladly following the discussion which assumes that &k is most likely something which one might expect it to be most of the time, a pointer into a table of values for each thread, and that one can expect to decide intelligently from that whether or not one can use it as a value in a template instantiation for a non-type template parameter, but essentially we can not know this until we know how a given compiler's implementation treats it. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Lock Classes: Does anyone care.
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Wed, 19 Feb 2003, Edward Diener wrote: > > > I think the question that needs to be answered is if locking mechanisms have > > any use outside of threading models. > > Yes they do. For example when accessing memory shared between separate > process. Also, locks can also be used when accessing files. In fact I > believe Win32 always uses read/write locks when opening files, on POSIX > systems the locks are completely optional but still there. Basically locks > can be used when ever accessing a shared resource. I think you have made a good case for a separate library for locking mechanisms. Whether that will be your library in some form or some other one or some mix of implementations, is for the general Boost community to decide. But I believe, given your argument above, that a locking library should not be only folded into the threading implementation which already exists. Of course the implementor of the threading library may feel that his own internal locking mechanisms are sufficient for what he wants to do in his library, but that shouldn't inhibit a separate locking library if the functionality is found useful for other Boost programmers. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Lock Classes: Does anyone care.
"Gennadiy Rozental" <[EMAIL PROTECTED]> wrote in message b2v2p5$6ad$[EMAIL PROTECTED]">news:b2v2p5$6ad$[EMAIL PROTECTED]... > > > 1. Does not Boost.Thread already have locking mechanisms > > > > The only thing boost threads offer is #1 on my list, that is "The ability > > to acquire a lock and release it when the object goes out of scope > > effectively implemented the "Monitor" concept". Implementing this idea is > > rather easy and obvious. It is the other things my classes offer that > > make it interesting. The differences should be obvious. > > In any case it should be part of Boost.Thread IMO. You may propose your > classes as an extension to existent Boost.Thread functionality. I think the question that needs to be answered is if locking mechanisms have any use outside of threading models. If so, a library of locking mechanisms should be separated from the thread library although the thread library certainly can use it. If not, then locking functionality should be folded into the thread library. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread-Local Storage (TLS) and templates
"Greg Colvin" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Any thoughts on this issue?
>
> >From: Steve Clamage <[EMAIL PROTECTED]>
> >To: C++ core language mailing list
> >Message c++std-core-9820
> >
> >Some compilers implement thread-local storage (TLS) for what would
> >otherwise be global variables. The compiler and runtime system
> >arrange for each thread to see its own copy of a global variable.
> >
> >Should the address of such a variable be allowed as a non-type
> >template parameter? For example, this code is OK:
> >extern int k;
> >template< int* V > class C { ... };
> >C<&k> ck;
> >
> >But what if k is designated thread-local? The actual variable
> >referred to by the address of k will differ among threads.
> >(I'm assuming an implementation where &k results in a link-time
> >constant whether k is an ordinary or thread-local variable.)
Two thoughts:
1) I don't know of any compiler which automatically makes 'k' thread-local.
You either have to:
a) tell the compiler that it is thread-local, ie. __declspec(thread) int k;,
or you must:
b) implement TLS yourself using an API which does pass a valid pointer to an
"int" in this case, but one that is certainly not a compile-time constant.
2) In case a) we are dealing with an implementation-defined language
extension ( __declspec(thread) ) so whether the address of such a variable
is to be allowed as a non-type template parameter appears like it may also
be implementation defined. In case b) we are not dealing with a compile-time
constant so that it must certainly fail.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Linker trouble when building regex lib
"Mark Davenport" <[EMAIL PROTECTED]> wrote in message 01c2d1a1$7fdee890$4198fc3e@brio">news:01c2d1a1$7fdee890$4198fc3e@brio... > Hello boost list > > I'm newish to C++ and very new to boost. > > I've just tried to build the object library for regex > in Borland Builder 5 Pro on Windows XP. I ran the make > on bcb5, got no errors at that stage, but when I try to compile > my app within the Builder IDE I get a fatal linker error: > Cannot load BOOST_REGEX_BCB5_MDI.LIB. Any ideas? This means that the linker is not finding finding BOOST_REGEX_BCB5_MDI.LIB on your Library path ( Project | Options | Directories/Conditionals | Library path ) or that your build didn't create an import library with this name anywhere. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Al Stevens who writes the C++ column for "Doctor Dobbs Journal" put out a persistent template library for C++ containers some time back. It is probably on the DDJ web site, although I haven't looked there recently. You might want to check that out and see what he did. I will readily admit I have not had the need to persist container data in my daily programming but I can understand others having that need. "Vladimir Prus" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Hi, > > after having to output std::vector to stream again and again using custom > solution, I started to wonder why we don't have a solution in boost. > Does it makes sense to include operators<< for vectors, sets, etc? > > I was thinking about > > > > > and so on. There are basically two approaches: > > 1. Operators use fixed format: bracked list with commas between values for > vector, for example. > 2. Manipulators are provided to set brackets and separators. > > I had implemented the second approach some time ago, but it turned out that > was overkill. So, 1) looks better now. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Greg Colvin" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 08:25 PM 1/28/2003, Edward Diener wrote: > >"Beman Dawes" <[EMAIL PROTECTED]> wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> At 01:42 PM 1/28/2003, David B. Held wrote: > >> > >> >"Greg Colvin" <[EMAIL PROTECTED]> wrote in message > >> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > >> >> Also, auto_ptr is an ugly hack that needn't be replicated. > >> > > >> >Disavowing your child? ;) > >> > >> Historical note: auto_ptr<> was one of the few (maybe only) times when the > >> C++ committee as a whole overrode the recommendation of the Library > >Working > >> Group. > >> > >> Greg and other people in the LWG didn't like auto_ptr<>, preferring what is > >> now called shared_ptr<>. But we were good soldiers, and accepted the > >> committee's decision. That meant we had to develop auto_ptr<>, even though > >> we didn't like it. A lot of us still think it is a minor smart pointer, and > >> has no place in the standard, except perhaps as an adjunct to more > >> important smart pointers such as shared_ptr<> and eventually smart_ptr<>. > > > >Many people have used std::auto_ptr<> successfully to do what it does best. > >As languages and understanding evolve other, better solutions have evolved > >also, but that doesn't mean std::auto_ptr<> has not served its purpose or > >will continue to do so. > > My problem with auto_ptr isn't so much the semantics, which > have proved useful and are probably the minimum needed to > solve the problem that the committee wanted solved. And it > isn't so much the "move as copy" syntax that Howard dislikes. > And except on a personal level it isn't the politics that led > to it being the way it is. My problem is the extremely fragile > language tricks needed to implement auto_ptr, exploiting a > loophole on a loophole, which I don't think should be imitated > unless really, really necessary. I hope that in the next > standard the language can be changed in a way that makes > auto_ptr straightforward to implement. OK, but the language tricks, which I am guessing centers on auto_ptr_ref, are very well hidden from the user who understands exactly how and why a std::auto_ptr<> should be used. In that sense it is successful rather than in the sense of the difficulty of implementation itself. In other words, the basic interface to using it is clear and fairly simple unless the programmer decides not to learn it and just makes unwarranted assumptions. I have no doubt a smarter pointer, such as Boost's shared_ptr<> and/or Loki's SmartPtr<>, will be part of the next standard, for the simply reason that a smart pointer which can be used in containers is an important programming idiom. Over and above that I am sure there are other commendable goals for a smarter pointer standard library class, but whichever smarter pointers are chosen, the implementors should not take their eye off of the result that makes that smart pointer clear and fairly simple for an end-user programmer to use in its normal configuration. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 01:42 PM 1/28/2003, David B. Held wrote: > > >"Greg Colvin" <[EMAIL PROTECTED]> wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > >> Also, auto_ptr is an ugly hack that needn't be replicated. > > > >Disavowing your child? ;) > > Historical note: auto_ptr<> was one of the few (maybe only) times when the > C++ committee as a whole overrode the recommendation of the Library Working > Group. > > Greg and other people in the LWG didn't like auto_ptr<>, preferring what is > now called shared_ptr<>. But we were good soldiers, and accepted the > committee's decision. That meant we had to develop auto_ptr<>, even though > we didn't like it. A lot of us still think it is a minor smart pointer, and > has no place in the standard, except perhaps as an adjunct to more > important smart pointers such as shared_ptr<> and eventually smart_ptr<>. Many people have used std::auto_ptr<> successfully to do what it does best. As languages and understanding evolve other, better solutions have evolved also, but that doesn't mean std::auto_ptr<> has not served its purpose or will continue to do so. I believe that those who are part of the C++ Standards committee are making too much of the "Standard". Standards evolve and so do languages. When they don't, they solidify into stone instead of being a living organism of change and while there is nothing wrong with stone, per se, it is a much harder substance with which to work than a more malleable element. I prefer the more malleable element and I am not personally concerned, as a C++ programmer, with the need to support code 20 and 30 years old and more. Therefore the need to never actually offer any improvements to the C++ language itself or the need to justify every library change as something that must last for the next 20 or 30 years, as so many committee members seem to believe, is IMHO an unnecessary delusion. I hope to see better smart pointers in the next version of C++ and Boost's shared_ptr<> seems like a good candidate. If Loki's SmartPtr<> makes it in also I see nothing wrong with that too. I just wish that members of the commitee, and I do not mean to point my finger at you directly, would just realize that changes to the languages and library do not have to be 100% correct in all their ramifications for all time, but that when changes are made they should serve the practical purpose of making the language easier to use and program in the future. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Deadline for the Standard Library Technical Report
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message b14cq2$2km$[EMAIL PROTECTED]">news:b14cq2$2km$[EMAIL PROTECTED]... > "Beman Dawes" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > At 04:25 PM 1/24/2003, Jeffrey Yasskin wrote: > > > > >Just out of curiosity, which boost libraries are likely to be proposed > to > > >the committee? > > > > See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html > > This is yet another bad PR move, but then I thought, if voicing an opinion > around here constitutes a problem, then the problem is not mine. So here > goes. PR stands for public relations AFAIK. Why is it a PR move ? If you think it is a bad PR move, why is it "another bad PR move", ie. what was the previous bad PR move ? > > The smart pointer proposal is unconvincing to me. This, of course, comes at > no surprise. There's some conjecture in the reference document at > http://www.boost.org/libs/smart_ptr/shared_ptr.htm such as "The support for > custom deallocators does not impose significant overhead" or "My opinion is > that the added functionality is worth the cost" etc. Not what one would > like to hear about a one-size-fits-most standard library implementation. > > On to the FAQ. (I will skip over the first three Q&A with which I totally > disagree.) > > Q.Why doesn't shared_ptr provide a release() function? > A.shared_ptr cannot give away ownership unless it's unique() because the > other copy will still destroy the object. > > The answer doesn't answer the question. The next natural question is, "ok, > but if the pointer is unique(), can I benefit of a release() function that > returns a bool telling me whether the release worked or not?" > > It turns out that in COM the need of relinquishing ownership back to the > system (or another entity) is a common case. Has anyone used shared_ptr > with COM extensively? I agree with you here. I think that one should theoretically be able to release a shared_ptr if there are no other copies of it around. However could you explain further the situation(s) in which this is likely to occur ? I understand COM but normally one uses a smart pointer with COM that is tied into the referencing counting mechanism of the COM interface to which the pointer is referring. Without getting too deeply into a discussion of COM, I would be reticent to use a general smart pointer mechanism with it but would use one designed specifically to work with COM interfaces such as those provided by Microsoft and Borland with their C++ offerings. I don't doubt that a generalized smart pointer that worked correctly with COM might be useful, but then should we consider CORBA and any other generalized object-oriented technologies in the mix. Where does one stop ? > > Q. Why doesn't shared_ptr provide (your pet feature here)? > A. Because (your pet feature here) would mandate a reference counted > implementation or a linked list implementation, or some other specific > implementation. This is not the intent. > > This is a presupposition. Someone wants to mandate lazy > initialization/specific dereference testing/specific initialization > testing/tons others. Would any of these require a refcounted/reflinked > implementation? Perhaps this has already been done, or perhaps you mean others to look at your own Loki smart pointer to understand what you think is missing from Boost shared_ptr, but I think you need to either specify what you believe are the specific weaknesses of the Boost shared_ptr class, present your own smart pointer to Boost as a better alternative within the Boost library, or present your own smart pointer to the C++ committee as a better or additional alternative to the Boost shared_ptr. Your last paragraph is not an argument for anything because one can not guess what "tons others" means. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Patch for BOOST_STATIC_CONSTANT docs -config-patch.txt
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> Shouldn't we stick the -b- option in our borland toolset, since it
> increases conformance?
In C++ Builder you can use a #pragma to ensure enum size from within a
header file using enums no matter how the -b option is set by the user. This
ensures binary compatibility. I use this technique all the time with enums
in my own Borland header files. The Regex++ library uses it also as Dr.
Maddock can affirm.
#pragma option push -b- // or #pragma option push -b
// enum(s) here
#pragma option pop
>
> Gennaro Prota <[EMAIL PROTECTED]> writes:
>
> > On Sun, 26 Jan 2003 10:05:51 -0500, "Edward Diener"
> > <[EMAIL PROTECTED]> wrote:
> >
> >>For Borland, the default is to make enum's int sized but this can be
changed
> >>with the -b- option in which enums are made as small as possible
depending
> >>on the range.
> >
> > Yes. The original problem, anyhow, was not about making them small but
> > making them large and giving them the right signedness, like in:
> >
> >enum { e = 2147483648u };
> >
> > Actually the -b- option also has this effect (thus with that option e
> > < 0 would yield false, as required by C++) but the help file provided
> > with Borland command line tools has an error that can be misleading in
> > that regard. It says:
> >
> >
> >When this option is off (-b-), the compiler allocates the
> >smallest integer that can hold the enumeration values:
> >the compiler allocates an unsigned or signed char if the values
> >of the enumeration are within the range of 0 to 255 (minimum) or
> >-128 to 127 (maximum), or an unsigned or signed short if the values
> >of the enumeration are within the following ranges:
> >
> > 0 to 4,294,967,295 or -2,147,483,648 to 2,147,483,647
> >
> >
> > It seems to refer only to types not larger than int, leading to think
> > that -b- is just a space optimization. Instead it also concerns sign.
> >
> > Note the last sentence: the ranges are those of unsigned and signed
> > *int*, not short :-) Probably there's a whole part in the middle that
> > got lost for some reason, which should be:
> >
> >..unsigned or signed short if the values... are within
> >
> > 0 to 65535 or -32768 to 32767
> >
> >or an unsigned or unsigned *int* if they are in
> >the range
> >
> >
> > 0 to 4,294,967,295 or -2,147,483,648 to 2,147,483,647
> >
> >
> > Genny.
> >
> > ___
> > Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
> --
>David Abrahams
>[EMAIL PROTECTED] * http://www.boost-consulting.com
> Boost support, enhancements, training, and commercial distribution
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for BOOST_STATIC_CONSTANT docs - config-patch.txt
"John Maddock" <[EMAIL PROTECTED]> wrote in message 00e801c2c535$8ce128a0$c37487d9@1016031671">news:00e801c2c535$8ce128a0$c37487d9@1016031671... > > Considering what we've seen in the recent thread > > "BOOST_STATIC_CONSTANT and VC++ enums", I thought to add a warning for > > VC++ users in the config docs. Also, there's a note saying > > > > > > "Note that in the above example value will have different > >lvalueness, depending on whether the compiler supports the > >static const or not." > > > > The patch (if there are no objections) is to be applied to rev. 1.23 > > > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/config/confi > g.htm > > No go ahead, BTW other compilers (Borland and Sun off the top of my head), > always make enum's int sized as well. For Borland, the default is to make enum's int sized but this can be changed with the -b- option in which enums are made as small as possible depending on the range. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Policy-based smart pointers revisisted
"Paul Mensonides" <[EMAIL PROTECTED]> wrote in message 004f01c2c0d5$da16f5a0$4900a8c0@c161550b">news:004f01c2c0d5$da16f5a0$4900a8c0@c161550b... > - Original Message - > From: "David Abrahams" <[EMAIL PROTECTED]> > > > > My feeling is that the boost community would of course be interested > > > in looking over a related submission, but most of its members are > > > not interested in actively working on such a port. And let's face > > > it, I'm not popular with boost, and that doesn't help generating > > > enthusiasm inside boost :o). > > > > I think your perception that your unpopular with boost does more to > > hurt your ability to generate enthusiasm than any actual > > unpopularity. You seem to have the attitude that the cards are > > stacked against you, and to approach boost with a kind of resentment > > and resignation that you won't get a fair hearing. > > I don't want to propagate a war here, but Andrei's perception (of his > perception) is not entirely unfounded either. In the past, Andrei has > raised some practical concerns with certain design strategies. At that > time, his opinion was derided based entirely on, from my perspective, > religious devotion to an unproven concept. Andrei asked for practical > examples of the utility of those design strategies, and he was effectively > told, "If you don't like it, don't use it." I don't want to get into that > old argument again, and that is not my intention. I'm merely pointing out > that Andrei got flack for presenting an opinion counter to many Boost > developers' and standing by that opinion. The fact is that there are many > things that various Boost developers will argue over with religious fervor > (i.e. another way of saying "political"), and I simply don't believe that > people are entirely objective. Their preferences influence their beliefs, > and people typically don't take criticism well. That is to be expected. > Such is life. People disagree with others all the time based on their technical understanding. No one's opinion is exempt from reasonable discussions or arguments over what someone else perceives as the correct solution to a technical problem. I'd argue with William Shakespeare ( or his ghost ) on poetical drama if I though I had an intelligent comment to make or, more to the point, with Bjarne Stroustrup on C++. I am a great admirer of "Modern C++ Design" as I would guess many other C++ programmers also are. That doesn't make Andrei exempt from other's opinions, as I am sure he knows, nor do I believe he really thinks it should be so. But it is strange that he really thinks he is unpopular with Boost, meaning people who use or create Boost libraries. I would guess exactly the opposite since the spur he gave to creative template programming in his book must certainly have influenced many Boost developers. > > The same thing looks like it is happening here with policy-based smart > pointers. It seems to me that arguments are being manufactured to preclude > the concept of a policy-based smart pointer (such as incompatibilities and > the supposed complexity of interface--neither of which I personally think is > significant) precisely because it isn't 'shared_ptr' or that it would > subsume 'shared_ptr'. That may or may not be the case, but that is how it > comes off to me, and I can see how it would come off that way to others. I don't think people are "manufacturing" arguments. They are just bringing up issues, seeking to discuss them, and make intelligent comments about ideas which they care. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Edward Diener" <[EMAIL PROTECTED]> writes: > > > "David Abrahams" <[EMAIL PROTECTED]> wrote... > >> "Edward Diener" <[EMAIL PROTECTED]> writes: > > >> > Nonetheless I do favor a compiler change such as allowing the "default" > >> > keyword to be used instead as Mr. Terekhov suggested in that same thread. > >> > That would be much cleaner and should be easy for any compiler to handle. > >> > This is one case where I would like to see the language updated with such an > >> > easy, transparent solution to the problem. Of course if others don't see it > >> > as much of a problem, they wouldn't be in favor of the solution since it > >> > involves the dreaded "C++ language change" > >> > >> Oh, it's a problem alright, but I'm still not very convinced of that > >> solution. The problem with interfaces that have lots of positional > >> parameters is that you forget what the different positions mean. To > >> solve that problem, you need either named parameters or a > >> position-independent interface. > > > > Since the C++ language already has embraced positional parameters as > > its normal means of passing information to functions, classes, or > > templates, it is a little disingenuous to complain about them. > > Do you know the meaning of "disingenuous"? Did you really mean to > accuse me of intellectual dishonesty? Not at all. My dictionary doesn't define "disingenuous" as "intellectual dishonesty" but even by its definition it was a very poor choice in the expression above and I shouldn't have used it along with the "complain" rhetoric. Just got carried away. What I meant to say was that arguing against positional default parameters goes against the grain of the language IMHO. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Edward Diener" <[EMAIL PROTECTED]> writes: > > > "Fredrik Blomqvist" <[EMAIL PROTECTED]> wrote in message > > b0cvd7$4dv$[EMAIL PROTECTED]">news:b0cvd7$4dv$[EMAIL PROTECTED]... > >> -snip- > >> > I thought the C++ template solution by Damian Conway was pretty neat, > >> -snip- > >> I thought so too at first, but at a closer look you can see that the code > > in > >> practice only works for integers.. It solves the problem in the original > >> thread, but shouldn't be mistaken for a generic solution. > > > > It seems as if it should work for any type with a copy constructor. Perhaps > > I missed something. > > > > Nonetheless I do favor a compiler change such as allowing the "default" > > keyword to be used instead as Mr. Terekhov suggested in that same thread. > > That would be much cleaner and should be easy for any compiler to handle. > > This is one case where I would like to see the language updated with such an > > easy, transparent solution to the problem. Of course if others don't see it > > as much of a problem, they wouldn't be in favor of the solution since it > > involves the dreaded "C++ language change" > > Oh, it's a problem alright, but I'm still not very convinced of that > solution. The problem with interfaces that have lots of positional > parameters is that you forget what the different positions mean. To > solve that problem, you need either named parameters or a > position-independent interface. Since the C++ language already has embraced positional parameters as its normal means of passing information to functions, classes, or templates, it is a little disingenuous to complain about them. Every function call is essentially a matter of knowing "what the different positions mean". Since we are stuck with this metaphor, so to speak, we can at least make the best of it in regard to default parameters with a simple solution. I wouldn't mind the idea of named parameters so much other than the adjustment away from what every C++ programmer has previously become accustomed to using. I imagine the compilers would also get more complicated as another area for dealing with C++ identifiers would have to be dealt with. Simply adding "default" in order to invoke the default value for a particular position is so much easier. My point is: since we already deal with "positions" in nearly everything, why not add "default" as has been suggested. If the language evolves to named parameters or some other means of a position-independent interface for passing normal parameters, we can consider these other ideas for passing default values. Keeping the metaphor consistent ( KTMC as opposed to KISS ) seems to me to be the best idea for now. That's not to say that you or others shouldn't invent better means, if you think it worthwhile, given what the language currently offers. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"Fredrik Blomqvist" <[EMAIL PROTECTED]> wrote in message b0cvd7$4dv$[EMAIL PROTECTED]">news:b0cvd7$4dv$[EMAIL PROTECTED]... > -snip- > > I thought the C++ template solution by Damian Conway was pretty neat, > -snip- > I thought so too at first, but at a closer look you can see that the code in > practice only works for integers.. It solves the problem in the original > thread, but shouldn't be mistaken for a generic solution. It seems as if it should work for any type with a copy constructor. Perhaps I missed something. Nonetheless I do favor a compiler change such as allowing the "default" keyword to be used instead as Mr. Terekhov suggested in that same thread. That would be much cleaner and should be easy for any compiler to handle. This is one case where I would like to see the language updated with such an easy, transparent solution to the problem. Of course if others don't see it as much of a problem, they wouldn't be in favor of the solution since it involves the dreaded "C++ language change" . ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
