Why do C++ folks make things so complicated? • Hacker News Board

Re: Why do C++ folks make things so complicated?

#11

Post by microtonal » Wed, Jun 15, 2011, 12:56 PM UTC

If you want to make such a distinction, Qt is probably what would come close to top-C++. It offers dynamic binding via signals/slots, Java-like iterators, simple multi-threading/parallelization, signal/slot-driven networking, database access, and some automatic memory management (deletion via parent widgets, and auto-pointers). It only misses the proposed compiler warnings to indicate that 'bottom-C++' is used.

Still, for the average programmar 'top-C++' makes a miserable language. Want to write a simple class? You have to make a separate header file and decide what methods to inline/make virtual, etc. Want (binary) compatibility? You'll have to worry about things such as PIMPL and d-pointers.

It's a low-level language, and low-level issues will always leak into higher-level subsets. And why should one go through the effort? The old mantra "write in a higher language, rewrite what is too slow in C/C++" works fine.

Re: Why do C++ folks make things so complicated?

#12

Post by blub » Wed, Jun 15, 2011, 1:01 PM UTC

microtonal wrote: post #11

If you want to make such a distinction, Qt is probably what would come close to top-C++. It offers dynamic binding via signals/slots, Java-like iterators, simple multi-threading/parallelization, signal/slot-driven networking, database access, and some automatic memory management (deletion via parent widgets, and auto-pointers). It only misses the proposed compiler warnings to indicate that 'bottom-C++' is used. Still…

Performance is a cross-cutting concern, you should factor it into the design of the application and not remember it when doing field tests and noticing that the software is too slow.

This doesn't mean that you must use C or C++, but assuming that you can always rewrite the slow parts in C or C++ is inviting disaster.

Re: Why do C++ folks make things so complicated?

#13

Post by cageface » Wed, Jun 15, 2011, 1:01 PM UTC

C++ already contains "top" and "bottom" C++. You can write boost-style code, with heavy use of smart_ptr and STL algorithms & functors, or you can stay pretty close to the "C with classes" layer.

Re: Why do C++ folks make things so complicated?

#14

Post by rch » Wed, Jun 15, 2011, 1:02 PM UTC

eru wrote: post #5

rch wrote: post #4

Earlier quoted context omitted.

Not so sure about that... Consider the Template Numerical Toolkit: extending it would be Bottom while using it would be Top (reference counting, overloaded for for both row-major or column-major array access, etc.). C# takes things several steps further down the road. http://math.nist.gov/tnt/

By the way, why do C++ people seem to think that reference counting is a good idea?

In TNT the goal is memory-efficiency. Maybe I should have said weak-reference assignment instead?

Re: Why do C++ folks make things so complicated?

#15

Post by blub » Wed, Jun 15, 2011, 1:03 PM UTC

gigamonkey wrote: post #9

gaius wrote: post #7

Earlier quoted context omitted.

Because in some situations you can't tolerate GC pauses.

But you can tolerate ref counting pauses? (When you release the last reference to the last object keeping a large tree of objects alive and have a lengthy cascade of objects being freed.)

If speed requirements are so tight you should preallocate the memory. GC is completely out of the question.

Re: Why do C++ folks make things so complicated?

#16

Post by jpablo » Wed, Jun 15, 2011, 1:10 PM UTC

blub wrote: post #12

microtonal wrote: post #11

If you want to make such a distinction, Qt is probably what would come close to top-C++. It offers dynamic binding via signals/slots, Java-like iterators, simple multi-threading/parallelization, signal/slot-driven networking, database access, and some automatic memory management (deletion via parent widgets, and auto-pointers). It only misses the proposed compiler warnings to indicate that 'bottom-C++' is used. Still…

Performance is a cross-cutting concern, you should factor it into the design of the application and not remember it when doing field tests and noticing that the software is too slow. This doesn't mean that you must use C or C++, but assuming that you can always rewrite the slow parts in C or C++ is inviting disaster.

Doesn't that go against all we have learned in CS? Early optimization being the root of all evil. And don't optimize what you think will be slow, but what you have measured to be slow?

Re: Why do C++ folks make things so complicated?

#17

Post by sambeau » Wed, Jun 15, 2011, 1:12 PM UTC

gigamonkey wrote: post #9

gaius wrote: post #7

Earlier quoted context omitted.

Because in some situations you can't tolerate GC pauses.

But you can tolerate ref counting pauses? (When you release the last reference to the last object keeping a large tree of objects alive and have a lengthy cascade of objects being freed.)

Generally, that will still be far smaller than copying every object pointed to on the stack.

Re: Why do C++ folks make things so complicated?

#18

Post by NickPollard » Wed, Jun 15, 2011, 1:12 PM UTC

gigamonkey wrote: post #9

gaius wrote: post #7

Earlier quoted context omitted.

Because in some situations you can't tolerate GC pauses.

But you can tolerate ref counting pauses? (When you release the last reference to the last object keeping a large tree of objects alive and have a lengthy cascade of objects being freed.)

If you use reference counting for a full tree hierarchy of objects, then you have to expect that.

The point is that sometimes in C or C++ you have a small, flat selection of objects that you want to dynamically create and destroy, whilst everything else falls into fairly stable patterns than can easily be handled manually.

An example from my field; computer games: It's quite common for game engines to use reference counting for resources such as textures. These days, it is very common for textures to be streamed into and out of memory during gameplay, either because it's a large game-world with whole sections being streamed, or simply for LoD (level-of-detail) reasons - objects in the distance have low resolution textures, when they get closer they become higher resolution.

To handle this, it's common to have a pool of textures that use reference counting, and every model/renderable that uses a particular texture increments or decrements the refcount as appropriate. The texture itself is just a flat blob of data, so when a texture is freed, there's no worry of large cascading frees.

This approach is very simple and easy to implement when you only want it on a small selection of the program.

Re: Why do C++ folks make things so complicated?

#19

Post by rch » Wed, Jun 15, 2011, 1:29 PM UTC

gigamonkey wrote: post #9

gaius wrote: post #7

Earlier quoted context omitted.

Because in some situations you can't tolerate GC pauses.

But you can tolerate ref counting pauses? (When you release the last reference to the last object keeping a large tree of objects alive and have a lengthy cascade of objects being freed.)

When it matters, I'm usually keeping a pool of de-referenced objects around anyway, so I can just reinitialize rather than allocate... memory is explicitly managed, not blindly RCed/GCed.

Re: Why do C++ folks make things so complicated?

#20

Post by michaelfeathers » Wed, Jun 15, 2011, 1:43 PM UTC

I think that the main reason that C++ is so complicated is because they've had to maintain compatibility with C's model. The declaration/definition and value/reference dichotomies double up a lot of work. When you add the fact that they wanted to base STL on pointeresque semantics (iterators) and people started using template meta-programming to deal with the lack of reflection, well, it all got complicated.