Re: My code does crash, but not as often as you think.
We have been spending a lot of time decising the kinds of operations we need to do on a BigAssClass, or a BigAssOrderedType. Your preceding paragraph specified what we want to be able to do. Now, given the tools available to do that, we start planning how to do it.
Well, unfortunately, when you define that max function in terms of T, you know have to keep in the back of your mind the potential effects of calling max(SomethingYouDidntReallyThinkThatHardAbout,SomethingElseYouDidntReallyThinkThatHardAbout);
IOW, that template mechanism paints with an infinitely broad brush and you now have to understand its exact expansion, along with expansions of any possible specializations you have (or your team mate wrote and didn't tell you about), and any automatic type conversion operators you've written along with any single argument constructurs you have.
To illustrate this, allow me to tell you about a short little gig I had as a porting engineer. During a development cycle when everybody was working on windows (except me, 'cause I just don't do windows), I would check out the code every morning and spend hours trying to build it - fixing portability issues and sending out hate mail to the team about some of their stupid assumptions.
One day I hit a compile error on something like:
CustomString str = "foo";
... return foo + "bar";
I looked up the developer and showed him the header for CustomString (this is before stl compiled anywhere other than Borland btw) and pointed out that there was no operator+ implemented on CustomString. He seemed perplexed because it worked fine on Windows. And so it did. As CustomString had an operator const char* defined, the MSString object had a ctor for const char*, an operator+, and an operator const char*. As we traced the execution we found that the compiler on windows had figured out it could construct a temp MSString (whatever they call it, I forget), do the operator+, then construct CustomString temp off the MSString's operator const char*.
Something like that - but the type conversions/automatic operator calls were several layers deep and of course there is no MSString for unix.
This lead me to conclude that the C++ type system is too complex for any human to predict what will happen for a given bit of code, and the introduction of a single function linking a couple types together and have far reaching unintended consequences on the system's overall behavior.
Thus, I boldly make the statement "C++ doesn't scale".
Re: My code does crash, but not as often as you think.
We have been spending a lot of time decising the kinds of operations we need to do on a BigAssClass, or a BigAssOrderedType. Your preceding paragraph specified what we want to be able to do. Now, given the tools available to do that, we start planning how to do it.
Well, unfortunately, when you define that max function in terms of T, you know have to keep in the back of your mind the potential effects of calling max(SomethingYouDidntReallyThinkThatHardAbout,SomethingElseYouDidntReallyThinkThatHardAbout);
IOW, that template mechanism paints with an infinitely broad brush and you now have to understand its exact expansion, along with expansions of any possible specializations you have (or your team mate wrote and didn't tell you about), and any automatic type conversion operators you've written along with any single argument constructurs you have.
To illustrate this, allow me to tell you about a short little gig I had as a porting engineer. During a development cycle when everybody was working on windows (except me, 'cause I just don't do windows), I would check out the code every morning and spend hours trying to build it - fixing portability issues and sending out hate mail to the team about some of their stupid assumptions.
One day I hit a compile error on something like:
CustomString str = "foo";
... return foo + "bar";
I looked up the developer and showed him the header for CustomString (this is before stl compiled anywhere other than Borland btw) and pointed out that there was no operator+ implemented on CustomString. He seemed perplexed because it worked fine on Windows. And so it did. As CustomString had an operator const char* defined, the MSString object had a ctor for const char*, an operator+, and an operator const char*. As we traced the execution we found that the compiler on windows had figured out it could construct a temp MSString (whatever they call it, I forget), do the operator+, then construct CustomString temp off the MSString's operator const char*.
Something like that - but the type conversions/automatic operator calls were several layers deep and of course there is no MSString for unix.
This lead me to conclude that the C++ type system is too complex for any human to predict what will happen for a given bit of code, and the introduction of a single function linking a couple types together and have far reaching unintended consequences on the system's overall behavior.
Thus, I boldly make the statement "C++ doesn't scale".
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
