Boost inspection notification (2006-09-13/RC_1_34_0) *X*
Boost Inspection Report Run Date: 16:04:31 UTC, Wednesday 13 September 2006 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11659 files scanned 903 directories scanned 194 problems reported Problem counts: 0 files with invalid line endings 0 bookmarks with invalid characters 3 invalid urls 109 broken links 29 unlinked files 8 file names too long 0 files with tabs 3 violations of the Boost min/max guidelines 42 usages of unnamed namespaces in headers (including .ipp files) Summary: archive (3) bind (1) build (4) date_time (1) doc (2) filesystem (36) graph (4) iostreams (2) iterator (7) lambda (3) libs (6) more (12) mpl (1) multi_array (2) numeric (2) parameter (5) ptr_container (1) regex (1) regression (13) serialization (1) spirit (2) test (79) thread (3) type_traits (1) typeof (2) Details: *R* invalid (cr only) line-ending *A* invalid bookmarks, invalid urls, broken links, unlinked files *N* file names too long *T* tabs in file *M* uses of min and max that have not been protected from the min/max macros *U* unnamed namespace in header |archive| boost/archive/basic_streambuf_locale_saver.hpp: *N* filename > 31 chars boost/archive/impl/xml_wiarchive_impl.ipp: *U* unnamed namespace at line 53 boost/archive/iterators/remove_whitespace.hpp: *U* unnamed namespace at line 57 |bind| boost/bind/placeholders.hpp: *U* unnamed namespace at line 25 |build| tools/build/v1/variables.html: *A* unlinked file tools/build/v2/example/libraries/util/foo/include/lib1.h: *N* file's directory depth will exceed 8 levels if placed on a CD tools/build/v2/example/make/main.cpp.pro: *N* filename contains more than one dot character ('.') tools/build/v2/test/test_system.html: *A* unlinked file |date_time| libs/date_time/xmldoc/date_time_docs_howto.html: *A* unlinked file |doc| doc/html/boost_math/inverse_complex.html: *A* unlinked file doc/html/jam.html: *A* unlinked file |filesystem| libs/filesystem/doc/do-list.htm: *A* invalid URL (hardwired file): file://?/ *A* invalid URL (hardwired file): file://?/UNC/ libs/filesystem/doc/i18n.html: *A* broken link: convenience.htm#basic_recursive_directory_iterator *A* broken link: exception.htm *A* broken link: operations.htm *A* broken link: operations.htm#Do-the-right-thing *A* broken link: operations.htm#is_directory *A* broken link: operations.htm#is_file *A* broken link: operations.htm#status libs/filesystem/doc/index.htm: *A* broken link: convenience.htm *A* broken link: fstream.htm *A* broken link: operations.htm#create_directory *A* broken link: operations.htm#create_hard_link *A* broken link: operations.htm#current_path *A* broken link: operations.htm#directory_iterator *A* broken link: operations.htm#equivalent *A* broken link: operations.htm#file_size *A* broken link: operations.htm#initial_path *A* broken link: operations.htm#is_file *A* broken link: operations.htm#is_symlink *A* broken link: operations.htm#status *A* broken link: operations.htm#symlink_status *A* broken link: path.htm#Canonical *A* broken link: path.htm#Grammar *A* broken link: path.htm#Normalized *A* broken link: path.htm#default_name_check *A* broken link: path.htm#name_check_mechanism *A* broken link: path.htm#normalize *A* broken link: path.htm#operator_eq *A* broken link: path.htm#synopsis libs/filesystem/doc/portability_guide.htm: *A* broken link: path.htm#name_check_typedef libs/filesystem/doc/tr2_proposal.html: *A* invalid URL (hardwired file): file:///C|/boost/site/libs/filesystem/doc/operations.htm#complete_note |graph| boost/graph/maximum_cardinality_matching.hpp: *M* violation of Boost min/max guidelines on line 755 *N* filename > 31 chars libs/graph/doc/lengauer_tarjan_dominator_tree.htm: *N* filename > 31 chars libs/graph/doc/sorted_erdos_renyi_generator.html: *N* filename > 31 chars |iostreams| libs/iostreams/doc/acknowledgments.html: *A* unlinked file libs/iostreams/doc/concepts/multi-character.html: *A* unlinked file |iterator| libs/iterator/doc/filter_iterator_ref.html: *A* unlinked file libs/iterator/doc/indirect_iterator_ref.html: *A* unlinked file libs/iterator/doc/issues.html: *A* unlinked file libs/iterator/doc/iter-issue-list.html: *A* unlinked file libs/iterator/doc/iterator_adaptor_ref.html: *A* unlinked file libs/iterator/doc/make_filter_iterator.html: *A* unlinked file libs/iterator/doc/ref_problem.html: *A* unlinked file |lambda| boost/lambda/core.hpp: *U* unnamed namespace at line 62 boost/lambda/detail/lambda_functors.hpp: *U* unnamed namespace at line 25 boost/lambda/exceptions.hpp: *U* unnamed namespace at line 24 |libs| libs/libraries.htm: *A* broken link: math/octonion/index.html *A* broken link: math/quaternion/index.html *A* broken link: math/special_functions/index.html |more| more/feature_model_diagrams.htm: *A* broken link: FeatureDescriptions more/version_history.html: *A* broken link: ../doc/html/date_time/date_time_io.html *A* broken link: ../doc/html/date_time/details.html#date_time.changes *A* broken link: ../doc/html/date_time/local_time.html *A* broken link: ../libs/math/octonion/index.html *A* broken link: ../libs/math/quaternion/index.html *A* broken link: ../libs/math/special_functions/index.html |mpl| boost/mpl/alias.hpp: *U* unnamed namespace at line 17 |multi_array| boost/multi_array/base.hpp: *U* unnamed namespace at line 69 libs/multi_array/test/generative_tests.hpp: *U* unnamed namespace at line 57 |numeric| boost/numeric/conversion/detail/old_numeric_cast.hpp: *M* violation of Boost min/max guidelines on line 159 *M* violation of Boost min/max guidelines on line 192 |parameter| libs/parameter/doc/html/index.html: *A* broken link: ../../../libs/bind/index.html *A* broken link: ../../../property_map/doc/ReadWritePropertyMap.html *A* broken link: ../../../property_map/doc/ReadablePropertyMap.html *A* broken link: tag::index *A* broken link: tag::name |ptr_container| libs/ptr_container/doc/tutorial_example.html: *A* unlinked file |regex| libs/regex/performance/input.html: *A* unlinked file |regression| regression/.htaccess: *N* leading character of one of the path compontents is not alphabetic tools/regression/xsl_reports/xsl/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: *A* unlinked file |serialization| libs/serialization/src/basic_xml_grammar.ipp: *U* unnamed namespace at line 43 |spirit| boost/spirit/utility/rule_parser.hpp: *U* unnamed namespace at line 70 libs/spirit/test/impl/string_length.hpp: *U* unnamed namespace at line 16 |test| boost/test/floating_point_comparison.hpp: *U* unnamed namespace at line 206 *U* unnamed namespace at line 228 boost/test/impl/cpp_main.ipp: *U* unnamed namespace at line 42 boost/test/impl/exception_safety.ipp: *U* unnamed namespace at line 400 boost/test/impl/framework.ipp: *U* unnamed namespace at line 199 boost/test/impl/plain_report_formatter.ipp: *U* unnamed namespace at line 45 boost/test/impl/progress_monitor.ipp: *U* unnamed namespace at line 38 boost/test/impl/results_collector.ipp: *U* unnamed namespace at line 106 boost/test/impl/results_reporter.ipp: *U* unnamed namespace at line 48 boost/test/impl/unit_test_log.ipp: *U* unnamed namespace at line 79 boost/test/impl/unit_test_monitor.ipp: *U* unnamed namespace at line 35 boost/test/impl/unit_test_parameters.ipp: *U* unnamed namespace at line 50 boost/test/results_collector.hpp: *U* unnamed namespace at line 40 boost/test/test_tools.hpp: *U* unnamed namespace at line 255 boost/test/utils/iterator/token_iterator.hpp: *U* unnamed namespace at line 166 boost/test/utils/named_params.hpp: *U* unnamed namespace at line 216 boost/test/utils/runtime/cla/dual_name_parameter.ipp: *U* unnamed namespace at line 43 boost/test/utils/runtime/cla/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/env/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/file/config_file.hpp: *U* unnamed namespace at line 169 *U* unnamed namespace at line 64 *U* unnamed namespace at line 74 boost/test/utils/runtime/file/config_file_iterator.hpp: *U* unnamed namespace at line 68 boost/test/utils/trivial_singleton.hpp: *U* unnamed namespace at line 52 *U* unnamed namespace at line 61 libs/test/build/msvc71_proj/config_file_iterator_test.vcproj: *N* filename > 31 chars libs/test/doc/components/prg_exec_monitor/index.html: *A* broken link: ../../../../../boost/test/cpp_main.hpp libs/test/doc/components/test_tools/index.html: *A* broken link: ../../tests/boost_check_equal_str.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_CLOSE.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_MESSAGE.html: *A* broken link: BOOST_MESSAGE.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_SMALL.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/tools_list.html: *A* broken link: ../../btl1.gif *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/utf/components/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/components/test_case/abstract_interface.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/auto_register_facility.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/tc_template.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/custom_log_formatter.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_result/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_suite/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/index.html: *A* broken link: getting_started/index.html libs/test/doc/components/utf/parameters/build_info.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/catch_system_errors.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/detect_memory_leaks.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/no_result_code.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/output_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/random.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_format.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/show_progress.html: *A* broken link: ../../btl1.gif libs/test/doc/examples/unit_test_example1.html: *A* broken link: ../../example/unit_test_example1.cpp libs/test/doc/examples/unit_test_example2.html: *A* broken link: ../../example/unit_test_example2.cpp libs/test/doc/examples/unit_test_example3.html: *A* broken link: ../../example/unit_test_example3.cpp libs/test/doc/examples/unit_test_example4.html: *A* broken link: ../../example/unit_test_example4.cpp libs/test/doc/examples/unit_test_example5.html: *A* broken link: ../../example/unit_test_example5.cpp *A* broken link: ../../example/unit_test_example5.input libs/test/doc/tests/auto_unit_test_test.html: *A* broken link: ../../test/auto_unit_test_test.cpp libs/test/doc/tests/auto_unit_test_test_mult.html: *A* broken link: ../../test/auto_unit_test_test_mult1.cpp *A* broken link: ../../test/auto_unit_test_test_mult2.cpp libs/test/doc/tests/unit_test_suite_ex_test.html: *A* broken link: ../../test/unit_test_suite_ex_test.cpp libs/test/doc/tutorials/hello_the_testing_world.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../execution_monitor/index.html libs/test/doc/tutorials/new_year_resolution.html: *A* broken link: ../../../../../../LICENSE_1_0.txt |thread| libs/thread/src/mutex.inl: *U* unnamed namespace at line 13 libs/thread/src/timeconv.inl: *U* unnamed namespace at line 13 libs/thread/test/util.inl: *U* unnamed namespace at line 24 |type_traits| libs/type_traits/cxx_type_traits.htm: *A* unlinked file |typeof| boost/typeof/encode_decode.hpp: *U* unnamed namespace at line 13 libs/typeof/test/odr.hpp: *U* unnamed namespace at line 12
Peter Dimov wrote:
Rene Rivera wrote:
[...]
42 usages of unnamed namespaces in headers (including .ipp files)
bind (1)
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now.
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard? -Thorsteb
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote
42 usages of unnamed namespaces in headers (including .ipp files)
bind (1)
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now.
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
ODR is potentially violated :-( Having said this, typeof also uses unnamed namespace in the header by design. Regards, Arkadiy
Peter Dimov wrote:
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now. If you add a comment containing 'boostinspect:nounnamed' with a quick explanation, inspect will stop complaining.
Arkadiy Vertleyb wrote:
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
ODR is potentially violated :-(
Apparently, it also causes problems with precompiled headers: http://thread.gmane.org/gmane.comp.lib.boost.devel/145539 I think that all such policies should be explained, probably in more/lib_guide.htm. I'm not volunteering to write a rationale because I'm not sure that I agree with the policy. Does anyone think it's worth writing? Daniel
Arkadiy Vertleyb wrote:
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote
42 usages of unnamed namespaces in headers (including .ipp files)
bind (1)
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now.
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
ODR is potentially violated :-(
How? -Thorsten
Arkadiy Vertleyb wrote:
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote
42 usages of unnamed namespaces in headers (including .ipp files)
bind (1)
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now.
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
ODR is potentially violated :-(
How?
Suppose you have a class A defined inside unnamed namespace (in a header). Suppose you also have a class B defined in terms of class A, but not inside unnamed namespace (in the same or another header). Now, if two translation units use the class B, the same class (B) is defined differently in these translation units (since unnamed namespaces are different and so B uses different A). Typeof has a specific test causing this condition. So far no compilers complained. Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Arkadiy Vertleyb wrote:
"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote
42 usages of unnamed namespaces in headers (including .ipp files)
bind (1)
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now.
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
ODR is potentially violated :-(
How?
Suppose you have a class A defined inside unnamed namespace (in a header). Suppose you also have a class B defined in terms of class A, but not inside unnamed namespace (in the same or another header).
Now, if two translation units use the class B, the same class (B) is defined differently in these translation units (since unnamed namespaces are different and so B uses different A).
Typeof has a specific test causing this condition. So far no compilers complained.
The difference is that in the case of Typeof, the ODR violation is buried inside the library implementation. The library developers can keep it hidden from users and are aware of the possible dangers. In the case of bind, we're (almost) ensuring that its users will create their own ODR violations, and we don't tell them there's any danger. That's a bigger concern to me, for some reason. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Peter Dimov wrote:
Rene Rivera wrote:
[...]
42 usages of unnamed namespaces in headers (including .ipp files)
bind (1)
I'm not sure what I'm expected to do about that one. Bind has been using an unnamed namespace for its placeholders for quite a while now.
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
Thorsten, this is not addressed to you, but I find shameful that so many boosters don't know this C++ 101. Especially so when you consider the arrogance with which many of them act (there are at least four or five egos here who behave as if they were the absolute source of computer science knowledge). FWIW, I added the check to the inspect tool. It was aimed at fixing one particular bad practice in boost code, but it really is like a drop in the ocean, so feel free to remove it (certainly it should if nobody understands what is it for). -- [ Gennaro Prota. C++ developer, Library designer. ] [ For Hire http://gennaro-prota.50webs.com/ ]
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
Thorsten, this is not addressed to you, but I find shameful that so many boosters don't know this C++ 101.
Now, now, Genny. I don't recall anyone ever talking about the problem until I raised it a year or two ago. That's surely not enough time to make it into the entry level C++ courses. I doubt it's even reached mainstream Herb-Sutter-level (advanced) dissemination yet.
Especially so when you consider the arrogance with which many of them act (there are at least four or five egos here who behave as if they were the absolute source of computer science knowledge).
<clears throat loudly>
FWIW, I added the check to the inspect tool. It was aimed at fixing one particular bad practice in boost code, but it really is like a drop in the ocean, so feel free to remove it (certainly it should if nobody understands what is it for).
That would be a bad idea, IMO. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 14 Sep 2006 07:00:26 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
Thorsten, this is not addressed to you, but I find shameful that so many boosters don't know this C++ 101.
Now, now, Genny. I don't recall anyone ever talking about the problem until I raised it a year or two ago.
And here's the ego I was talking about. You may feel like the first man who brought the light on all us, but that light is common advice for any comp.lang.c++.moderated regular. I guess I learned the facts from Francis Glassborow at least four years ago; and several modern books mention the problem: I'm sure about Sutter/Alexandrescu but there are others, I just don't have time to check. In any case I can't see any post in this thread which gives the correct explanation (it seems that my newsreader have missed some message though --probably one between Arkadiy's and yours). And I really want to clarify that Thorsten attitude is absolutely ok: he is asking what the problem is. What's wrong is the attitude of those who think they know the reason without realizing they do not. -- [ Gennaro Prota. C++ developer, Library designer. ] [ For Hire http://gennaro-prota.50webs.com/ ]
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Thu, 14 Sep 2006 07:00:26 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
Thorsten, this is not addressed to you, but I find shameful that so many boosters don't know this C++ 101.
Now, now, Genny. I don't recall anyone ever talking about the problem until I raised it a year or two ago.
And here's the ego I was talking about. You may feel like the first man who brought the light on all us,
Hey, now, back off. That's not ego, that's just my recollection.
but that light is common advice for any comp.lang.c++.moderated regular.
I thought of myself as a regular there, but I hadn't seen this advice. That's the truth. For what it's worth, I can find a mention of eschewing anonymous namespaces in header files from Francis in Jan 2004, which is about 6 months before I started posting about it. However, that posting does not mention the ODR and does little to clarify (for me) why it might be a bad idea. Anyway, I don't need credit for discovering anything here. My only point is that it's easy to be very involved in the community and still never encounter the unnamed-namespace-in-header/ODR issue. IMO, we ought to cut everyone some slack and just keep working on education. There's no shame in ignorance unless it's wilfull. BTW, for anyone who still wants an explanation of the issues, I dug up my original post: http://article.gmane.org/gmane.comp.lib.boost.devel/104728
I guess I learned the facts from Francis Glassborow at least four years ago; and several modern books mention the problem: I'm sure about Sutter/Alexandrescu but there are others, I just don't have time to check.
FWIW, Sutter/Alexandrescu don't mention the ODR either; they just talk about the amount of space generated in your program by repeated definitions. If you were to read their advice you might think that in general it's a bad idea to put objects with external linkage in a header, but that what we're doing with the bind placeholders is OK.
In any case I can't see any post in this thread which gives the correct explanation
I hope my link above works well enough in that department.
(it seems that my newsreader have missed some message though --probably one between Arkadiy's and yours). And I really want to clarify that Thorsten attitude is absolutely ok: he is asking what the problem is. What's wrong is the attitude of those who think they know the reason without realizing they do not.
Now you've really lost me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Gennaro Prota wrote:
On Thu, 14 Sep 2006 07:00:26 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
Thorsten, this is not addressed to you, but I find shameful that so many boosters don't know this C++ 101.
Now, now, Genny. I don't recall anyone ever talking about the problem until I raised it a year or two ago.
And here's the ego I was talking about. You may feel like the first man who brought the light on all us, but that light is common advice for any comp.lang.c++.moderated regular.
Not quite... the general advice against putting unnamed namespaces in headers is one thing, explaining how the constant variable (unnamed)::_1 technically causes ODR violations is another. In practice, Bind is getting away with this kind of a technical ODR violation on every supported compiler. But my question wasn't about ODR violations or egos. I asked what is the proper course of action for a library developer whose library has been flagged by the report. And it seems that nobody knows. I can remove the unnamed namespace (at some cost) but this is a potentially destabilizing change and not suited for 1.34, against which the report is being run.
Peter Dimov wrote:
But my question wasn't about ODR violations or egos. I asked what is the proper course of action for a library developer whose library has been flagged by the report. And it seems that nobody knows. I can remove the unnamed namespace (at some cost) but this is a potentially destabilizing change and not suited for 1.34, against which the report is being run.
And at this point the only concern should be regressions anyway, right ? Regards, Stefan
"Peter Dimov" <pdimov@mmltd.net> writes:
Gennaro Prota wrote:
On Thu, 14 Sep 2006 07:00:26 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Wed, 13 Sep 2006 22:00:09 +0200, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
What is the problem with an unnamed namespace in a header anyway? Is it illegal according to the standard?
Thorsten, this is not addressed to you, but I find shameful that so many boosters don't know this C++ 101.
Now, now, Genny. I don't recall anyone ever talking about the problem until I raised it a year or two ago.
And here's the ego I was talking about. You may feel like the first man who brought the light on all us, but that light is common advice for any comp.lang.c++.moderated regular.
Not quite... the general advice against putting unnamed namespaces in headers is one thing, explaining how the constant variable (unnamed)::_1 technically causes ODR violations is another.
In practice, Bind is getting away with this kind of a technical ODR violation on every supported compiler.
Yes, and let me support that assertion by saying it's probably going to continue to work on every C++ compiler we ever encounter. Maybe some fancy lint tool would be able to detect it. It's really only a technical violation of the standard. But that said, I don't like the idea of, entrapment even if the crime commited is victimless... or something. I hope y'all see my point.
But my question wasn't about ODR violations or egos. I asked what is the proper course of action for a library developer whose library has been flagged by the report. And it seems that nobody knows. I can remove the unnamed namespace (at some cost) but this is a potentially destabilizing change and not suited for 1.34, against which the report is being run.
I agree. I think you should put the report silencing directive in the RC_1_34_0 branch only, with a note saying that we will address it in the next release. How does that sound to you? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 14 Sep 2006 21:36:14 +0300, "Peter Dimov" <pdimov@mmltd.net> wrote:
Not quite... the general advice against putting unnamed namespaces in headers is one thing, explaining how the constant variable (unnamed)::_1 technically causes ODR violations is another.
Maybe, but I think the point is understanding that the compiler-generated name of an unnamed namespace is unique per translation unit, not per source file (and I can't think of any way a book or, say, a C++ course can explain -- for a proper meaning of "explain" :-) -- them without making the distinction clear; that's why I consider it 101). All the rest is a consequence. If I understand correctly the idiomatic expression "back off" it means "stop here" or something like that. Well, I'll do, as I don't think this discussion is actually useful to anyone. -- Gennaro.
"Gennaro Prota" <gennaro_prota@yahoo.com> wrote
In any case I can't see any post in this thread which gives the correct explanation (it seems that my newsreader have missed some message though --probably one between Arkadiy's and yours). And I really want to clarify that Thorsten attitude is absolutely ok: he is asking what the problem is. What's wrong is the attitude of those who think they know the reason without realizing they do not.
I thought I pretty much understand the issue (after David explained it to me a couple of years ago, when I just started playing with typeof, and after I spent quite some time trying to work it around, although with no success), otherwise I wouldn't have tried to explain it in this thread. Since I am apparently one of those who don't realize their ignorance, I would like to see the correct explanation. Would you care to provide one? Regards, Arkadiy
participants (8)
-
Arkadiy Vertleyb -
Daniel James -
David Abrahams -
Gennaro Prota -
Peter Dimov -
Rene Rivera -
Stefan Seefeld -
Thorsten Ottosen