People who hate C++ are only doing so because it's hip and cool to hate on something that seems too complex at first glance. You want to be seen as cool and edgy, as someone who goes against the grain, when in reality you're just another annoying undergraduate that will probably have a hard time finding a job in the field.
C++ is not perfect, but no language is. Get over it.
Name:
Anonymous2011-07-03 6:40
>>72 rvals can't be on the left side of an assignment, or passed in to a function by reference.
Huh? #include <stdio.h>
#include <string>
void f(const std::string & s) {
printf("%s\n", s.c_str());
}
void main() {
f("abc");
}
>>81
if i'm understanding that correctly, the "abc" constant is passed to the constructor to string, which creates a new string object, and then the string object is passed to f(). that variable is passed by reference but then thrown away after the call completes. so the rval is automatically cast to an lval which then goes into the function.
>>76
yes of course rvalues can be variables but i guess i was confusing your point, i thought you were talking about the difference between literals and variables. a variable, when used as an rval, is for all intents an purposes the same as a literal.
and yes, C and Java generally do not allow the type of a variable to be changed after compilation. that's the way it should be for maintainable code. otherwise static analyses, such as finding all the references for a given variable, don't work. if you can change and repurpose variables willy nilly that pretty much throws the advantages of type safety out the window.
Name:
Anonymous2011-07-03 10:48
>>83
Some of us programmers actually believe in following the corresponding language terminology instead of inventing our own defintions.
Name:
Anonymous2011-07-03 10:54
>>83 that variable is passed by reference but then thrown away after the call completes
No. The variable doesn't get thrown away after the call completes you fuckwad.
so the rval is automatically cast to an lval which then goes into the function.
Wrong again pee wee. There is neither an explicit nor an implicit cast in that piece of code.
Name:
Anonymous2011-07-03 10:59
The following statement that you made also irks me..
if you can change and repurpose variables willy nilly that pretty much throws the advantages of type safety out the window.
Geeze, have you ever written a single line of code in your entire life? Just curious, because at Kodak, we have several pieces of production level C code that has the following patterrn...
int lock = 1;
/* Do some stuff */
{
int lock = 0;
/* Do some more stuff */
}
>>86
What are you talking about? Those are different variables. (And that does look like a template for less than awesome code.)
Name:
Anonymous2011-07-03 11:41
>>89
No you idiot. The code simulates re-biding the variable. Cripes. Why don't you just shut the fuck up, write a few hundres lines of actual code, read one of the language standards, and then come back when you have a clue.
Name:
Anonymous2011-07-03 12:08
>>86
those are different variables as far as i'm concerned, since they are in different scopes. what i was talking about is changing the type of a variable within the same scope. a scope is essentially an anonymous part of the variable name, an anonymous namespace if you will.
Name:
Anonymous2011-07-03 12:10
>>85
i'm certain you are wrong. if you change the signature of string::string(const char *str)
to
explicit string::string(const char *str)
then your code will not work. you can also verify by putting a break point in the constructor above.
const void vi_vi_vi_function_of_the_beast(int *ptr) {
puts("suck my cock, faggot");
exit(*ptr);
}
int main(void) {
auto volatile int MisterFister69 __attribute__ ((aligned(128), nocommon, unused, deprecated, cleanup(vi_vi_vi_function_of_the_beast))) = ~-1;
>>95
the variable goes out of scope, not the object.
Object o1
{
Object o2 = new Object();
o1 = o2;
}
{
o2 = new Object(); // failure
o1.hashCode(); // ok
}
>>96
regardless of the exact technical wording of "scope", same variable name in different scopes is very different than repurposing a variable in its same scope. next you'll tell me overloaded functions are the same as dynamically assigned functions.
Name:
Anonymous2011-07-03 13:47
>>102
I was talking about an 'object' in the ANSI/ISO sense, not the OOP sense.
>>103
And more to the point, an 'object' (usually) has the properties of scope, duration, and visibility. It's kind of like your wife has the properties of obese, herpes, and ugly.
Name:
Anonymous2011-07-03 14:01
I'm not clear on how this relates to programming. I'm certain this thread will segue into a programming related discussion at any moment.
Name:
Anonymous2011-07-03 14:07
>>108
Because in some of your loser imperatives languages, an 'object' comes into existence at runtime. However, the variable, which has a type, is only known at compile time. In contrast, some languages can determine the type at runtime because it's the value, and not the variable, that gets bound to the object. So which one is more type safe?
Name:
Anonymous2011-07-03 14:08
I'm STILL not clear on how this relates to programming. I'm certain this thread will segue into a programming related discussion at any moment.