C++ isn't a bad langauge

[blueberry]

My use of reference counting was to implement a resource handler.

The problem is if I use a ResourceHandler.createInstance("file") type scheme it would mean looking up the file every time I need a resource.

To solve this problem I used a ResourceHandler.getResourceReference("file") scheme, but this would have the problem of not knowing when to free the resource. This is where reference counting comes in.

The segfault was from a std::set or something inside sf::sprite getting corrupted cause the resource it was connected to get deleted.

[Disch]

Ah. yes that is very useful. I stand corrected.

[tition]

Sometimes, the expensive time is execution time, in which case having a container do bounds checking is more expensive than just programming correctly.

I absolutely agree, and C++ has excellent support for both approaches.

You'd have to implement the stack unwinding yourself (unless you're using glibc) though.

Yep, did the stack tracing myself^*. No stack unwinding though: too complicated and system dependent. Tried a few ``ready libraries'' but they were all system dependent.

Stack tracing is very easy though: it's one line of code in the beginning of each function body. I also macroed it all, so if I ever need to squeeze speed out, I can do with a one-line change. There was no visual performance drop, and the benefit is way too large for me to do any bench-marking.

*I do not store the states of the local variables, just the function name, file location, and start of function body line number.

[chrisname]

Oh, right, you did it that way. I definitely agree that it's useful to do that, but I stick to STL containers. I just realised also that stack unwinding with C++ wouldn't really work because of the name mangling.

[tition]

I find that the speed efficiency of std:: containers is offset by the lack of flexibility: you definitely don't want to change the implementation of an stl container. You could end up wrapping up stl containers in your own classes, but this way you will end up doing a similar amount of work as if you did the classes yourself.

To me the greatest benefit of std:: containers is that, well... they are standard. Most people using c++ are in fact familiar with std:: containers, or at least can very quickly look up enormous documentation on the web.

So, if you are in a team, or want to be in one, you should stick to std:: containers, to reduce the learning curve/coordination costs. However, if you work alone, writing your custom classes is not a minus. Also, implementing a small feature in a custom class can be faster than looking up the documentation.

[chrisname]

Well, if you need to do something that the STL containers don't let you do, then first you should make sure that you really need to do that thing and that it's the best way to do it, and if you still need to do it, then you should write your own (or a wrapper).

[tition]

then first you should make sure that you really need to do that thing and that it's the best way to do it

I disagree. Sounds very much like the java mindset ("the high priests of Sun at the great Oracle of the land have already determined what we, the sheep, should believe in"). Prudence suggests that you should be critical to yourself, but the same prudence suggests you should be critical to the authors of the standard libraries/language designers.

[helios]

"the high priests of Sun at the great Oracle of the land have already determined what we, the sheep, should believe in"

I think it has less to do with this and more to do with not reinventing the wheel for no good reason.

[tition]

I think it has less to do with this and more to do with not reinventing the wheel for no good reason.

The boundary between the two (reinventing the wheel and doing something in your, possibly novel way) has never been clearly drawn.
Example: every programming language.

[helios]

That's what the "no good reason" part is for.

[zb0S216C]

tition wrote:

"I find that the speed efficiency of std:: containers is offset by the lack of flexibility: you definitely don't want to change the implementation of an stl container. You could end up wrapping up stl containers in your own classes, but this way you will end up doing a similar amount of work as if you did the classes yourself. "

True. The STL containers are designed for general purpose usages, as is the language. I find that the STL containers do not suit the needs of all projects, so they have to create containers specific to the project. I think creating containers is an excellent way of gaining experience.

<sub>I haven't used any STL containers in a long time. Mine are all custom made :)

Wazzak</sub>

[Disch]

I find that most people who claim std containers are not flexible often simply don't know how to use them.

I stuggle to think of anything you would want to do with a dynamic array that you can't do with a vector. Or anything you'd want in a linked list that can't be done with list.


The only functionality I've wanted in a container that STL doesn't provide is pointer ownership. So for that I use boost's pointer containers (which operate identically to STL containers, only they delete the element when it's removed from the container).


Creating containers certainly is a fun and educational exercise, but not exactly practical. I certainly wouldn't want to maintain someone else's code when they needlessly made their own container classes for everything just to be cute or because they weren't familiar with STL.

[1yR4jE8b]

The only functionality I've wanted in a container that STL doesn't provide is pointer ownership.

Doesn't std::unique_ptr<T> solve this problem?


http://msdn.microsoft.com/en-us/library/ee410601.aspx

unique_ptr uniquely manages a resource. Each unique_ptr object stores a pointer to the object that it owns or stores a null pointer. A resource can be owned by no more than one unique_ptr object; when a unique_ptr object that owns a particular resource is destroyed, the resource is freed. A unique_ptr object may be moved, but not copied; for more information, see Rvalue Reference Declarator: &&.

[Disch]

AFAIK you can't put unique_ptrs in a container for the same reason you couldn't put auto_ptrs in a container: objects need to be copyable.

You can use shared_ptr, though. But it comes at a performance price. Why pay for reference counting when you don't need it?

[1yR4jE8b]

Not anymore, Move Constructors allow container reallocation without copying.

[Disch]

vector's constructors still operate on object copying, though... do they not?

I fail to see how this constructor would work without object copying:

vector<double> foo( 10, 3.14 );

[Cubbi]

you can't put unique_ptrs in a container for the same reason you couldn't put auto_ptrs

Huh? vector<unique_ptr<T>> is a common programming pattern. Some people say the main reason unique_ptr exists is exactly because it can be put in containers.

[tition]

I find that most people who claim std containers are not flexible often simply don't know how to use them

Agree, but that raises a question: which is faster: learning how to use std:: container or writing (the parts you need) yourself?

[Disch]

Cubbi:

I didn't know that. Thanks for clarifying.

Agree, but that raises a question: which is faster: learning how to use std:: container or writing (the parts you need) yourself?

Depends on the person, really. But learning how to use STL containers is ultimately more useful in the long run.