What's wrong with C++ (from the point of view of someone that uses it daily)
blog.codeimproved.net
blog.codeimproved.net
I dont feel that way about C though and its probably because of C++'s immense complexity. If everyone on your team has 7+ years of using C++ and most of its features on a day to day basis then I think you have a chance (however remote) of getting a clean maintainable system. If not you get a good ugly mess.
(And yes I've created a few myself, while learning this language :)
Also re: maintainability. C++ is completely maintainable, and built from the ground up for maintainability specifically in large projects.
Don't blame C++ for the sins of Microsoft (managed C++ extensions, DLL HEll, C++ COM interfaces, compiler support classes, 9 different string types). Don't blame C++ for the sins of gcc. At some point we need to distinguish between the (pure) LANGUAGE and the (often politically motivated) TOOLSET.
The better the tool you use the less stress it puts on you the builder.
Most of those sins were committed specifically to address weaknesses in C++.
A language without a first-class late-binding model is fundamentally broken. Don't blame Microsoft for trying, however ineffectively, to fix it.
With C++ and Qt on the other hand, it's very easy to write self-contained applications, also with a minimum amount of platform-dependent code.
This is quite easy to fix on linux. You compile a your required version of ruby beside the application that needs it.
/srv/<application>
src/
ruby/ <-- install ruby here with the proper flags
build-ruby.sh <--- custom script to download, build, and install ruby
The bundler project is also trying to the gem problem by bundling gems with your application.
C++ has its place, but that place is getting smaller and smaller each day, making the advanced features of C++ all the more irrelevant.
Does anyone knows any research or even a state of affairs of const inference in language design?
The idea is similar to type inference whereby a compiler (or some other tool in a chain) would take care of understanding which arguments/variables/functions are going to be const and generate appropriate warnings based on that. For example,
void foo(int * a) { (*a)++; }
void bar(int * b) { foo(b); }
void baz(const int * c) { bar(c); }
void foo(int * a) { }
void bar(int * b) { foo(b); }
void baz(const int * c) { bar(c); }
In fact, the example above is more relevant, because what I am ultimately aiming for is to not need to make member functions const, and yet be able to call them for const class instances.
"Why running with one leg is great" - written by someone who run each days with one leg.
Of course, if you're using C++ each days of your life, you become quite good at it. You know the downside, you learn to use external libraries, etc. However, it's when you actually switch to another language that you can look behind realize all the time and effort you lost.
It's when you actually start running with 2 legs that you know for sure that, yes maybe one leg is ok, but 2 legs is easier, simpler, faster and safer.
Oh, some says it's better to use a car, well, I don't care because 2 legs is ok for me. [to be completed]
I work on a real-time visualization application for microscopes. Main requirements:
1) Performance (DSP and image processing involved)
2) Decent GUI
3) Must be maintainable by students in engineering physics
What I am supposed to use that's easier, simpler, faster and safer than C++/Qt for this? Even dropping the "maintainable" thing, I don't see any language that would let me code faster. And my app doesn't have very unusual requirements...
If you lose one of your shoes and need to walk in the street, you might be better to jump with only one leg.. it doesn't make it better than 2 legs.
In the same way, if you needed raw performance, need to control your memory, etc. C++ might be the only way to go.
However, for your particular problem, I don't know if it's possible, but a mix of Python for GUI and C for the raw algorithm could have been easier.
And, for students in engineering physics, Python is way simpler than C++. From my experience, I helped students in other concentration than computer at university, and they had all kind of: #include <iostream.h>, lots of global variable named with only one letter, etc.. in their code.
But don't get me wrong, C++ has its use and I keep using it again and again for various project. I know however that when I can use other language such as python, I'm way more effective and the final code is really prettier and simpler.
Sadly, as in everything in life, nothing is black or white.. if C++ fits you well for a project, uses it. It's nobody's business anyway. I think it's important however to know that if you only use and know C++, you miss something.
He is not saying that C++ is great. In fact he mentions several issues that bother him in his day to day use of the language. The problem with a lot of the anti-C++ rants is that they make it sound like it is impossible to get anything done in C++, which of course is not the case. Memory management for example is often brought up as a major issue with C++. I have been in 200+kloc projects that never leak memory and very, very rarely have to call delete. Just use RAII - it's not rocket science.
A garbage collected program should never leak memory but if it does, then your problem is nastier - for example, how do you find memory leaks in C# in Mono? The tools are not sufficient. And standard Ruby, btw, doesn't official leak memory but simply never return allocated memory to the main pool - it keeps it in a private pool for future allocation. But allocate 1Gig and your Ruby instance will keep that 1Gig forever.
When I'm using some scripting language and not Qt, I wish I was using Qt.
Qt is the shit. If you haven't used it you can't criticize C++. I've whipped up several things I know would have taken me ages longer to achieve the performance requirements with anything else.
If you want to know how C++ can be better, you should take a look at at the Reason C++ framwork, especially if you have never seen C++ in its most pure uncomplicated OO form.
Reason is a C++ framework that ive been writing for about 8 years, which aleviates many of the sources of pain highlighted in this discussion. Writing code with Reason is much more like using a dynamic language, with a full library like Java or .Net.
It supports raii, but doesnt use exception handling and doesnt bother with const nonsense or over the top inheritance restrictions. In fact pretty much everything in Reason is public and designed to be derived, modified or enhanced.
It has generic programming features, but doesnt force you to write everything as templates (a classic mistake that the standard library makes). For example, you can have an iterator of int's without caring what the underlying container type is, so your code and algorithms can actually be generic, not just infectious templates.
Unlike a lot of C++ frameworks and libraries, its not specifically focused on networking, or a few esoteric template classes or collection libraries.
Reason is a fully featured systems programming framework with a complete interface to all the usual posix api's and everything else you would expect from a modern language. It has strings, regexes, streams, parsers, sockets, threads, filesystem, encryption, encoding, xml, xpath, collections, time and date, sql (mysql, postgress, sqlite), http (client/server), smart pointers, formatting, logging, and much more.
But the features are perhaps not as important as how it is written. It is simple, and very object oriented, everything is designed to work togeather cleanly and obey the principle of least surprise. Just like Python and Ruby, Reason allows you to do a lot in a very small amount of code.
So if your wondering how you can have the simplicity of C, with just the good parts of C++, heres your answer.
<pre>
#include <stdio.h> void function ( int const * const value ) { printf ("%d\n", * value); / * more code * / ( * value)++; / * more code * / ++value; }
int main(int argc, char * * argv) { int value = 1; int * pvalue = &value; function(pvalue); return 0; }
$ gcc t1.c t1.c: In function ‘function’: t1.c:5: error: increment of read-only location ‘* value’ t1.c:7: error: increment of read-only location ‘value’ </pre>
quick googling: http://www.cprogramming.com/tutorial/const_correctness.html
EDIT: how can we properly paste code in here? The * mess things up.
#include <stdio.h>
void function(int const * const value)
{
printf ("%d\n", *value);
/* more code */
(*value)++;
/* more code */
++value;
}
int main(int argc, char **argv)
{
int value = 1;
int *pvalue = &value;
function(pvalue);
return 0;
}
$gcc t1.c
t1.c: In function ‘function’:
t1.c:9: error: increment of read-only location
t1.c:13: error: increment of read-only location
EDIT: I've recompiled on OSX to correct the error message with the correct lines.
void function(int const * const value)
void function(int const *value)
void function(const int *value)
I've never found a need for it. I usually don't care if the pointer itself is modified, particularly since such modifications are usually local and obvious.
I admittedly don't use C++ that frequently, but if I make my code const-correct it always seems to cause a lot of false positives, while seldom finding actual bugs.
The idea is that most other languages are ++C. or ++A. The operation isn't straddled across two lines. Backwards compatibility with another language (C) isn't so important. And all the language features aren't generated implicitly without a real clear idea about the design (i.e., via temporaries).
On the other hand, it is possible to program in something like ++C -- no temporaries -- by consciously going through and picking which features you like in C++, and not waiting for them to influence your design in some weird way (hence these types of posts about C++, and how different programmers have different takes on the language -- and different tools, moc, etc.). That is, if you want to write really elegant C++ code, you have to write it with a vengeance. It's not orthogonal really like Python or Ruby. It's much more like Perl. Just as the compiler is generating unnecessary cycles by creating that temporary (9/10), so are the C++ design paradigms often very overlapping and if you're not careful and don't understand them in detail -- they'll create a lot of unnecessary design cycles.
But I think with the right tools and the right focused perspective, it's still one of the best languages. It's not forgiving -- and sometimes it's almost misleading -- I mean from the very beginning, you'd think if you wanted simply to increment an integer or an object semantically you'd just foo++ -- but that'd usually be wrong.
But the redeeming part about C++ is that all languages make these mistakes. All languages, in trying to improve on their predecessors, make limiting choices that are imperfect and at some point will be optimized or revised in the future. The beauty, if you can call it that, of C++ -- is that because of its performance bent, it doesn't force you to choose any of its features which aren't already in C.