Actually, the computer scientist's world is more like, "This program is provably impossible to verify for correctness." At least, unless you severely constrain the problem, which is the alternate theoretical approach (see qmail for an example).
Not so much kidding as participating in good old fashioned ASCII-art jokes. But seriously, _ constitutes a line segment (1-dimensional), and. constitutes a point (0-dimensional). I mean, we can't have the entire scientific community getting themselves confused about the degrees of complexity difference between a period and an underscore!
I'd argue that it's encoded onto a 1-dimensional stream of bits. The main difference being that an encoding can be used to reconstruct the original, whereas a projection by definition loses information.
We may see in 2D, but we can perceive in 3D, due to a combination of depth perception and our brain's habit of assuming the world is made of straight lines.
The same works for audio... A stereo recording only has one dimension spatially (a line going through the speakers). But it's quite easy to make something sound nearby (full frequency range, mostly direct sound) or far away (muted high frequencies, mostly indirect sound / reverb). Thus, you really get an extra dimension for free, same as for our eyesight... both because of how the brain is trained to perceive the world.
I've never experimented with ICC on AMD hardware, but I would expect the same problem—suboptimal code bcause the underlying hardware is different.
Deploying an intel-built solution shouldn't be any harder. If you're pushing binaries, the only dependencies would be Intel's fancy math libraries, if you use them. If you're pushing source, you either provide two Makefiles (one for GCC, one for ICC), or you might even be able to get away with one, since ICC attempts to be as compatible as possible with GCC's command-line options.
In my opinion, Intel builds are only useful for in-house software or professional scientific software. Use both compilers while you're testing. Use all of the profiling tools available to you (gcov, vtune, valgrind/cachegrind, etc). Use all of the style guidelines for both compilers (particularly anything they say about strict aliasing).
It doesn't matter what language-specific tool was used to solve the problem. What matters is that a problem was solved. Python has dict, and C++ has std::pair and struct for ad-hoc structures.
Manual memory management. In any complex program, balancing your news with deletes is not as simple as you make it out to be. Object ownership is a tough problem.
Application code shouldn't be managing memory. That's what smart pointers or other resource-owning utilities exist for. Effectively layered C++ applications have very few ownership issues, and where they exist, they tend to be between threads (a logical issue for the developer to solve, not something that the programming language can do itself).
Lots of C++ code solves this problem by making a lot of defensive copies, which in turn hurts performance greatly.
Alternatively, C++ is designed as a language with value semantics. That means when you have a small struct, you copy it around as needed instead of trying to keep a single "entity" accessible everywhere. You'll probably also have better overall performance with that, because you won't be thrashing the cache so much (better locality of reference for stack/member objects, as well as reduced sharing or false sharing of memory between threads).
Remember: unless you've measured a performance difference, it doesn't exist. Most estimates at performance analysis are wrong.
I'm a C++ guy myself, but I like your comment. I'll add something nice about Java (yuck...). Java solves the build issue rather well. It's quite onerous to get used to, but once you realize how much effort it is to get large-scale build systems for C++ set up, it proves itself a nice time-saver. Most C or C++ shops develop their own in-house standards anyways, and Java just eliminates that mental workload.
1) It is impossible to make a string class that behaves "normally"
Please define "normally".
[std::string] foo = 7;
Oh, you mean Variable-Typed Values? That's not a string class. That's an everything class. And yeah, you can do that with an STL-esque string, but it is a bit of a silly idea. Your normal doesn't match anything I would expect for a general-purpose string abstraction.
GCC has done a pretty good job of keeping up with ICC on Intel... even though GCC supports a multitude of other platforms. Pretty much the only place where ICC is ahead of the game (based on aggressive in-house benchmarking) is interprocedural optimization and hardcore floating-point math. Everything else is a wash, and GCC is free software. The biggest hurdle with GCC is that it takes a fair amount of compiler flags in order to get reasonable output out of it - in comparison, ICC works well (for an Intel chipset) without any extra flags. On the other hand, ICC isn't going to do well for anyone on any other chipsets...
The world is bigger than you think, and there are still many places where C or C++ will smash a Java or C# solution. Calling those developers dinosaurs just makes you look ignorant.
What happens when you have to use 5 different objects with Dispose methods? Do you need 5 levels of indentation? I'm genuinely curious, because I've been spoiled by RAII (C++, PHP, Python), and I get frustrated in any language that doesn't have deterministic destruction by default.
You're doing it wrong. I think what you mean is, "For most developers, it's harder to write well-performing C++ than it is to write well-performing Java."
Slashdot Mirror
Your statement reminds me of a legless man bragging to someone who chooses to sit down.
Actually, the computer scientist's world is more like, "This program is provably impossible to verify for correctness." At least, unless you severely constrain the problem, which is the alternate theoretical approach (see qmail for an example).
Stop embracing the ignorance.
oOo... good point.
Not so much kidding as participating in good old fashioned ASCII-art jokes. But seriously, _ constitutes a line segment (1-dimensional), and . constitutes a point (0-dimensional). I mean, we can't have the entire scientific community getting themselves confused about the degrees of complexity difference between a period and an underscore!
I'd argue that it's encoded onto a 1-dimensional stream of bits. The main difference being that an encoding can be used to reconstruct the original, whereas a projection by definition loses information.
We may see in 2D, but we can perceive in 3D, due to a combination of depth perception and our brain's habit of assuming the world is made of straight lines.
The same works for audio... A stereo recording only has one dimension spatially (a line going through the speakers). But it's quite easy to make something sound nearby (full frequency range, mostly direct sound) or far away (muted high frequencies, mostly indirect sound / reverb). Thus, you really get an extra dimension for free, same as for our eyesight... both because of how the brain is trained to perceive the world.
Fixed that for you.
In my opinion, Intel builds are only useful for in-house software or professional scientific software. Use both compilers while you're testing. Use all of the profiling tools available to you (gcov, vtune, valgrind/cachegrind, etc). Use all of the style guidelines for both compilers (particularly anything they say about strict aliasing).
Touche'.
It doesn't matter what language-specific tool was used to solve the problem. What matters is that a problem was solved. Python has dict, and C++ has std::pair and struct for ad-hoc structures.
I won't argue with your other points, but...
Application code shouldn't be managing memory. That's what smart pointers or other resource-owning utilities exist for. Effectively layered C++ applications have very few ownership issues, and where they exist, they tend to be between threads (a logical issue for the developer to solve, not something that the programming language can do itself).
Alternatively, C++ is designed as a language with value semantics. That means when you have a small struct, you copy it around as needed instead of trying to keep a single "entity" accessible everywhere. You'll probably also have better overall performance with that, because you won't be thrashing the cache so much (better locality of reference for stack/member objects, as well as reduced sharing or false sharing of memory between threads).
Remember: unless you've measured a performance difference, it doesn't exist. Most estimates at performance analysis are wrong.
I'm a C++ guy myself, but I like your comment. I'll add something nice about Java (yuck...). Java solves the build issue rather well. It's quite onerous to get used to, but once you realize how much effort it is to get large-scale build systems for C++ set up, it proves itself a nice time-saver. Most C or C++ shops develop their own in-house standards anyways, and Java just eliminates that mental workload.
Please define "normally".
Oh, you mean Variable-Typed Values? That's not a string class. That's an everything class. And yeah, you can do that with an STL-esque string, but it is a bit of a silly idea. Your normal doesn't match anything I would expect for a general-purpose string abstraction.
GCC has done a pretty good job of keeping up with ICC on Intel... even though GCC supports a multitude of other platforms. Pretty much the only place where ICC is ahead of the game (based on aggressive in-house benchmarking) is interprocedural optimization and hardcore floating-point math. Everything else is a wash, and GCC is free software. The biggest hurdle with GCC is that it takes a fair amount of compiler flags in order to get reasonable output out of it - in comparison, ICC works well (for an Intel chipset) without any extra flags. On the other hand, ICC isn't going to do well for anyone on any other chipsets...
From the boost multi-index tutorial: typedef multi_index_container< employee, indexed_by< ordered_unique<identity<employee> >, ordered_non_unique<member<employee,std::string,&employee::name> >, hashed_unique<member<employee,int,&employee::ssnumber> > > > employee_set
The world is bigger than you think, and there are still many places where C or C++ will smash a Java or C# solution. Calling those developers dinosaurs just makes you look ignorant.
The proper solution is to smack the idiot developers, not hamstring the intelligent ones.
What happens when you have to use 5 different objects with Dispose methods? Do you need 5 levels of indentation? I'm genuinely curious, because I've been spoiled by RAII (C++, PHP, Python), and I get frustrated in any language that doesn't have deterministic destruction by default.
I wouldn't want to work with whoever's servers you are maintaining. None of the C++ servers I've worked on have had the same issues.
Hopefully C++'s revision is better than the crapfest that is anything more complex than sticks and dirt.
FTFY :)
You're doing it wrong. I think what you mean is, "For most developers, it's harder to write well-performing C++ than it is to write well-performing Java."
Name something you can do in C that you can't in C++.
I read slashdot too, and I loose my mind when I see people type like you.
Their. Fixed that 4 u.