Some time ago I've posted some bugs in date_time, and format libraries. There is no answer, there is no fix, there is no any reaction at all. The only two authors reacts and have applied suggested fixes: Hartmut Kaiser has fixed problem with select_p in spirit and Robert Ramey has partially fixed problem with ADL and vc7.1 in serialization. All others bugs are unanswered. But release is going to be issued. Why this? What is the bugs policy? Release is going to contain known bugs? -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
And someone should look at the random library. There are some issues I stumble regulary: 1) <cmath> must be included before <boost/random.hpp> (GCC 3.4.2), otherwise some errors arise: "'std::pow' has not been declared" and friends 2) There ist one documented operator in uniform_int which does not exist in the headers: result_type operator()(UniformRandomNumberGenerator& urng, result_type n) Regards, V. Peters
Viktor Peters wrote:
And someone should look at the random library. There are some issues I stumble regulary:
1) <cmath> must be included before <boost/random.hpp> (GCC 3.4.2), otherwise some errors arise: "'std::pow' has not been declared" and friends
I think I've committed such a change some time ago, after running into a trouble myself. Do you still get errors on 1.32 release candidate? - Volodya
1) <cmath> must be included before <boost/random.hpp> (GCC 3.4.2), otherwise some errors arise: "'std::pow' has not been declared" and friends
I think I've committed such a change some time ago, after running into a trouble myself. Do you still get errors on 1.32 release candidate?
Yes you are right. This error is gone in 1.32 release candidate. I should have looked closer. Sorry... -- V. Peters
Viktor Peters writes:
And someone should look at the random library. There are some issues I stumble regulary:
1) <cmath> must be included before <boost/random.hpp> (GCC 3.4.2), otherwise some errors arise: "'std::pow' has not been declared" and friends
2) There ist one documented operator in uniform_int which does not exist in the headers: result_type operator()(UniformRandomNumberGenerator& urng, result_type n)
These should have been reported earlier. It's too late for 1.32. -- Aleksey Gurtovoy MetaCommunications Engineering
Some time ago I've posted some bugs in date_time, and format libraries. There is no answer, there is no fix, there is no any reaction at all. The only two authors reacts and have applied suggested fixes: Hartmut Kaiser has fixed problem with select_p in spirit and Robert Ramey has partially fixed
The report suggested changes in a serialization library header and a config header for VC 7.1. I concluded that the issue with the serialization library was a valid one - although it didn't show up in any testing, and removed some leftover useless code. Another suggestion was to define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for VC 7.1 . a) I didn't feel sufficiently knowledgable to evaluate such a proposal. b) It seemed (and still seems) pretty radical to me. c) Such a change would have to be made only after thorough investigation of any vagarities in VC 7.1 implementation of ADL. I suspect that no one has been able to justify this effort. Robert Ramey "Vyacheslav E. Andrejev" <vandrejev@excelsior-usa.com> wrote in message news:cn9jjv$thq$1@sea.gmane.org... problem with ADL and vc7.1 in serialization. All others bugs are unanswered. But release is going to be issued. Why this? What is the bugs policy? Release is going to contain known bugs?
-- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
_______________________________________________ Unsubscribe & other changes:
Hello Robert, RR> The report suggested changes in a serialization library header and a RR> config header for VC 7.1. RR> RR> I concluded that the issue with the serialization library was a RR> valid one - although it didn't show up in any testing, and removed RR> some leftover useless code. Sorry, but your removal didn't fully eliminate the problem. In large enough project the problem comes up eventually. RR> RR> Another suggestion was to define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP RR> for VC 7.1 . RR> RR> a) I didn't feel sufficiently knowledgable to evaluate such a RR> proposal. RR> b) It seemed (and still seems) pretty radical to me. RR> c) Such a change would have to be made only after thorough RR> investigation of RR> any vagarities in VC 7.1 implementation of ADL. I suspect that no RR> one has RR> been able to justify this effort. RR> Robert Ramey Yes, your're right. But this preprocessor macro is used only in one place of the whole boost, namely in serialization library. What were the reasons to put load and save methods for collections to std namespace? This is a root of evil. We may not define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for vc7.1, but simply put load and save to boost::serialization for vc7.1. I think, that code that you have removed, was intended exactly for this purposes, but were written with error. May be right decision would be not to remove the code, but instead accuratly rewrite it in order to place load and save in serialization namespace specailly for vc7.1. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
Vyacheslav E. Andrejev wrote:
I concluded that the issue with the serialization library was a valid one - although it didn't show up in any testing, and removed some leftover useless code.
Sorry, but your removal didn't fully eliminate the problem. In large enough project the problem comes up eventually.
Another suggestion was to define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for VC 7.1 .
a) I didn't feel sufficiently knowledgable to evaluate such a proposal. b) It seemed (and still seems) pretty radical to me. c) Such a change would have to be made only after thorough investigation of any vagarities in VC 7.1 implementation of ADL. I suspect that no one has been able to justify this effort. Robert Ramey
Yes, your're right. But this preprocessor macro is used only in one place of the whole boost, namely in serialization library.
Out of curiosity, what ADL-related problems are you experiencing with VC 7.1? I'm not aware of any. Templated inline friends sometimes confuse the code generator, but this doesn't seem to be the issue here.
Hello Peter, PD> Vyacheslav E. Andrejev wrote: PD>
I concluded that the issue with the serialization library was a valid one - although it didn't show up in any testing, and removed some leftover useless code.
Sorry, but your removal didn't fully eliminate the problem. In large enough project the problem comes up eventually.
Another suggestion was to define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for VC 7.1 .
a) I didn't feel sufficiently knowledgable to evaluate such a proposal. b) It seemed (and still seems) pretty radical to me. c) Such a change would have to be made only after thorough investigation of any vagarities in VC 7.1 implementation of ADL. I suspect that no one has been able to justify this effort. Robert Ramey Yes, your're right. But this preprocessor macro is used only in one place of the whole boost, namely in serialization library.
PD> Out of curiosity, what ADL-related problems are you experiencing PD> with VC 7.1? I'm not aware of any. Templated inline friends PD> sometimes confuse the code generator, but this doesn't seem to be PD> the issue here.
boost::serialization has load and save template functions defined in std namespace for serialization of std collections. These functions are specialized for every std collection and are called from serialization namespace. Sometimes (by very curious conditions) vc7.1 compiler injects into object code calls to them just like they are in serialization namespace (i.e. ADL fails), consequently linker generates error that it can not find serialization::load or/and serialization::save. This problem was reported by me in boost.devel 09.11.2004 (Message-ID: <cmq7ir$64n$1@sea.gmane.org>) and by Delfin Rojas in boost.user 10.11.2004 (Message-ID: <200411101619.iAAGJnji009552@patti.moodlogic.com>). Problem appears in very subtle hardly reproducible conditions. For example, in my project it appeared when I add additional insert to set collection. Something like this set<my_type> p1, p2; p1.insert(my_type()); p2.insert(my_type()); // without this line all works fine Note, that in the rest of code this set never had been serialized at all, even set<my_type> didn't, actually list<my_type> is that suffered serialization. Further experiments with code led to the compiler internal error. Since I was limited in time, I simply edit serialization library to put load and save by force into serialization namespace. After this everything became ok.
From this I supposed that ADL in vc7.1 unstable because of some internal compiler errors.
-- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
"Vyacheslav E. Andrejev" <vandrejev@excelsior-usa.com> wrote in message news:cnf21s$124$1@sea.gmane.org...
Hello Robert,
Yes, your're right. But this preprocessor macro is used only in one place of the whole boost, namely in serialization library.
LOL - that amazes me. I guess I'm just lucky.
What were the reasons to put load and save methods for collections to std namespace? This is a root of evil.
We may not define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for vc7.1, but simply put load and save to boost::serialization for vc7.1. I think, that code that you have removed, was intended exactly for this purposes, but were written with error. May be right decision would be not to remove the code, but instead accuratly rewrite it in order to place load and save in serialization namespace specailly for vc7.1.
Your analysis and understanding are correct on this. Here is how we came to be here. a) originally everything was in the boost::serialization namespace and the serialization library code specifically used the boost::serialization namespace. This required user specializations to be in the boost::serialization namespace as well. b) Some people complained but it was OK by me and I was resolved to defer adjustments to a future release (at that time release branching was scheduled for 28 July 2004 !!!). c) I ran tests with the codewarrior compiler 9.2 - everything using export bombed. It seems that this is the only compiler I used that implemented two-phase lookup. So specializations subsequent to the definiation of of the default one in the serialization header wouldn't be found. The implementation of export functionality required that headers be in a certain order so I couldn't easily fix this problem. d) the "fix" was to rely upon the fact that there are no compilers which implement two-phase lookup and do not implement ADL. So the requirement was imposed that specializations be part of the same name space of the data-type to be serialized for those compilers which implement it. e) the REAL fix is to re-implement the export functionality so it doesn't require the current header sequence. This would permit specializations to be in boost::serialization or, for compilers supporting ADL, in the same namespace as either the archive type or that of the type to be serialized. This fix is certainly not trivial. I briefly considered one idea but rejected for reasons I don't remember now. f) After implementing e) above, the serialization library would no longer depend upon BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP and I would be off that hook. I hope this answers your question. Its not that there's a reluctance to fix things, its just that by the time on considers all the reasons that things are the way they are, it isn't obvious how to fix something. Robert Ramey P.S. want to hear something funny? After going through all this codewarrior compiler doesn't build programs which use the serialization export functionality. This is due to a compiler feature which removes all code not explicitly referenced by name. That is, an overzealous optimization. Heroic efforts have failed to resolve this issue for this compiler. Arrrrrrrgggggggghhhhhhh.
Hello Robert, RR> "Vyacheslav E. Andrejev" <vandrejev@excelsior-usa.com> wrote in RR> message news:cnf21s$124$1@sea.gmane.org... RR>
Hello Robert,
Yes, your're right. But this preprocessor macro is used only in one place of the whole boost, namely in serialization library. RR> RR> LOL - that amazes me. I guess I'm just lucky. RR> Shame on me. Some more libraries actually uses it (math, graph and python). First time I have checked not all boost but only part that is used in my project.
RR> I hope this answers your question. Its not that there's a RR> reluctance to fix things, its just that by the time on considers all RR> the reasons that things are the way they are, it isn't obvious how RR> to fix something. Yes, I understand. In a mean time I've found own solution for the problem, I wrote a script that fixes library in the way I need after downloading from cvs prior to adding to my project :). RR> P.S. want to hear something funny? After going through all this RR> codewarrior RR> compiler doesn't build programs which use the serialization export RR> functionality. This is due to a compiler feature which removes all RR> code not RR> explicitly referenced by name. That is, an overzealous RR> optimization. RR> Heroic efforts have failed to resolve this issue for this compiler. RR> Arrrrrrrgggggggghhhhhhh. It is sad. I also have experinced many "funny" things when fought with vc7.1 :). One good thing I heard (rumours may be) that MS uses boost for regression tests of their new compiler, it raises hope in my breast :). Regards. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
Vyacheslav E. Andrejev writes:
Some time ago I've posted some bugs in date_time, and format libraries. There is no answer, there is no fix, there is no any reaction at all.
In most cases reposting your query helps to get the attention of the corresponding maintainers. They might have just trivially missed your post(s).
The only two authors reacts and have applied suggested fixes: Hartmut Kaiser has fixed problem with select_p in spirit and Robert Ramey has partially fixed problem with ADL and vc7.1 in serialization. All others bugs are unanswered.
Please see the above.
But release is going to be issued. Why this?
We try to collect the patches that fell on the floor during the release preparation, but given the amount of traffic on the list and the sheer volume of issues developers have to deal with during this period, some times things still slip through. If it's critical for you that the bug is addressed in the next release, please consider to be more persistent in getting your message heard.
What is the bugs policy?
The policy is "No regressions".
Release is going to contain known bugs?
Some, most definitely. Do you know any software that doesn't? -- Aleksey Gurtovoy MetaCommunications Engineering
participants (6)
-
Aleksey Gurtovoy -
Peter Dimov -
Robert Ramey -
Viktor Peters -
Vladimir Prus -
Vyacheslav E. Andrejev