Nemanja Trifunovic wrote:

So people are using VB for image processing nowdays? Fascinating.

And have done so for years, even in VB6. So what's your point? Was there even a point? In most applications speed simply doesn't matter that much. And although (reasonably fast) image processing in VB6 used to be more work than, say, in C++, this was often offset by the efford to interoperate with a C++-coded image processing DLL. So image processing in VB was (and is, even more so) a completely sane choice. Of course, if you have other requirements, e.g. process a large batch of images really, really fast, then scratch the above and turn to ASM. On the other hand, there are some excellent assembly-enhanced VB6 codes out there to do just that.

Thanks for the advice. Luckily, however, I'm working on a library and don't need to bother with user interfaces. The reason my code only works on Unix is that I rely on some third party libraries that are poorly written and (for no good reason) are completely platform-specific. However, I am hopeful that this will change in the foreseeable future.

I can't share your enthusiasm. I'm working full-time on a Mac and I do most of my development stuff under Windows in a VM. However, I currently work on a large code base which won't compile under Windows so I'm forced to use Linux/Mac. And I have found XCode to be severely restricted in its capabilities so I've wholly adapted the GVIm/makefile approach. Actually, this works surprisingly well and I believe that with the right skill (which I don't yet possess) this may make fully-fledged IDEs redundant. At the moment, I still struggle to quickly switch between many files … but well.

jschell wrote:

So re-phrasing, what makes you think that your opinion about the way in which objects should be used in C++ actually has anything to do with the way in which they are in fact commonly used?

Please let me be a bit arrogant in answering this question: I don't actually care what's commonly used. It's widely acknowledged that 80% of everything is crap (cf. Sturgeon's Law) and I firmly believe that it is counterproductive to waste time discussing crap. So, I don't care what's commonly done. I do care how it should be done. And Stroustup (and others) tell us how it should be done. Stroustrup himself said that, in his opinion, “C++ Is [his] favorite garbage collected language because it generates so little garbage.” The context in which he says this (as well as his reference to it in the FAQ) makes it obvious that this phrase alludes to RAII. => You might be right that most C++ code written uses pointers to objects and explicit memory management all over the place. However, it is widely acknowledged that this is bad C++ and I am not going to justify this assertion because others have done so time and again – I simply won't waste energy on an established, well-documented fact. There's certainly no single Right Way to program C++. But using explicit memory management excessively is certainly the wrong way.

jschell wrote:

Unfortunately, this trade-off is still (and will be for years to come) absolutely unacceptable in many computing areas.

Presumably you mean as a absolute count rather than in comparison to all software fields.

What I mean is that there are many fields (although they are certainly a minority compared to all existing computing problems). Simply, there are sufficient areas to justify the existence of a language such as C++.

jschell wrote:

and the performance penalty (on modern compilers) equals zero.

You are claiming that data constructs in C++ have a zero cost? That is incorrect.

That's indeed what I am claiming and it is correct. I am not claiming that, for a specific, well-analyzed case, you can't build a better suited custom data structures (e.g. you could forego any resizing issues in a vector with a fixed-size buffer). I am, however, claiming that in a general case without any specific domain knowledge, C++ data structures have a zero performance overhead at runtime, compared to low-level Assembler implementations of the same problem. Of course, this is a theoretical upper bound. In practice, most compilers have difficulties attaining this level of optimization. But modern compilers come very close most of the time (so close, in fact, that the difference is not measurable on modern PCs). My point is, C++ provides a level of abstraction that is completely transparent and has no additional cost, compared to an equivalent solution without the use of abstraction.

jschell wrote:

In terms of original creation of C++ garbage collection probably wasn't considered at all. That would be the reason for not having it. Another reason would have been because C didn't have it.

First of all, I am pretty sure a GC was considered. Perhaps not in the first version of “C with classes” but later on. I am even pretty sure that I've read a statement saying this from one of the committee members but I can't find it now (I think it was even from Stroustrup himself, in TC++PL). Second, saying “because C didn't have it” is a real no-argument. C didn't have classes, yet we see them in C++. A GC could have been built to be completely unobtrusive and transparent on top of the memory management, thus providing backwards compatibility so this

Your simplification fails to grasp several key concepts that distinguish C++. I will just highlight one of these, because it is my favourite concept (and arguably the cornerstone to C++' success). I am speaking of templates. Yes, I know that C# has generics but these have not much in common with C++' powerful concept. C++ templates allow the implementation of very high abstraction data models and algorithms without any runtime penalty whatsoever! Take a look at any book on algorithms. Chances are, the examples are implemented in Java (unless, of course, you are reading Knuth, who, for reasons best known to himself, treats us to MIX). Now, these example codes usually practice a very high level of abstraction and present the concepts in a wonderfully concise way (once we overlook the shortcomings of Java's syntax). But, these books have a serious drawback: They trade abstraction for performance. Unfortunately, this trade-off is still (and will be for years to come) absolutely unacceptable in many computing areas. My own domain is bioinformatics and here the performance/abstraction trade-off of languages such as C#, VB or Java are clearly out of question. Templates in C++ offer the same degree of abstraction – in fact, the STL is a textbook example of abstraction and surpasses anything .NET or Java can muster – and the performance penalty (on modern compilers) equals zero. Good C++ compilers produce code having the same performance as hand-coded assembler routines, while using high abstraction. Stroustrup gives a very good example of the power of templates by comparing C++' std::sort function to qsort from C. Surprisingly, std::sort outperforms qsort even when their implementations are conceptually identical. This is due to the fact that qsort has to call a function pointer in order to compare elements. C++ achieves the same genericity through templates and a function object. This function object call can be inlined most of the time, eliding any runtime overhead. I have to address one other issue, though (because it figures in your thread title). C++ has no garbage collection for very good reasons. For those interested in details, I can advise looking up the RAII idiom and C++' way of treating objects as stack-located values most of the time (rather than working on pointers to the heap).

So what about GVIm? I use that exclusively. It could be said that all the other editors mentioned here merely emulate subsets of GVIm while GVIm is no more heavyweight than them.

I seem to be an utter Google novice by these standards: I often get questions from friends via IRC concerning programming problems. What I usually do (unless I know the answer by heart) is to copy the question (e.g. "How do I concatenate strings in Ruby"), paste it into google and post the link in the IRC messenger without even looking at the results list. Of course, that's just a paraphrased "STFW" but the first hit almost always holds the answer to the initial question. Which shows that the novice approach using natural language works well enough (provided the question ist well formulated and does not contain the word "umbrella").