Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 May 2010
Offline Last Active Dec 21 2012 06:19 AM

#4953700 std::vector vs std::unique_ptr

Posted by on 28 June 2012 - 10:30 AM

I'm pretty sure the default deleter does a delete[] on array unique_ptr's. The template is specialized for array types.

Anyway, transferring ownership is pretty easy with a vector too. If you return a vector created in the same function, it'll actually trigger the move semantics, resulting in only the pointer to the contents being moved to the new vector "copy" outside the function. That means the move takes constant time no matter how big a vector.

To force move semantics, you use the std::move function. This effectively transfers ownership the same way.

Only difference is that the unique_ptr enforces the ownership a bit more by not being implicitly copyable.

Very few occations call for a C array (with or without unique_ptr), and if you actually need a constant sized container, use the new std::array rather than a C-array. The std::array can be entirely stack allocated as well since it's constant sized, which is pretty handy at times.

#4952493 c++, SDL, sstream, and brain farts.

Posted by on 24 June 2012 - 06:38 PM

Close, but no cigar. clear() does not clear the contents of the stringstream. It clears the error control state.

Oops.. poor observation from my part. I usually never reuse string streams that way.

I usually only keep it in the scope where it's directly used and let it crumple by the wrath of the }
I doubt there's much to gain from storing a stringstream away from its 'working area'

#4951712 Dedicating my whole life to creating my dream game. Going to college

Posted by on 22 June 2012 - 06:11 AM

I do programming because I love programming.. and I happen to love games too, so I program games! If you don't have the passion for game programming and you're going about it yourself, it will be really difficult.

I'm also quite artistic, good with sketching and painting, music and so on.. I went down that track first because I thought that was my passion. After a year in art school, it turned out I did more programming in my own time than I spent time on those creative skills. Go figure?

Are you sure you're the programmer type? You got to love solving lots and lots of logical (or somethings not so logical) problems. That has to be a passion, next to the passion for making a game.

There's other ways of coordinating a game project for the ambitious. Realizing what your skills are and what skills you can recruit is essential for any project to reach completion. Do some proper soul searching. Are you really a jack of all trades, passionate for each facet of game development?

I know I'm most focused on the programming. That's why I'm now hiring a friend to make the music, even though I could do it myself. I'll probably get someone to make the art assets too, which I'd also be capable of, but don't really want to spend my time on.

I wouldn't completely crack down on "game dev" collage. It's a chance to do serious networking. Get to know people! Maybe you'll find your game development soul mate. I am chosing CS at university though, because I really want to do programming in depth. Collage is just as much about learning as it is about meeting similarly minded people.

#4951683 Which is faster? std::priority_queue or std::multimap

Posted by on 22 June 2012 - 04:19 AM

A priority_queue is usually just a vector sorted as a heap1, according to cpluplus.com

The map is sorted with an RB tree, containing nodes swimming in memory.

I can't give you exact performance comparisons (you'd really have to do that yourself), but there's a few things to say about vector and map (or list).

A vector gives a consistent memory block, which helps a lot with the speed of fetching if it's used much. Maps and lists have an extra pointer, which means the node is anywhere in memory and most likely not already in cache unless its very recently used.

A priority queue got to maintain the heap however, but once sorted the first time, this is a fairly small operation. Usually faster than the cycles required to fetch a map node on a cache miss!

But as earlier posters say.. they are for different purposes and you should simply chose what's right for the job.

1heap in this case is not the 'free memory'. It's a form of sorting structure within an array.

#4950964 Overusing smart pointers?

Posted by on 20 June 2012 - 08:30 AM

If the committee really feels like unique_ptr should take the place of new/delete why not implement it in the language?

The main reason I see is because the std pointer templates are very generic implementations. They are made with the general case in mind, but far from every case. People will still find needs for new & delete. You may need your own memory manager and then you'll still need the "lower level" stuff. Having the template rather than a language feature also allows people to actually review the code for it, and perhaps build their own using the std version as a guide.

C++ fundamental types are all very simple structurally. A smart pointer with additional memory allocations, ref counting and destructors are miles away from a raw pointer which is only a memory address requiring no initialization or destruction, only assignment. I think this is one of the reason why it's simply a library implementation. C++ isn't a managed language and doesn't aim to be. It's the programmer that should make the choices without being too inclined by the language features.

Arbitrary typedef? Alright, say you've got an object which you've at first used a unique_ptr<MyObject> (or MyObject*, what ever). This works well for a while in your design. A while later you've come to use this plain object declaration in a lot of places, but now require to exchange it with a shared_ptr<> or ^. If you had just used a typedef MyObject_ptr it'd be a one line change instead of having to change every single line. This use for typedef goes for a lot of things, like container types. My point being, you should probably be using a typedef anyway so a preference for a symbol ^ instead of a template makes no difference.

[...] to me, they feel too much as an afterthought and totally extraneous to the language.

I would agree if it was a higher level language than C++. The code generated from the smart pointers is just as optimized as if they were a "primitive" type of the C++ language. Creating a smart pointer in a language that runs on a VM layer, then absolutely yes. Then you'd want the language to cut away the extra layer of the interpretation and just get down to business. But that's not C++.

#4950896 Overusing smart pointers?

Posted by on 20 June 2012 - 03:27 AM

Actually Stoustrup himself suggests to use smart pointers as "last resort", expecially shared_ptr .

It depends on what you mean with smart pointers. On the Going Native conference earlier this year they discussed the new smart pointers, that is both the unique_ptr and shared_ptr.

B. Stroustrup did say shared_ptr should be a last resort, but the unique_ptr should absolutely be used instead of any new/delete case. It was clearly stated that this should be the new way of handling heap objects in C++. "You should never have to call delete on your own."

Raw pointers still has its uses though, as also discussed at the conference, but they should always be perceived as non-owning pointers that you must guarantee never outlives the object it points to. This is usually the case when a child object has to point back to its parent, where the parent holds an owning pointer of the child. You could use a weak_ptr here, but it's pointless and creates unnecessary overhead. - The intention of this is however only clear if you always use the new smart pointers in the other cases, which is a small theoretical change in code style, but a very large practical change.

When ever I have a class that I put on heap, I usually put in a public typedef for a unique_ptr of that class. Simply MyClass::uptr_t, which honestly isn't that more straining to write that MyClass*. Or declare it outside the class as MyClass_uptr. The added syntax by unique_ptr<> is a poor excuse not to use them. Who can't say they should use typedef a bit more anyway?

#4947610 Extremely Large numbers in C++

Posted by on 09 June 2012 - 03:17 AM

It'd be easier to just say 10^100.. save you the counting of zeros ;)

A standard 64bit datatype that covers this number already exists. It's called a double! It'll give you numbers up to something around 2.2*10^308 and down to 2.2*10^-308 with precision of 15-17 digits.

But, if you want to cover 10^100 + 1 with exact precision, then you'll need a heck of a big data type.. and its beyond me how you'd do it.

I suggest a bit of reading on wikipedia:

And the recent altdevblog series on float:
http://www.altdevblo...-of-odd-floats/ (this article has links to all the previous ones, start with the first one )

#4946530 need help with data oriented design

Posted by on 05 June 2012 - 12:02 PM

There's a bit more manual tracking, that's true. One of the downsides of DOD is the extra foresight required when designing the code for it.

Glad I could help ( and be sure to use the rep button <-- ;) )

#4940009 C++ - do you use STL in your game?

Posted by on 14 May 2012 - 03:48 AM

I agree with jbadams post with a few additions.

Two things to keep in mind.

First, there's a few people out there who aren't aware of the iterator debugging in visual studio's implementation of the STL (standard template library) containers. This causes a major slowdown in debug builds, and release code are often tens of times faster without it! Declare NDEBUG, or some _NO_ITERATOR_DEBUG (I think it was) to get rid of it. You can find the details on msdn if need be. It's a good safety net though that can really catch nasty bugs.

Second of all: all STL and standard library features are generalized to allow for a one-fits-all solution. This is generally a good thing, and they've implemented it in such a great way so that you can even assign your own memory allocators to avoid that potential slowdown too, which was mentioned before. Having them take memory from a pre-allocated pool greatly improves performance for the linked containers.

..But, generalized is always generalized, which means that you can't optimize it for your particular case and may run a bit slower because of it. You'd still have to be a damn nifty coder to make it better and as stable as the STD library.

Saying that, STL containers is my first choice, always. Most reasons stated by jbadams already.