Comment: Re:When did CEOs get to dictate tax policy? (Score 1) 122
Corporate personhood is an American concept and only applies to certain situations.
|
|
Sure, make Kirk the youngest CO ever. I'm cool with that. Right up until, apparently, there's not a single officer on the entire ship... except for Spock...
This is the part that I've never been able to resolve. Even if this is a case, and Kirk needs to take command, there's no reason for him to get permanently bumped up 4 ranks.
Abrams clearly wanted to have Kirk as captain of the Enterprise at the end of the movie, and have him as a cadet at the start, but that really wasn't going to be possible in a logical way.
In Europe, the share of traffic deaths attributable to drunken driving was reduced by more than half within 10 years after the standard was dropped
Typically this sort of reduction will be accompanied by a public awareness campaign on the dangers of drink driving. I'm not totally convinced this is a good argument.
No, it's a good design decision. Why would anyone want their program to pay for something they don't use?
Simplifying development would be a good reason. This would be mitigated by making it an optional feature. Sure, you can argue all sorts of good reasons why this shouldn't be included, but more than once I've found myself cursing this omission.
If that kind of optimization is needed, people can use a string literal.
But then you're optimising. Not the compiler. And really this was just an example. I really think that a modern programming language without a built in string type is bizarre, and by the time C++ was introduced, the amount of string processing that programmers do was pretty well known. Retrofitting it is the wrong solution.
Yes, but the point is that it breaks the "you don't pay for what you don't use" design principle of C++.
If it prevents useful features from existing, this is a poor design decision. Plus, you'd only need to include it if it was actually used. It could even be added as an optional feature to classes.
You can't guarantee it. For example, if some library happens to use some kind of generic conversion function for its templated type, and you include the enum, then you've automatically dragged in a whole bunch of stuff.
This is a problem with the library. Not C++.
If the standard defines strings as a built-in type, you've just shifted the problem from the library to the compiler which doesn't fix anything.
string a = "hello ";
string b = "world";
string c = a + b;
int d = c.length();
return d;
The above code can optimise to {return 11;} if strings are built in. If it's a type then it involved allocating at least 3 chunks of memory and 2 memory copies.
if they make reflection a feature of the language, then users pay for its performance penalties even though they don't use it.
Can be implemented as static members. Performance cost is a little bit of static data per class type.
Enum to string: same as above.
Not at all. If you don't use it then the string conversion function won't be linked.
While the std string library leaves a lot to be desired, I don't see why an inbuilt string type is needed.
Because the std::string type leaves a lot to be desired. A built in type means that the compiler is allowed to know what a string is and is and can handle strings differently for optimisation. It also means that we can have third party libraries that don't rely on an assumption that we're using the right std::string implementation.
I find if you think of templates as less powerful LISP macros that only works on types.
If I want that I'll add a lisp macro as a precompile step. Templates add a lot of complexity for limited benefit.
The first duty of a revolutionary is to get away with it. -- Abbie Hoffman