Re: [boost] Re: Boost to the rescue
In-Reply-To: <6.2.0.14.2.20050417185958.0459b5a0@mail.rudbek.com> vawjr@rudbek.com (Victor A. Wagner Jr.) wrote (abridged):
do you keep all versions of your compiler around forever?
Pretty much. We don't keep them in VCS though. We don't treat them as source code because, well, they are not source code. (Switching to a different compiler vendor would be a much bigger deal than adopting boost so this comparison probably isn't helping your case.)
I didn't want to include anything I couldn't see an immediate use for.
a true forward looking point of view.
That sounds like sarcasm. I've already explained how it is easier to add stuff that was missed that to delete stuff that shouldn't have been added. Also, with broadband internet, the boost documentation so accessible from the web site that it doesn't need to be added locally.
actually you don't need to "understand it" to use it, anymore than you need to understand the workings of the transmission in the auto you drive.
I do need to understand the documentation before I use it, and in the example I cited the documentation is long and complex. Also, I need to debug code, and that often does require understanding how it works. I must be a car mechanic as well as a driver.
I find it difficult to believe that min and or max got "redefined" such that they became unusable (I'm pretty sure it would have shown up in the regression testing. I recall no such incident).
The root problem, as I thought we'd agreed, is that Microsoft wrongly defines them as macros. This means code like: long x = max( 1L, 1 ); works. I found that #including boost reverted to the standard-conforming definition, which meant the above became ambiguous as the 2 arguments have different types. Don't let's pay this issue more attention than it deserves. I doubt boost can do any better than it is doing, here. -- Dave Harris, Nottingham, UK.
At Monday 2005-04-18 03:55, you wrote:
In-Reply-To: <6.2.0.14.2.20050417185958.0459b5a0@mail.rudbek.com> vawjr@rudbek.com (Victor A. Wagner Jr.) wrote (abridged):
do you keep all versions of your compiler around forever?
Pretty much. We don't keep them in VCS though. We don't treat them as source code because, well, they are not source code.
I was unaware that a version control systems was only for source (most use it that way, though). When attempting to build a previous version of a product (to reproduce bug reports) it is often necessary to get the tools that were then in use.
(Switching to a different compiler vendor would be a much bigger deal than adopting boost so this comparison probably isn't helping your case.)
Unfortunately, the version control system we use, doesn't handle multiple repositories very well(not for the same project). Therefore I'm kinda "stuck" with using the repository provided by boost itself (which occupies 0 space on our machines).
I didn't want to include anything I couldn't see an immediate use for.
a true forward looking point of view.
That sounds like sarcasm.
It was, I apologize.
I've already explained how it is easier to add stuff that was missed that to delete stuff that shouldn't have been added. Also, with broadband internet, the boost documentation so accessible from the web site that it doesn't need to be added locally.
Your ISP must be somewhat more reliable than mine. They always seem to be doing maintenance just about the time I need to look something up.
actually you don't need to "understand it" to use it, anymore than you need to understand the workings of the transmission in the auto you drive.
I do need to understand the documentation before I use it, and in the example I cited the documentation is long and complex.
I concur, some of the documentation is almost worthless, IMO. Reference materials are wonderful, but every once in a while one would like to start with a tutorial (one of the reason's I'm so fond of "The C++ Standard Library" by Nicolai Josuttis). To this day, I can make no sense of some of the documents.
Also, I need to debug code, and that often does require understanding how it works. I must be a car mechanic as well as a driver.
to that end, as another has pointed out, one of the problems is all the #ifdef that hang around solely because the compiler vendors have been loath to produce a conforming compiler. I would really like to see an collection of (call them reference designs if you wish) all the Boost files with NO conditional code, just pure standard (I suppose I could wait until C+0x, but I'd rather not) C++. I've pointed out many times before that continuing support for ancient compilers (my favorite to pick on is Microsoft VC++6.0) costs all of us, not just the person who has clients that won't upgrade (folly, IMO) and volunteers to keep _his_ library working on what should have been a dead horse years ago (mixed metaphors are my specialty).
I find it difficult to believe that min and or max got "redefined" such that they became unusable (I'm pretty sure it would have shown up in the regression testing. I recall no such incident).
The root problem, as I thought we'd agreed, is that Microsoft wrongly defines them as macros. This means code like:
long x = max( 1L, 1 );
works. I found that #including boost reverted to the standard-conforming definition, which meant the above became ambiguous as the 2 arguments have different types.
Don't let's pay this issue more attention than it deserves. I doubt boost can do any better than it is doing, here.
I don't see any way out either. Some days I think hanging on to all that old C heritage is just an impediment to getting where we need to go.
-- Dave Harris, Nottingham, UK.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
compilers (my favorite to pick on is Microsoft VC++6.0) costs all of us, not just the person who has clients that won't upgrade (folly, IMO) and
Not really folly, we tried to upgrade to vc2002 two years ago and gave up in the face of multiple optimiser errors generating bogus code (doing nice things like overwriting the return address on the stack), after a while we stopped fighting and stuck with vc6 til we got the project out the door. We have now upgraded to vc2003 and had a similar issue with the optimiser, this time we'll live with it as we have nearly 2 years to deal with it but if we we're still within 6 months of shipping there would be no way we'd change. Never mistake your own development requirements with those of others, some projects live a long a time and compiler stability is a major factor. Martin (and yes I hate vc6 but standards conformity is less of a requirement than correct code generation).
At Tuesday 2005-04-19 04:05, you wrote:
compilers (my favorite to pick on is Microsoft VC++6.0) costs all of us, not just the person who has clients that won't upgrade (folly, IMO) and
Not really folly, we tried to upgrade to vc2002 two years ago and gave up in the face of multiple optimiser errors generating bogus code
vc2003 was out 2 years ago, why did you use the already replaced version?
(doing nice things like overwriting the return address on the stack), after a while we stopped fighting and stuck with vc6 til we got the project out the door. We have now upgraded to vc2003
with it's replacement due for release in 3 months
and had a similar issue with the optimiser, this time we'll live with it as we have nearly 2 years to deal with it but if we we're still within 6 months of shipping there would be no way we'd change. Never mistake your own development requirements with those of others, some projects live a long a time and compiler stability is a major factor.
Stability and wrong aren't that great a combination (though I'm sure your staff has learned not to try anything they read in the literature, or use the STL). Or have you gotten the upgrades directly from Dinkumware?
Martin
(and yes I hate vc6 but standards conformity is less of a requirement than correct code generation).
yeah, it has _great_ code generation.... </sarcasm> if someone has managed to tell you that you'd better get at least SP4 or you've found out the hard way yourself. And, IMO, it's borderline criminal that they've not updated the STL in 6. btw, I've been using 7.1 since it became available, and haven't bumped into any optimization problems, and we compile debug with none, and about everything we can find to turn on in release. Granted there are only 4 of us, but I don't recall any gotchas. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" P.S. It still costs us all money to try to support
vc2003 was out 2 years ago, why did you use the already replaced version?
If you read what I said a bit more carefully you'll understand why not.
(doing nice things like overwriting the return address on the stack), after a while we stopped fighting and stuck with vc6 til we got the project out the door. We have now upgraded to vc2003
with it's replacement due for release in 3 months
And we'll look and evaluate 2005 when it comes, if it's looks good then we'll move, any problems and we won't.
Stability and wrong aren't that great a combination (though I'm sure your staff has learned not to try anything they read in the literature, or use the STL). Or have you gotten the upgrades directly from Dinkumware?
Stability is everything, lack of conformance we can code around easily as the compiler tells us at build time, bad code generation we have to wait until runtime to *maybe* find it in testing before release.
yeah, it has _great_ code generation.... </sarcasm> if someone has
Cut the sarcasm please, you really are just plain rude at times and it has a habit of clouding any valid points you may have. Its code generation never caused the return address to be overwritten (vc2002) or the vtable to be overwritten (vc2003).
btw, I've been using 7.1 since it became available, and haven't bumped into any optimization problems, and we compile debug with none, and about everything we can find to turn on in release. Granted there are only 4 of us, but I don't recall any gotchas.
Which just show's what limited experience you have in these things and why you should not try to tell others how to manage their products which are probably in a completely different market to your own. We have a great deal of code and at times had 15-16 developers working on it over a four year period and we have found optmisation bugs in the last 2 vc compilers and the current intel compiler and none in vc6, these are not easy to create small repros for and with the update schedule of vc at the moment are not going to fixed quickly. And when we are trying to get a product ready for final release we are definitely not going to change compilers if there are *any* problems in sight. cheers Martin
P.S. It still costs us all money to try to support
Oh and at no point did I say that I think boost should support vc6, regardless of that fact that it costs users (or us testers) nothing to support it except maybe a few more seconds to parse a couple of #def's or download a fraction more code. It costs the implementers time and that is there own personal choice at the end of the day; not yours, mine or anyone elses. Martin
At Tuesday 2005-04-19 16:50, you wrote:
P.S. It still costs us all money to try to support
Oh and at no point did I say that I think boost should support vc6, regardless of that fact that it costs users (or us testers) nothing to support it except maybe a few more seconds to parse a couple of #def's or download a fraction more code. It costs the implementers time and that is there own personal choice at the end of the day; not yours, mine or anyone elses.
we went through this once before. It costs the testers and it's not just a few seconds (or maybe you don't look at your results to see if something YOU have done screwed up). Thank you for your help in doing the regression tests, by the way. But you're dreaming if you think that some developer screwing up something in his/her zeal to support vc6 costs nobody else.
Martin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
we went through this once before. It costs the testers and it's not just a few seconds (or maybe you don't look at your results to see if something YOU have done screwed up).
Erm what could I possibly do to screw it up? Since i set it up the initial time I haven't had to touch it at all, it just runs as a scheduled task and all is good. check the regression reports maybe 2/3 times a week to make sure that it hasn't stopped working and monitor the test mailing list to see if anyone raises an issue. If the regression fails or not is of no real concern to me in the sense that its going to make me go and fix things, thats the developers job, testing is just a very small way I can say thank you for the hard work that has gone into the libraries. If there is a problem and for some reason they don't have access to the compiler I test on then at that point I'd be more than happy to work with them to try and solve it. Or was there something else you were thinking about? cheers Martin
At Wednesday 2005-04-20 02:28, Martin Slater wrote:
we went through this once before. It costs the testers and it's not just a few seconds (or maybe you don't look at your results to see if something YOU have done screwed up).
Erm what could I possibly do to screw it up? Since i set it up the initial time I haven't had to touch it at all, it just runs as a scheduled task and all is good. check the regression reports maybe 2/3 times a week to make sure that it hasn't stopped working and monitor the test mailing list to see if anyone raises an issue. If the regression fails or not is of no real concern to me in the sense that its going to make me go and fix things, thats the developers job, testing is just a very small way I can say thank you for the hard work that has gone into the libraries. If there is a problem and for some reason they don't have access to the compiler I test on then at that point I'd be more than happy to work with them to try and solve it.
Or was there something else you were thinking about?
Martin Wille pretty much said it all
cheers
Martin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Martin Slater wrote:
P.S. It still costs us all money to try to support
Oh and at no point did I say that I think boost should support vc6, regardless of that fact that it costs users (or us testers) nothing to support it except maybe a few more seconds to parse a couple of #def's or download a fraction more code. It costs the implementers time and that is there own personal choice at the end of the day; not yours, mine or anyone elses.
That's not correct. In fact, supporting VC6 or gcc 2 costs a lot of CPU time for the testers. It's not only the additional toolsets to run tests for (which could be considered a personal choice of the tester); more importantly, it's the frequency of changes to the source code in order to make modern code work for a bunch of broken compilers. These changes trigger rebuilds for *all* toolsets. Regards, m
That's not correct. In fact, supporting VC6 or gcc 2 costs a lot of CPU time for the testers.
I've never paid for my cpu time so I'm not sure what the issue is here. Tests for me start at about 10pm and they have approximately 10 hours to complete. It makes zero difference to me if it takes 2 hours or the full 10. If its still not complete by the time I get to the office then it'll probably just be nuked so I can get on with some work but that has not happened since I got my intial teething problems ironed out. To put it another way, if the developer chooses to support older compilers then I am more than happy to let it trigger tests. Sooner or later the old compilers will go away and all this discussion will be moot, we just need to keep arguing for another year or so;) Also looking at the regression summary no one is testing vanilla vc6 at the moment anyway so if anyone wants it give me a shout i'll setup for it as well. Martin
Martin Slater writes:
Also looking at the regression summary no one is testing vanilla vc6 at the moment anyway so if anyone wants it give me a shout i'll setup for it as well.
Actually, we do (the toolset name is "msvc"), but we definitely won't protest if somebody picks it up from us. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (5)
-
Aleksey Gurtovoy -
brangdon＠cix.compulink.co.uk -
Martin Slater -
Martin Wille -
Victor A. Wagner Jr.