Re: [boost] enable_if formal review ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jaako, Jaakko Jarvi wrote: | Hi Boosters, | | We submitted enable_if for formal review in July. The library does not | seem to be on the review queue, It is in fact in the queue, only that the queue is only current in CVS. | and maybe it is not worth a full | review. Let's introduce a fasttrack review for this kind of utility components criteria and procedure will be as follows. What components qualify for a fasttrack review - - - - The technique must be already in use in boost libraries ~ thus the new component provides a common implementation - - The component must be small Procedure - - - - A full boost-conformant implementation is available in the sandbox - - The submitter posts an fasttrack review announcement to the list (should this go to boost-announce as well?). Review period should last for 5 days. No two fasttrack review should run in parallel. Fasttrack review may run during full reviews, though generally this should be avoided. - - After the review period ended, the submitter will post a review summary containing planned changes to the current implementation. - - After applying all changes, the component will be checked in to cvs by the submitter. If nobody objects, I'll add this to our review policies. Thomas Boost Review Wizard. - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/S2jB0ds/gS3XsBoRAgE8AJ0fPp7LS8DBg40OrGrR+pa/bkXYfgCfednm RUDdbbSxF1x1SFTXSDGjGvI= =yjEu -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: enable_if formal review ?
David Abrahams wrote: Thomas Witt [EMAIL PROTECTED] writes: - - A full boost-conformant implementation is available in the sandbox Or in Boost CVS, I hope... since if it's already in use it may already be there. I assume that in general the new component would have a new place and add some tweaks. Furthermore I would not want to make a general exception to the review-first-boost-CVS-then idea. That being said, something that is in boost CVS already doesn't need to be moved to sandbox for review purposes. - - The submitter posts an fasttrack review announcement to the list (should this go to boost-announce as well?). Review period should last for 5 days. No two fasttrack review should run in parallel. Fasttrack review may run during full reviews, though generally this should be avoided. No review manager intervention at all? Yep this is going to be lightweight process. If it doesnt play out we can change it accordingly. Hmm, I'd rather you make the announcement. I can check the preconditions and do the scheduling as well as the announcement, if you want me to. Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: |Just out of curiosity. What the heck is librt? | | | It contains the POSIX realtime feature set (used by boost.threads, and hence | tested by boost.config for timeouts and thread priorities and the like). Ahhh.. Thanks! Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/O2ny0ds/gS3XsBoRAgmqAJ48W8mgnaD0xDKjiE8SwfyjOmGI1gCfdYlW Bj4/UnUt8H5aVe6xWC5xI+k= =+0Iq -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Wille wrote: | David Abrahams wrote: | | | The config_test regression was caused by not having linked against | librt. I added these lines to intel-linux.jam on the RC_1_30_0 branch: Just out of curiosity. What the heck is librt? Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/O1lD0ds/gS3XsBoRAsU5AJ4gY6y2AozxySczPbLwR1M26b+YgQCfWiBB qPGiYaI3OSu4cKMuYNX5acQ= =YoJd -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Filesystem: naming, canonical path
Dave, Beman Dawes wrote: At 08:06 PM 8/9/2003, David Abrahams wrote: I'm sorry if this sounds harsh, but I think the cure for someone being confused about the term absolute on multi-root OSes is to pick the definition that allows the term to be meaningful (an absolute path identifies a specific location, and so must include the root) and *add a clarifying note or definition for the corner case*, not to pick some new term which nobody knows about and makes the library hard to approach. The problem is not someone who is confused. The problem are a potentionally significant number of users who are sure they know what they are doing, but don't. A clarifying note won't be much use to them, cause for them there seems to be nothing that needs clarification. Just to make this clear, I don't blame them for this. I think we are all prone to this behaviour. We mostly fail due to things we believe we know not due to those we think we don't know. The library isn't all that large that people can't just read about each function. There were lengthy discussions on the list of this and other naming issues during development, during review, and during the resolution of review issues. Many people had fairly strong views. IIRC, the idea that is_absolute( /foo ) was false on some operating systems was impeded by long-held beliefs. By giving the function an unfamiliar name, people are forced to actually read the specs instead of just assuming what it does, and that ends up being a good thing, IMO. I second this. Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
David Abrahams wrote: Thomas Witt [EMAIL PROTECTED] writes: What would be the native representation for the following native ^^ ^^ Sigh! paths C:\C\foo \C\foo C:\foo Not a very interesting challenge. C:\C\foo \C\foo C:\foo Grrr... I assume you mean the portable representation of the native paths: /C/C/foo / + *current_path().begin() + /C/foo (**) /C/foo (**) There is no way to represent The foo subdirectory of the C directory of the current drive portably, because it isn't a portable concept. I would argue that different drives are the non-portable concept. Therefore, we could pick other sensible answers for the middle path, e.g.: 1. Exception is thrown 2. ./C/foo 3. /*/C/foo where '*' is some character not normally allowed in portable paths. I think your proposal is clearly inferior to what we currently have. With your solution the set of valid portable paths is dependent on the set of valid roots on a given platform. I.e. all portable(syntax) paths starting with a slash are essentially non-portable. Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Filesystem: naming, canonical path
Dave, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: If I were king, the portable, generic version of windows-native c:/foo would be /c/foo and the portable generic version of windows-native /foo would be *current_path().begin()/foo. Is there a reason that approach was rejected? Yes, it had five or six different problems IIRC, although some of them can be fixed by adding additional syntax. For example, the ambiguity in /c/foo - is it a relative path starting with a directory named c or a complete path to the c drive Read as a generic path according to my system, it is not a relative path because it starts with a slash. That's simple and there should be no confusion assuming you know you're not looking at a native format.. Ok, here is the challenge Given the following directory structure C:\C\foo \foo What would be the native representation for the following native paths C:\C\foo \C\foo C:\foo Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: | What is the problem adapting pair of iterators to scalar vectors to produce | an iterator with complex value type? The problem is you can hardly adapt a pair. So using iterator_adaptor (the new class template) does not provide any benefit. | | I am sure both old and new iterator adaptor easily allows it. | As I said before iterator_facade (new) would be the right tool AFAICS. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MUsi0ds/gS3XsBoRAh8HAJ4kZumstczYuRg1VklfHHadWsjpCQCdGZT1 1KOJGnqwMriz3ZarJSpth7A= =pStw -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |Rozental, Gennadiy wrote: | || What is the problem adapting pair of iterators to scalar vectors to |produce || an iterator with complex value type? | |The problem is you can hardly adapt a pair. So using |iterator_adaptor (the new class template) does not provide |any benefit. | | | Why is that? The whole point in adapting is that you modify some but not all behaviour/interface of a thing. Ther is nothing a pair provides that can be reused so adaption is pointless. That's why the new version provides iterator_facade and iterator_adaptor. iterator_facade helps with implementing iterators, iterator_adaptor is for adapting iterator like types. | I did not look in depth on new version but I remember that old | one allowed to adapt any source. You needed to do this as the iterator interface implementation was not seperated from the actual iterator_adaption. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MVHC0ds/gS3XsBoRAsJLAJ4gb8KM3GJGi3wYM65ppMSfasuXtACghiD3 dGgVfgSioFYgEm0ihB0r9zY= =wm0V -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: |1) Since only 1 object can be passed to the iterator adaptor |constructor, I |had to pass a pair. | | | Use object generators. | | |2) Distance uses only one of the base iterators. | | | Use minimal distance. Different distances are most certainly a precondition violation. AFAIAC assert on differing distances. | | |3) iterator_category uses only 1 of the iterators. | | Use most restrictive category. In general don't use the old iterator_adaptor unless you really have to. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MWiy0ds/gS3XsBoRAg/mAKCFxhPTSwxfrqQloTThZN9HfNjt0gCgkgKB 32RUc1R4EOJzUgw4dmlRgoE= =gADX -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ABI fixing and prefix/suffix headers (was theboost::signalsample crashes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: | | One final point - there was a reason that I moved regex to use automatic | library selection and ABI fixing - without it I was getting a tonne of | support requests along the lines of Your library doesn't work, it just | crashes when I call anything, which almost always turned out to be caused | by ODR violations (either the user had changed an ABI option, or had linked | to the wrong runtime-library-build variant), these basically stopped | overnight once I modified my code to stop those (this was all in pre-boost | days BTW). FWIW I do believe that automatic library selection is a broken concept in praxis. It causes no end of problems when there is more than one library that does it. In the end you end up with the same situation as before the user has to know about the different runtime libraries and how to handle them. Furthermore I do believe that dependencies should be something that the programmer is aware of and that they should be actively managed by the programmer. Automatic library selection hides dependencies sometimes up to the point that dll's aren't shipped to the customer. Said that I can see your point John. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/M5fw0ds/gS3XsBoRArhaAJ9zPYhIARwrE2xTvG/mV8WhJI+w4gCbBlqt Jffv2UEPlUzTAE9ytIHcsbs= =kWRT -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neal, Neal D. Becker wrote: | Some time back I mentioned I was interested in iterator adaptors to convert | between vectors of complex and scalar. I have looked at using the iterator | adaptor framework in boost. It appears that it is easy enough to adapt from | a complex sequence to pick off either the real or imaginary part, but going | the other direction is not feasible? | | You would need to adapt from a pair of iterators over scalars to output an | iterator over complex. Thomas Becker is working on a combine iterator that will solve this problem. IIUC he has a working draft. | | Will the new iterator adaptor framework help? If you need it badly iterator_facade will help with getting the iterator interface right. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MT3Q0ds/gS3XsBoRAk+gAJ4vWlBSQkW8+pGAwMlHYWJ6y7k2JgCfRSF9 a6MjiFmWyB01bI7tScpMY6Y= =BLfu -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Shifted ptr review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philippe, could you please contact me in case you are still interested in shifted_ptr being reviewed. TIA Thomas BOOST Review Wizard. - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MS6j0ds/gS3XsBoRApt5AJ0QSBaiYuWEHYHTlAgQtAHnRU3ImwCdGaqL 81EsBPFzXJDbi/JRSUX6l3A= =zG0I -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Filesystem: create_directories
Jeremy B. Maitin-Shepard wrote: On Mon, 04 Aug 2003 10:51:07 +0400 Vladimir Prus [EMAIL PROTECTED] wrote: [snip] Another option might be: create_directory_and_parents That name is longer than create_directories although it better describes the function. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions create_directory_and_parents looks best to me. ensure_directory_exists does not imply any operational semantic(i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). demand_directory is good. One problem is that demand still does not communicate to me that something will be created. I suggested create_directory_and_parents because the current create_directories has exactly the semantics of calling create_directory incrementally on each parent directory path, then on the directory path itself. AFAICS this is not correct. create_directory will throw if the directory exists. IIUC create_directories will not. Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Re: Filesystem: create_directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir, Vladimir Prus wrote: | Reid Sweatman wrote: | | So, to summarize, I've no problem with the current name that I've | introduced. :-). Seriously having two functions that differ only by number is a no-go to me. | Of other suggestions create_directory_and_parents looks best | to me. ensure_directory_exists does not imply any operational semantic | (i.e. the name does not say that the directory will be created. That's exactly the point. The operational semantics are that the directory is only created if it not already exists. The long name is do_what_it_takes_but_make_sure_this_directory_exists(path p); | One might | expect exception to be thrown if dir does not exist). This is a bit of a stretch AFAICS but if ensure is to much like assert, I am perfectly fine with demand. | demand_directory is | good. One problem is that demand still does not communicate to me that | something will be created. And that's good because creation does not necessarily happen. Not until you require that create_directories creates at least one directory. I don't see this in the documentation and I don't think this would be the most usable semantics. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/LiGi0ds/gS3XsBoRAvypAJ9tqAhHcHL4IjyE7pdjF1JKD8iJpACfVC2y 2mcc8YE/zl1umrg/WJjo7Es= =O4XE -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Filesystem: create_directories
David Abrahams wrote: Dave Gomboc [EMAIL PROTECTED] writes: Ah, naming again. My favourite. :-) It's not my favourite, but it matters. I like create_path_and_directory. I prefer this order of the two terms because logically the path exists before the directory itself does. create_full_path(path, 'd') create_full_path(path, 'f') I'de like to get away from create. As I understand it, what we really want is to make sure a directory path actually exists without necessarily creating any directories. To me calling a create function for something that already exists should be an error. I can't see a reasonable way to have these semantics with create_directories. What about something like this: ensure_path_exists(path); Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem: create_directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Abrahams wrote: | The documentation for create_directories makes no sense. It says | only: | | void create_directories( const path ph ); | | Precondition: ph.empty() || | forall p: p == ph || is_parent(p, ph): is_directory(p) || !exists( p ) | | Postcondition: exists(ph) is_directory(ph) | | It looks as though this is the same as create_directory, but has a | weird precondition. I swear I was *completely* baffled by its | purpose until I looked at the header file. This seems to have slipped by me. I really feal uncomfortable with having two different functions named create_directory and create_directories Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/K8Hu0ds/gS3XsBoRAuYTAJ9HRfJPfW2k/Od4TZIX94bYiLA2kQCdH+OK NmJUgQDA6XGun2t3drJSX8s= =HHVF -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Minor bug in indirect_iterator.hpp
Joe Gottman wrote: There is a small problem with the current version of indirect_iterator.hpp. It forward declares struct indirect_iterator, but declares class indirect_iterator. MSVC 6.0 emits a warning because of this. Thanks! Fixed. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. I agree with Dave here. To me there is another good reason for doing minor releases more frequently. Neither the next major release nor the CVS state is likely to help most of the people who use Boost in their projects. I guess that there are a lot of projects out there that cannot allow for an interface change in one of the core libs every couple of month. So they really need bugfix only releases if showstopper bugs are found in the last release. Just my 2c Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem compiling boost.filesystem library
Beman Dawes wrote: msvc: C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899: typename cannot be used outside a template declaration Fixed. -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review request: enable_if
Jaakko,
There are three issues I have with enable_if as it is.
1. enable_if takes a boolean template argument. I would like to see it
taking a type with a member value that that can be used in an ICE. This
would play nice with mpl and type_traits and would make enable_if
expressions shorter.
template class T
typename enable_ifboost::is_arithmeticT, void::type foo(T t) {
std::cout An arithmetic type\n;
}
2. I am unhappy about the name enable_if_lazy. First it reads as a
condition, whereas being lazy is not the condition. Second it is
inconsistent with the mpl apply_if. At least the inconsistency should be
fixed IMO.
3. To me the disable templates don't add any value. They are just
duplicating the amount of code without any real benefit. I know this is
a matter of taste, it's just that I would prefer a minimal interface.
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet
Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
On Wednesday 09 July 2003 19:43, David Abrahams wrote:
I strongly prefer this interface:
Me too.
// enable_if operates on types with a nested ::value
template class T
typename enable_ifboost::is_arithmeticT, void::type foo(T t) {
std::cout An arithmetic type\n;
}
template class T
typename disable_ifboost::is_arithmeticT, void::type foo(T t) {
std::cout Not an arithmetic type\n;
}
// and enable_if_c operates on integral constants:
I doubt that the _c version are needed frequently enough to warrant the extra
types.
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New Iterator Adapters - filter_iterator
Dave, On Thursday 03 July 2003 09:32, David Abrahams wrote: Thomas Witt [EMAIL PROTECTED] writes: I've checked in a fix for this. Static asserts make the instantiation of iterator_adaptors members fail depending on the iterator category. You may want to try it, though I don't have access to VC until tomorrow, so it is not guaranteed to work. I guess with the new categories that might be OK. With the old categories it was neccessary to allow operations which didn't correspond to the category so that users could build, e.g., random traversal readable rvalue iterators (had to be labeled as input iterator). We should take care that we're not disallowing people from building useful iterators with capabilities that aren't accounted for by our categories. The reason I choose to do it this way was that it was the least intrusive modification that did the job. I can envision a more sophisticated mix-in based approach but frankly I don't think that it's worth it. As you said the problem of disallowing usefull combinations was mostly due to the old categories, but even with the old categories I would prefer the safe road. The user who wants to provide more than the category asks for can always reimplement the needed functions in a derived class. I like the idea of being explicit about doing something special. Furthermore I think that this inconvenience is more than outweighed by the added safety. Things that accidently compile should be avoided whereever possible. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New Iterator Adapters - filter_iterator
John, John R. Bandela wrote: Should filter_iterator use iterator_facade as its base instead of iterator_adapter? It seems the iterator_adapter is incorrectly implementing advance. I wouldn't say that it is incorrectly implementing advance. AFAICS the problem is that there is no way to restrict the functionality that iterator_adaptor provides in a derived class. I am not yet decided what the right fix to this issue is, maybe a mix in based implementation of iterator_adaptor is the right way to go. Regards, John Bandela PS: I don't know if this is the place to ask, but I have updated tokenizer to the new iterator adapters. Is there some place it should be placed pending release of the new iterator_adapters? I was under the impression that Dave is gonna move it to the main trunk real soon, so keeping it on your local disk for a few more days might be the easiest solution. Dave? Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New Iterator Adapters - filter_iterator
John, On Wednesday 02 July 2003 02:34, John R. Bandela wrote: I was playing with the new iterator adapters in the sandbox. As I was looking at filter_iterator, I found that it allows user code to increment it like a random access iterator. Here is an example that compiled on VC 7.1 I've checked in a fix for this. Static asserts make the instantiation of iterator_adaptors members fail depending on the iterator category. You may want to try it, though I don't have access to VC until tomorrow, so it is not guaranteed to work. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: I/O library status
Daryle, On Thursday 05 June 2003 01:28, Daryle Walker wrote: Actually, that reason isn't accurate. The '\n' is an expression of type char, and all output streams can print a char object with operator , even if the stream's character type isn't char. (The stream will secretly call the widen member function.) Yep, you are right. This will tell me to stop talking about io issues from memory ;-). Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: I/O library status
Hi,
On Monday 02 June 2003 19:21, Ed Brey wrote:
* newl differs from '\n' only in that newl doesn't perform background
formatting. Presumably one would choose to use newl to avoid the
formatting. What is undesirable about '\n' being formatted?
To me there are basically two reasons that make newl desirable beside the
formatting issue.
1. std::endl was and is still abused heavily. I think there is a reason for
this. Most c++ programmers are taught to stay clear of ugly low-level c
things and to use the new shiny c++ facilities instead. And that's what they
do, replace '\n' with std::endl. Personally I believe this reason alone
justifies a std library extension std::newl.
2. IIUC the difference between a character and a manipulator is that the
manipulator is not tied to the streams character type. So for some
applications '\n' does not suffice. To me stream.widen('\n') is sufficiently
ugly to justify a newl modifier.
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost version 1.30.0 released
On Thursday 20 March 2003 18:37, Beman Dawes wrote: Boost version 1.30.0 has been released. Thanks, for managing the release. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] exception context
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trevor Taylor wrote: | | Perhaps I could relate some of my experience and put some ideas up | for discussion? I would be interested. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+eE020ds/gS3XsBoRAhOiAJ9AnG2pe52k7rVX4p6qsFcQslbeAQCaA0je J4HMlWAmwpUY20RHhGuP1TU= =GMg1 -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Abrahams wrote: | [EMAIL PROTECTED] writes: | | I think we need to keep the argument for VC6 at least; the problem is | one that shows up at link time because VC6 seems to distinguish | function template instantiations only by the types of the arguments | and not the template parameters. FWIW, it's a problem with the name mangling. Parameters and return type show up in the mangled name, template arguments don't. As a result this applies to all compilers that have complete VC6 compatible name mangling. AFAICS intel5 is one of them. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+dzfq0ds/gS3XsBoRArquAJ91kNFWoeZDgcUhtp1mwWthrvXhggCeNMY3 nBWtrXGVcxKKkWpAcHAxjc4= =zqnF -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] filesystem library name RC_1_30_0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Beman, the library name is still fs. I was under the impression that this was only temporary and should be changed to a more boost compatible boost_filesystem before release. From a pratical point of view fs seems like begging for a nameclash. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+dbzj0ds/gS3XsBoRAv8AAJ9P0UYTuzG3PhFMNoUFEQBenIfLJQCcDb1A rhx1Fbk5gxR7f3oQpxAvCSU= =8TnF -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevlin, Kevlin Henney wrote: | In article [EMAIL PROTECTED], Thomas Witt | [EMAIL PROTECTED] writes | | (1) I would not consider that to be something to document as the | implementation should be free to choose a suitable approach, Agreed, when I was talking about getline() and str() I was using them more like a placeholder for the implied semantics. The semantic is documented now. | so long as | it satisfies the principle of least astonishment (the whitespace bug | clearly failed this test :-). Yes, it did not satisfy the principle of least surprise. No, it wasn't a bug. Thanks for the fix and the documentation update. Looks much better now. Nitpickingly yours Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+dLaC0ds/gS3XsBoRAtIHAJwMx8x+MfIloy9nPdkzLeDOUiJzVgCeIaA9 NviKY9OWXNPGb5QSUYFisS0= =mRhl -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast fixes
Kevlin, Kevlin Henney wrote: In article [EMAIL PROTECTED], David Abrahams Without a documentation update?!? The documentation is the same as it was yesterday. The change was in the implementation and not the interface, which is what is documented. As said before I am not trying to block the lexical_cast update for 1_30_0. That's beyond my power anyway. I'll try to rephrase my criticism to be a bit more constructive. That said I do have serious concerns with regard to the documentation. I would really appreciate it if you could comment on the following issues. All quotations from the current documentation. In general I do think a paragraph describing the changes in semantics with respect to the prior version is missing. To me this is a must. IIUC there are wchar_t support aside two significant changes in semantics. First conversions to std::basic_string and second precision of floating point output. The change in floating point precision handling might be surprising to some users. Especially to those who use lexical_cast for output formatting. In detail: Returns the result of streaming arg into a std::stringstream and then out as a Target object. IIUC this is false for conversions to std::basic_string. If I read the code correctly std::getline is used to extract the string from the stream. There is a big semantic difference to using operator as implied by the above sentence. BTW why isn't streamobject.str() used to extract the string? I do think this needs to be documented and a rationale describing why the current semantics were choosen would be really helpfull in understanding lexical_cast and the involved problems. Note that spaces are significant in any conversion and are not skipped. I think this sentence was the main reason why I got the impression that you didn't change the documentation at all. To me it is easily misunderstood for someone who is aware of the problems with string streaming. To me this sentence implies that lexical_caststring(U U); does not work. I.e. whitespace is significant. Thanks in advance Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
Thomas Witt wrote: Hi, I am biased anyway, but I would vote for reverting the lexical_cast changes in RC_1_30_0. I was just looking at the new lexical_cast implementation and unless I messed up with updating my tree to RC_1_30_0 the documentation needs to be fixed as well. AFAICS the documentation nowhere mentions the change in semantics for string handling. Furthermore the documentation seems to be misleading with respect to the new semantics. Returns the result of streaming arg into a std::stringstream and then out as a Target object. Note that spaces are significant in any conversion and are not skipped. IIUC, this is no longer true for std::basic_string. I cannot resist, I particularly like this one. Where non-stream-based conversions are required, lexical_cast is the wrong tool for the job, and is not special-cased for such scenarios. To me its a clear argument for not changing the std::basic_string semantics. I got the impression that the majority on the list want's the change in string semantics and I am willing to accept this. But I would really like to see the documentation clearly state that strings are handled differently. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Kevlin did update the docs; the complaint is that the updates are unclear. I thought the complaint was that the current state is plain inaccurate in major ways. The complaint is that the doc's are misleading, at times straddling the border to being outright wrong. See my citations. It was a tough day today, maybe I am just mad. Could somebody please check whether the docs explain the special behaviour for std::basic_string. If they do I'll stop complaining. If they don't they need to be fixed before release. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal Review Requst: String Algorithm Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff, Jeff Garland wrote: |Phil, | |On Monday 03 March 2003 23:28, Phil Nash wrote: | |This request seems to have been left up in the air. I know that many are |busy with the release schedule, and there is an identified shortage of |review managers, but it would have been nice to have at least acknowledged |this request (unless it has been done offlist). | |Pavols request is already in the queue. This has been done off list. | | | Is the schedule available somewhere? The up-to-date schedule is in CVS. | I'm not even sure the web page | has been updated with recent past reviews. Perhaps we should have a | Wiki page or something with the upcoming reviews on it? We had a discussion with regard to this a while ago. IIRC the consensus was that the schedule should not be moved to the wiki. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+ZKOz0ds/gS3XsBoRAoadAJ99ldlvx00GEeNMCdVY9ka2xx3uKgCgkJGF ONIKv2HaXSkwA30cE/sdpUw= =LQel -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal Review Requst: String Algorithm Library
Phil, On Monday 03 March 2003 23:28, Phil Nash wrote: This request seems to have been left up in the air. I know that many are busy with the release schedule, and there is an identified shortage of review managers, but it would have been nice to have at least acknowledged this request (unless it has been done offlist). Pavols request is already in the queue. This has been done off list. Thomas Boost Review Wizard -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal Review for Boost I/O Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am responsible for the overlap. This is due to an email getting lost. The I/O review may be extended to make up for the overlap. I will make a posting as soon as a solution is found. In the meantime we will have two reviews running in parallel. Though this is in fact undesirable, I don't think it's a real problem in this case. Gennadiy Rozental wrote: | Wait a minute! | Variant is up to review till the Sunday 2nd. And I am planning to supply my | comments. | The variant review is still open and will be open until March 2nd. Thomas Boost Review Wizard - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Xd6A0ds/gS3XsBoRAlXoAJ4j7dZJOfdt6CxIVtod/Oc0hs9duACghTne Kc7FWW6lXR+hP4I2oVL6EUA= =vYhE -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Formal Review I/O Library Extended
Hi, To make up for the schedule problems the formal review for I/O is extended until March 11th. So there is no need to hurry for those willing finish their variant review first. As said before the variant review is still open until March 2nd. Thomas Boost Review Wizard -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] Doc nitpick
Hi, There is a reference to the 1.29.0 distribution in boost/libs/mpl/doc/index.html#source Shouldn't this be removed before 1.30 is branched? Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Review Managers Wanted
Hi, I am looking for volunteers who are willing to act as review manager. Due to the increasing number of review requests the current pool of review managers just isn't enough. As of now we do have a backlog of five outstanding reviews. For those interested in the details I have updated the review schedule in CVS. The updated schedule will move to the web with the 1.30.0 release. The ideal review manager is an experienced boost developer that is known to the people on the list. Though he don't need to have submitted a library himself. Nor does she actually have to be a he. Further information about the job of a review manager can be found on the webpage http://www.boost.org/more/formal_review_process.htm People who are willing to volunteer, please contact me by private email. Thanks in advance Thomas Boost Review Wizard -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Emily, Emily Winch wrote: | On Wed, 2003-01-29 at 15:30, Jeremy Siek wrote: | I would be very happy to submit it to boost, and several people have | suggested this. I think it would be a mistake to submit it for a formal | review without any prior discussion. Yep. What about making it available in the sandbox and improving the compiler support. | | I have mentioned this a couple of times now, and the lack of feedback | led me to think that nobody was particularly interested in it. That's | easy to believe, since when I wrote the paper it was really more from a | hey, this is cool perspective than hey, this would be really useful. It is definitely cool. If it is useful I don't know. | | So, I have a question: Why no feedback? | | a) The library is not something that people think makes sense in Boost. No | b) The library uses the wrong approach to the problem and someone should | submit something else. Haven't heard of anything so far. | c) The library is not something that anyone would really use. (Hey, | Jeremy. I'm sure you said you would use it). As said before I am not sure that it is useful. To me the concept is really usefull but there are practical issues that may outweigh the benefit. One problem is the organization of names, mostly key type names and where to put them. Another problem I encountered is that using alists does not neccessarily reduce the amount of source code that is written for the problem I tried to adress. This is partly due to syntactical issues. | d) People think it's a great idea but just never got round to having a | look or making any comments. One problem may be that the code does not compile on a wide range of compilers. It is a lot easier to play with something that compiles out of the box, than wading through endless strings of template related error messages. Don't get me wrong, I am not complaining about the code it is just a real life problem. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+PmDF0ds/gS3XsBoRAo/WAJ99uvlUbQt8ksYuZZ3tJW0I8GJx8QCbBu1+ WqRWy183/8UgpdpKIYwC8ZI= =ao1M -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review Request: shifted_ptr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philippe, Philippe A. Bouchard wrote: | Greeting, | | I would like to request a formal review for my library: shifted_ptr. It | consists of a smart pointer optimizing dynamic memory allocations and | deallocations on the heap, thus lower requirement on the memory map and | faster execution. | | It is accessible at: | http://groups.yahoo.com/group/boost/files/shifted_ptr.zip. | | The main documentation rationale is found in | /shifted_ptr/doc/structboost_1_1shifted__ptr.html. Thanks for submitting. I will contact you as soon as I have found a review manager. This might take some days. BTW Volunteers, anybody? Thomas Witt Boost Review Wizard -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+OV7I0ds/gS3XsBoRAhLnAJwNnlAZOyverjkjUOgrnVRFQGeDhQCfaN+/ W/bjOqSPsMN4TcfVRWyCB6c= =5XvY -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: | | The LWG suggested (and I agreed with) a change to is_base. To me this is a bad idea, from a usability point of view. I strongly object against making this change. The argument ordering is perfectly obvious in is_base_and_derived, there is no such hint in is_base. Just my 2c Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+N+dk0ds/gS3XsBoRAtD6AJwIvNqyKNwqGPMp0yKnm+AtG/dTDwCfRMjx PvxWiOpHeLVmyCCXu2No6uQ= =x9Oo -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_base_and_derived question
Hi, the type traits documentation for is_base_and_derivedT,U says Evaluates to true if type T is a base class to type U. IIUC is_based_and_derivedT,T evaluates to true as well. Is a class T strictly speaking a base class of itself? TIA Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] filesystem feature request: temporary path and files
Hi Alberto, Alberto Barbati wrote: Hi, first of all, I want to thank Beman Dawes and all others that contributed with the design and development of the Filesystem library. It's a wonderful piece of work. I just would like to propose a couple of additions that I believe are very useful. Both features regard temporary files. First proposal: I propose to add a function with a signature of this kind: path generate_path_for_temp_file(); IIRC functions like this are considered a bad idea. They are subject to race conditions and a potential security problem. I agree with you, that the functionality would be really helpfull. The usual solution to the race condition problem would be to have a function that returns a stream. See mkstemp on POSIX. Win32 has a similar facility. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast Future directions
Kevlin Henney wrote: This is the philosophy that Kevlin and I agreed on when lexical_cast was first introduced. However, I don't think it has stood the test of time with real users, and it would be stupid to ignore that. I Agreed. I see the problem, I am just unsure with regard to the solution. suspect Kevlin feels the same way about it, which is why he has agreed to review the changes in the Files area. Apologies for delays. Yes, I have to review Terje's changes and am guilty of not having applied myself to that task yet. In terms of the philosophy of the design, I think it would be reasonable to say that intuitive stream-based conversion is the aim, which is compatible with fixing whitespace issues. One more argument. lexical_cast may be able to provide intuitive conversion for all std string types, but it will likely brake again for custom string types. Even if the custom type has exactly the same interface and semantics as std::string lexical_cast will break. naggingly yours Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] lexical_cast Future directions
Hi, On Sunday 29 December 2002 01:29, Terje Slettebø wrote: there...) Anyway, the surprising result of this was that the space in Hello there caused the interpreter.eof() check in lexical_cast to fail. So if that check were not present, dest would have been assigned the value Hello. Fortunately, the check was there, and instead I got a bad_lexical_cast exception. This issue comes up at regular intervals, since this is one of the known problems of lexical_cast, but it hasn't yet been fixed. See e.g. this posting (http://aspn.activestate.com/ASPN/Mail/Message/1454894). A proposition has been made to fix this and other things (http://groups.yahoo.com/group/boost/files/lexical_cast_proposition/), and I'll get to update it properly, and write the docs for it, soon. It should work correctly as it is, as it's been tested in an extensive unit test (also found at the same place). Is this the way lexical_cast is intended to work? No, Kevlin has acknowledged that this is a known problem with the current version of lexical_cast, the handling of whitespace in strings and characters. I am still uncertain whether this is a problem with lexical_cast and whether it should be fixed. The stated purpose of lexical_cast is type conversion through string representation. I think this is a simple but powerful concept. To me the actual problem is not in lexical_cast but in the std::basic_strings stream operator semantics. Basically you cannot read strings containing whitespace as a whole. I.e. the integrity of a string containing whitespace is lost once you streamed it. This is a fundamental if at times undesirable property of std::basic_string and char const* for that matter. I don't know whether it is a good idea for lexical_cast to try to fix it. Just my 2c Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] trouble with browse info with VC++ 6.0 when boost filesare included
Toon Knapen wrote: When including some boost libraries Visual C++ 6.0 (with Intel compiler 7.0 and STLPort) is unable to generate the browse info. Have others experienced the same effect or is there some workaround ? From the top of my head, so take care. IIRC browse info generation is still done by cl, so if it can't parse it you are out of luck. I think this is documented somewhere. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Resend: Review Request: I/O Manipulators and Adaptors
On Sunday 08 December 2002 09:41, Daryle Walker wrote: Did the people who arrange formal reviews see this? Yes, this time. Sorry for missing your first post. Can you give me a short summary of what this stuff is about and whether it should be reviewed together or seperately. Where is this supposed to go in boost. I.e. seperate lib, utility .? Feel free to contact me by private email for any review issues. Thanks in advance. Thomas -- Boost Review Wizard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr deleter introspection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 21 November 2002 17:03, Peter Dimov wrote: Ah, _that_ workaround. IIRC (been a while since I used MSVC 6) there will be no link problems with get_deleter. 'D' is mentioned in the return type, and the return type of the function _is_ included in the mangled name, although the template parameters are not. Correct. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE93QsK0ds/gS3XsBoRAnEhAJ9oBgPj9Ay7Hp0OCxhhoriQ+HfKUQCggmty UK1Kp0eHUIBqgMfvah5F4rw= =O4L+ -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Suggestion for iterator adaptors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Herve, On Tuesday 19 November 2002 07:11, Herve Bronnimann wrote: Dave, Jeremy: one iterator adaptor I needed often (and once again today) is the projection on the first or second member of a pair. I could make it using projection_iterator and select1st, except that select1st is an std extension from SGI. I haven't found any other out-of-the-box way to do this, did I miss something? Not as far as I can see. As a sidenote. From my experience you will run into the projection/transform problem quite frequently. IIRC projection iterators cannot be used on base iterators that don't have real reference types. I find them especially useful in connection with map::iterator, since std::map does not have a value_iterator. I guess that alone provides the rationale for including such an iterator adaptor, not to mention better support of std::pair. Actually, I'd like to see a more general solution for all kind of tuple like types. Smth like typedef select_iterator0, std::mapint::iterator key_iterator_t; Btw, templated typedefs anybody ? It's simple enough to make two adaptors, so if you don't see anything wrong with it, I'm proposing the patch for you. I'll even write the corresponding portion of the documentation if you go ahead with it. Hope you like it, I like the idea, and yes I do believe there is a real need. There are just some issues to be sorted out. I'd like to postpone this until the new iterator_adaptor version is finished. Thanks Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE92kr/0ds/gS3XsBoRAquxAJ4yr6ZLp/LRhxjYDyW6bZHrqrpYBgCeO7E+ b7Ebbr85gMKFXrqBFqFMr/E= =u8Oq -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
