No, there's nothing preventing you from including that header file multiple times for different types.
Okay, I missed that. However, once you start doing things like including generic functions/classes in other generics, and doing compile-time calculations you're going to have headaches, namely because the C preprocessor only does a single pass on the code.
Back to code length: the C preprocessor version forces you to define multiple constants and include a header for each specialization of the template. Given that C++ can also infer template arguments from function arguments, I would have thought the C++ would be shorter.
The only difference is that with preprocessor macros, you create the class explicitly up front with its own name so the instantiation syntax is cleaner.
My opinion is the complete opposite of this- explicitly having to specialize a template with a bunch of defines and an include each time seems fugly. Perhaps we'll just have to agree to disagree on that one:-)
I have a couple of issues with that code. First, If I want to create multiple CustomArrays of differing base types, in C++ I can do CustomArray<int> ints;
CustomArray<char> chars;
With the C preprocessor, I can only do a single define, and I'm stuck with that single base type. Secondly, That's a _lot_ more code, and it's a _lot_ uglier...
Lastly, about the foreach loop- I can see where you're coming from about it being 'glued on', but i've never really found it to be much of a hindrance. Apparently C++0x has something similar, though.
C++ can't have been what you describe, because of one of the design goals: maintaining backwards-compatibility with C. As soon as you start making arrays behave differently, you break a lot of code. C++'s strength is that it has powerful high-level language features while allowing C's (relatively) low-level stuff.
As for C++'s STL libraries being difficult to use, I have to disagree again. Let's take vector as an example. Elements are accessed the same way as regular arrays (square bracket notation), and the notation for using templates (i.e. vector<int> ints;) is really not difficult. Actually writing template functions is a little harder, though. I am frankly amazed you think the C preprocessor is equivalent in usefulness to templates, so in case i'm being stupid here, would you explain how you implement a generic container using the preprocessor? For that matter, what do you find nicer about the C preprocessor than templates? Littering source code with #defines and #ifdefs surely can't be neater...?
As for OO in PHP, I don't see why you think dynamic typing decreases the value of object-oriented programming.
It's not that I think dynamic typing decreases the value of OO, but that I think OO decreases the value of dynamic typing.
Dynamic typing just makes it a little easier to shoot yourself in the foot by not throwing up an error when you make the assignment or function call in the first place.
Which is why I really don't see the value of forced dynamic typing- it makes code less clear, puts 'compile'-time errors at runtime, and generally reduces performance all around.
[PHP is] remarkably close to what C++ should have been...
Wow. Really? Somehow I feel you've never done any development for high-performance applications before.
Variable length arrays? Try STL's vector or map. C++'s arrays are backwards compatible with C's, but that's not to say it's not sensible behaviour- growable arrays have a fairly big overhead.
Also, I'm not sure where your gripes with C++'s string manipulation come from, but I suspect you really haven't looked into the STL libraries very much. I often see C++ coders rewriting even basic things like vector or some of the algorithms (poorly) just because they didn't know about them
Preach PHP all you want, but don't try to tell me that it's better designed than C++. It's simply not true.
A side note, what's the point of OO in dynamically typed languages? It kinda defeats the point of inheritance & polymorphism...
It's about owning a large user base, not about the technology. Google didn't buy Youtube because it was unique or had some technically brilliant product/code. That said, it's still dumb.
There are a bunch of consumer products that i'd hesitate to classify as 'embedded' nowadays. Specifically, mobile phones, handheld consoles, etc. They're not running a RTOS, and they're wielding a pretty hefty amount of power.
In any case, you shouldn't run windows on anything life-critical unless you want "blue screen of death" to be a literal term.
Whenever a government is allowed to get away with something like this, it's a global problem. Should I not care about Darfur, simply because I don't live there? (Not to equate this with genocide, but I hope I made my point)
No, no, no! This is not a healthy line of thought! There is absolutely no way you can predict with certainty the future benefits of any scientific research. Even electricity was of uncertain value. The very point of public funding is for research whose benefits aren't obvious, but whose results are a benefit to science as a whole. You say that you believe it is possible to 'evaluate potential research'. How do you go about doing that? What are your criteria? Does research which has no practical application whatsoever but advances understanding of the whole get swept under the carpet?
One might argue that without establishments such as the Royal Society, a lot of great scientists in Great Britain might never have been able to publish.
Phillip Pullman also did a great piece in the Times related to, although not specifically about, this recently. Oddly, it got pulled by the Times with no explanation. I wonder why?
Your nintendo analogy doesn't quite fit. Let's say Nintendo bundle a free FPS game* with the Wii. Now let's say they terms for licensing games are that it _cannot_ be an FPS: it can't compete with theirs. That's a monopolistic practice no matter how you look at it.
As for the barriers to entry: they may be small for most apps, but they're infinitely high for a browser.
All i'm saying is that the practice of forcing the end user to use certain apps is a monopolistic practice.
* Yes this category is much wider than 'browser', but it's the closest example I can think of.
In this case, it's not a question of shipping with other software, but even allowing it to compete! Microsoft's monopoly stems from the bundling, sure, but they never went out and deliberately prevented Mozilla or Opera from creating and publishing their own browsers. You keep spouting the line "The rules are different when you're a monopoly": yes it's true, but as i've said twice now, just because a company isn't a monopoly doesn't mean a practice can't be monopolistic.
Yeah, but maybe Opera does. The whole point is that Apple is artificially stifling competition. Saying "It's apple's toy" is equivalent to saying Microsoft should be able to disallow the installation of any web browser but IE; it's just a question of scale.
Okay, I missed that. However, once you start doing things like including generic functions/classes in other generics, and doing compile-time calculations you're going to have headaches, namely because the C preprocessor only does a single pass on the code.
Back to code length: the C preprocessor version forces you to define multiple constants and include a header for each specialization of the template. Given that C++ can also infer template arguments from function arguments, I would have thought the C++ would be shorter.
My opinion is the complete opposite of this- explicitly having to specialize a template with a bunch of defines and an include each time seems fugly. Perhaps we'll just have to agree to disagree on that one :-)
I have a couple of issues with that code. First, If I want to create multiple CustomArrays of differing base types, in C++ I can do
CustomArray<int> ints;
CustomArray<char> chars;
With the C preprocessor, I can only do a single define, and I'm stuck with that single base type. Secondly, That's a _lot_ more code, and it's a _lot_ uglier...
Lastly, about the foreach loop- I can see where you're coming from about it being 'glued on', but i've never really found it to be much of a hindrance. Apparently C++0x has something similar, though.
As for C++'s STL libraries being difficult to use, I have to disagree again. Let's take vector as an example. Elements are accessed the same way as regular arrays (square bracket notation), and the notation for using templates (i.e. vector<int> ints;) is really not difficult. Actually writing template functions is a little harder, though. I am frankly amazed you think the C preprocessor is equivalent in usefulness to templates, so in case i'm being stupid here, would you explain how you implement a generic container using the preprocessor? For that matter, what do you find nicer about the C preprocessor than templates? Littering source code with #defines and #ifdefs surely can't be neater...?
It's not that I think dynamic typing decreases the value of OO, but that I think OO decreases the value of dynamic typing.
Which is why I really don't see the value of forced dynamic typing- it makes code less clear, puts 'compile'-time errors at runtime, and generally reduces performance all around.
Wow. Really? Somehow I feel you've never done any development for high-performance applications before.
Variable length arrays? Try STL's vector or map. C++'s arrays are backwards compatible with C's, but that's not to say it's not sensible behaviour- growable arrays have a fairly big overhead.
Also, I'm not sure where your gripes with C++'s string manipulation come from, but I suspect you really haven't looked into the STL libraries very much. I often see C++ coders rewriting even basic things like vector or some of the algorithms (poorly) just because they didn't know about them
Preach PHP all you want, but don't try to tell me that it's better designed than C++. It's simply not true.
A side note, what's the point of OO in dynamically typed languages? It kinda defeats the point of inheritance & polymorphism...
It's about owning a large user base, not about the technology. Google didn't buy Youtube because it was unique or had some technically brilliant product/code. That said, it's still dumb.
Oh, so you're still using a CRT with your desktop?
There are a bunch of consumer products that i'd hesitate to classify as 'embedded' nowadays. Specifically, mobile phones, handheld consoles, etc. They're not running a RTOS, and they're wielding a pretty hefty amount of power. In any case, you shouldn't run windows on anything life-critical unless you want "blue screen of death" to be a literal term.
Referred to in Mayan texts as "The Great Mayan Integer Overflow".
For the record, i'd like to provide a short list of things that aren't cogent scientific arguments:
1) Political arguments
Hah, well this won't affect me: my signature comes out different every time!
Assuming 2 project managers, that's 164 warm bodies, and 2 cold, dead, unfeeling bastards.
What do you mean i've got a chip on my shoulder?
Whenever a government is allowed to get away with something like this, it's a global problem. Should I not care about Darfur, simply because I don't live there? (Not to equate this with genocide, but I hope I made my point)
Believe it or not, some slashdotters actually live in the UK!
That link really hit home. We're going to have to start doing something about this.
Yeah but they're marked up like 100x the original price. I think it's the packaging.
No, no, no! This is not a healthy line of thought! There is absolutely no way you can predict with certainty the future benefits of any scientific research. Even electricity was of uncertain value. The very point of public funding is for research whose benefits aren't obvious, but whose results are a benefit to science as a whole. You say that you believe it is possible to 'evaluate potential research'. How do you go about doing that? What are your criteria? Does research which has no practical application whatsoever but advances understanding of the whole get swept under the carpet?
One might argue that without establishments such as the Royal Society, a lot of great scientists in Great Britain might never have been able to publish.
Naw, what (s)he said was (and I quote):
An unlocked, sim-free G1 would meet these requirements. It's still pricey though.
I only do eyes!
Phillip Pullman also did a great piece in the Times related to, although not specifically about, this recently. Oddly, it got pulled by the Times with no explanation. I wonder why?
Nobody visit those URLs! They have viruses!
Love,
The RIAA.
I'd quite like to read that, do you have a link?
Your nintendo analogy doesn't quite fit. Let's say Nintendo bundle a free FPS game* with the Wii. Now let's say they terms for licensing games are that it _cannot_ be an FPS: it can't compete with theirs. That's a monopolistic practice no matter how you look at it. As for the barriers to entry: they may be small for most apps, but they're infinitely high for a browser. All i'm saying is that the practice of forcing the end user to use certain apps is a monopolistic practice.
* Yes this category is much wider than 'browser', but it's the closest example I can think of.
In this case, it's not a question of shipping with other software, but even allowing it to compete! Microsoft's monopoly stems from the bundling, sure, but they never went out and deliberately prevented Mozilla or Opera from creating and publishing their own browsers. You keep spouting the line "The rules are different when you're a monopoly": yes it's true, but as i've said twice now, just because a company isn't a monopoly doesn't mean a practice can't be monopolistic.
Hence "It's just a question of scale". Just because Ballmer's being a hypocrite doesn't mean he isn't right.
Yeah, but maybe Opera does. The whole point is that Apple is artificially stifling competition. Saying "It's apple's toy" is equivalent to saying Microsoft should be able to disallow the installation of any web browser but IE; it's just a question of scale.