@eddieclay

I see why you get SIGABRT. This is because you are using “debug/vector” which is almost entirely different from the standard vector except for the interface. It is less efficient and adds a lot of excessively stringent out-of-boundary assertions to keep your program from potential bugs. I did not have this problem because I always use the command line which links to the “released” version at least by default. If you link to the “release version”, you will not see SIGABRT; valgrind will complain nothing. With the standard STL, there is NO memory problem with the example I have shown. In C++ syntax itself, there is nothing wrong with my program. It is the debug version of STL that imposes the requirement, which is helpful, though.

Running…
C array, preallocated: 0.950 sec
C array, dynamic: 2.037 sec
C vector, dynamic (kv_a): 1.271 sec
C vector, dynamic (kv_push): 1.794 sec
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/debug/vector:198:
error: attempt to subscript container with out-of-bounds index 0, but
container only holds 0 elements.

Objects involved in the operation:
sequence “this” @ 0×0x7fff5fbff6d0 {
type = NSt7__debug6vectorIiSaIiEEE;
}
Program received signal: “SIGABRT”.

It’s my attempt to make an OOP language which translates to C and sucks less than C++ (a very unfair description but it puts it into context.)

Anyway – you can learn more about it on the homepage, and this page http://ooc-lang.org/syntax should give you a good fell of its syntax.

Note that it’s still in early development, and ides are welcome (we can be found at #ooc-lang on Freenode)

You may read my other posts about efficient generic programming in C. For generic C libraries, GDSL/Glib uses void*, which may have efficiency issue. Sglib and Sean’s Tool Box use macros, although sglib does not use the best algorithm at least for rb-tree. For generic RB-tree, Niels Provos’ tree library is recommended due to its performance and stability. For generic hash table libraries in C, I recommend my own implementation.

STL is the work of several phenomenal programmers who have considerable influence over the C++ programming. It is difficult for a common/unknown programmer to write something widely accepted by the C community. In addition, good C programmers, like me, love to reinvent the wheel. They do not rely too much on existing libraries as much as C++ programmers do.

I agree with you in general. C++ is unnecessarily overcomplicated. I only use C these days, although I used to systematically study STL source code back to a few years ago.

I am thinking why C++ is so popular. There must be a reason. In my view, the magic of C is to write a variety of programs from a few simple rules. But to combine these rules effectively and efficiently, you must have a programmer’s mind which is not possessed by everyone. Many people after C classes cannot work on real projects at all. They do not know where to start from simple rules. In contrast, C++ gives you many complex rules. After C++ classes, you feel you have really learned something. You can write reasonably good programs without really grasping the essence of programming. For many people, remembering knowledges is much easier than using knowledges. Simplicity attracts someone but also pushes someone away. To this end, C++ lowers the threshold of a qualified programmer.

However, even so I think the adoption of C++ is a historical mistake. To be compatible with C libraries (not C source code), D does much better. It is just too late.

The problem with C++ seems to me they are adding too many overcomplex features but not simplifying anything.

Take autopointers. The idea is yet another thing to obscure memory management but you should either go for managed memory or keep at a lower level, not a horrid in between state. With autopointers you make many small allocations, and you are doing extra allocations for the pointer itself. AND you can easily accidentally assign it to the wrong thing anyway…so what’s the benefit? It’s not only worthless but a very harmful and misguided practice.

A pointer should be a pointer, not some vague idea that you have no idea what it’s really doing on a particular platform. Types with pointers is very likely a mistake, and not the only possible mechanism to avoid assignment to invalid object types.

Memory and pointers are easy concepts but C++ completely obscures them instead of forcing programmers to just use them from the start.

Inheritance is really not something to worry about, though. It’s not the performance issue many make out or it’s not if you are using it in places that make sense.

The biggest performance problem with OOP is that C++ has awful memory allocation that just can’t handle lots of small allocations (such as autopointers) which causes huge waste in space and time.

The real problem, though, is overcomplexity. If you use anything in STL at all, it’s not long before you have to start coding every single thing around the STL in their (very very silly) paradigm. The new casts are a good illustration of what’s wrong with C++’s direction – if you are consciously throwing out constness ever, and I mean EVER, you are doing something very wrong or using a very poorly made library (usually latter).

Templates themselves are nice and would also be a good addition to C, but the way they are used by most people is just awful, including STL.

What really needs to happen is to ditch C and C++ completely. Many of the C++ OOP features are just halfassed and barely functional. IE try and catch, namespaces, having to tell the compiler to use virtual destructors when overloaded. There’s so many old features lingering that it makes it so that most people are also basically redefining C++ as they go, making their code useless to anyone who doesn’t use their exact same paradigm.

I heard there is also OO coding style in Linux Kernel. When programs go further complicated, do something in OO may reduce the load to designed a big system.

It is also the original significance: breaking code into segments with proper authorizing and simplifying the process to design a system.

It is true whether or not choose OOP is a trade-off between efficiency and flexibility.