Jump to content

  • Log In with Google      Sign In   
  • Create Account


std::vector vs std::unique_ptr


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
28 replies to this topic

#21 iMalc   Crossbones+   -  Reputation: 2299

Like
0Likes
Like

Posted 02 July 2012 - 01:29 PM

Oh, so you did. Nobody responded about it though. Oh well.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

Sponsor:

#22 rnlf   Members   -  Reputation: 1117

Like
0Likes
Like

Posted 03 July 2012 - 06:25 AM

I am using unique_ptr<x[]> whenever I want to read large arrays directly from binary files. It skips vector's default-initialization of the allocated memory and allows efficient use of istream::read instead of per-element-read operations.

Does anyone know a way to get these advantages (maybe there are even specific compiler optimizations for this case?) by using a vector instead of unique_ptr<x[]>?

Cheers, rnlf

my blog (German)


#23 BitMaster   Crossbones+   -  Reputation: 3894

Like
0Likes
Like

Posted 03 July 2012 - 08:49 AM

I'm not sure if you can bypass the default initialization, but &myvector[0] (or better myvector.data() on C++11) points to the exact same block of memory you can use for istream::reads.

Edited by BitMaster, 03 July 2012 - 08:49 AM.


#24 rnlf   Members   -  Reputation: 1117

Like
0Likes
Like

Posted 03 July 2012 - 09:02 AM

Yes, I know that. But for large chunks of memory (like large textures, vertex or audio data) I would like to circumvent the initialization. I think, using a unique_ptr ist reasonably secure and it is also quite convenient, since the size of the block is always known beforehand and will never be resized.

i just thought, maybe someone knows a way to get the best out of both worlds ;-)

my blog (German)


#25 Hodgman   Moderators   -  Reputation: 29493

Like
0Likes
Like

Posted 03 July 2012 - 09:11 AM

I keep it simple and just use char* along with simply disallowing transfer/modification of the buffer's initial lifetime (which is assigned to a scope-stack)... that's probably not the most popular C++-esque answer, but it works for me, is dead simple and pretty hard to screw up Posted Image

#26 Cornstalks   Crossbones+   -  Reputation: 6974

Like
0Likes
Like

Posted 03 July 2012 - 10:13 AM

@rnlf: I googled your question and found this. For those too lazy to click the link, the relevant code is:

#include<iterator>

std::ifstream testFile("testfile", std::ios::binary);
// ...
std::vector<char> fileContents;
fileContents.reserve(fileSize);
fileContents.assign(std::istreambuf_iterator<char>(testFile),
                    std::istreambuf_iterator<char>());

All credits to wilhelmtell for the code. Whether or not this is more optimal though, is up for debate, as I think it has potential to be slightly slower (but not faster) than just a simple std::unique_ptr (I say it could potentially be slightly slower because it depends on exactly how the C++ implementation implements std::ifstream::read() and the above code... buffering (and copying into a temporary, intermediate buffer) can make a big difference, and I imagine that a single std::ifstream::read() may potentially just read directly into the buffer, while the std::istreambuf_iterator may potentially cause data to be read into an intermediate buffer before copying it over...). If you care that much, just try each one, look at the asm, and profile.

I might just go for a std::unique_ptr, for simplicity's sake.

Edited by Cornstalks, 03 July 2012 - 10:21 AM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#27 rnlf   Members   -  Reputation: 1117

Like
0Likes
Like

Posted 03 July 2012 - 10:25 AM

@Cornstalks: when I initially googled for the topic, I found this stackoverflow thread as well, but just as James McNellis writes a few comments below, this does not actually seem to be standard compliant. I still have to look it up in the standard to get confirmation though.

it seems to me, there really isn't a nice and correct way to achieve this by using a vector (and in fact, there is no real benefit using a vector instead: Freeing of the array is done automatically when it goes out of scope, it is exception safe, it is not easier to make mistakes with the arrays size and indexed access as it would be with a vector and it saves the overhead of the - in this case - unneccessary management data). Plus it has a much more natural syntax that does not feel like abuse of a vector's interface.

So I guess I'll just stick to it. Thank you anyway, I feel much more confident using this versiow now :-)

Cheers
rnlf

my blog (German)


#28 Cornstalks   Crossbones+   -  Reputation: 6974

Like
0Likes
Like

Posted 03 July 2012 - 11:23 AM

@Cornstalks: when I initially googled for the topic, I found this stackoverflow thread as well, but just as James McNellis writes a few comments below, this does not actually seem to be standard compliant. I still have to look it up in the standard to get confirmation though.

That was because his first reversion was, which he fixed (see his response to James McNellis's comment).

But yeah, I like std::unique_ptr for this better, anyway. It makes it a little clearer you have no plans on resizing the buffer, anyway.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#29 rnlf   Members   -  Reputation: 1117

Like
0Likes
Like

Posted 03 July 2012 - 11:26 AM

Ah, I'm sorry. Missed the two hidden answers. But I'll stick to unique_ptr, just as you said.

my blog (German)





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS