Stephan Bergmann wrote:
[EMAIL PROTECTED] wrote:
User: vg Date: 2006/11/22 02:43:14
Modified:
udk/ure/source/uretest/cppmain.cc
Log:
INTEGRATION: CWS hr33 (1.4.12); FILE MERGED
2006/05/02 17:01:26 hr 1.4.12.1: #i55967#: no prefix for STL header
please
[...]
#include <functional>
#include <memory>
#include <new>
+#include <hash_map>
[...]
-#include "stl/hash_map"
[...]
Is this change really clean? While it is important that standard
headers are
#include <map>
etc. the situation is different for non-standard headers like STLport's
hash_map. (We repeatedly had the discussion whether headers delivered
by one part of OOo and used within another part of OOo should be
included <...> or "...". We do not need to repeat that discussion here,
as we obviously come to no agreement, and it might be considered a
matter of style which to choose.)
At the very minimum, <hash_map> should have been inserted at the correct
place in the sorted list of included standard headers. Grr.
[Cursorily browsing
<http://www.openoffice.org/issues/show_bug.cgi?id=55967>, if we want to
support compiling OOo with anything but OOo's STLport, the cleanes
solution IMO would have been to wrap non-standard things like STLport's
hash_map functionality behind an (OOo-local) header like
sal/hash_map.hxx that does the necessary things to provide this
functionality, and to change any includes of the hash_map header to
#include "stl/hash_map.hxx"
You mean "sal/hash_map.hxx"? Of course that would be cleaner, at least
as long the tr1 stuff is not offical. Would also enable the standard
build to use the compiler provided STL. Any volunteers?
Heiner
PS: If we choose one implementation of hash_map we probably should take
the one from the TR1 report.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
