On 20/03/2012 06:35, henrikv wrote:
>  Hello group!
>
>  When writing parallel code, I often allocate a vector for results. I
>  allocate the complete vector with a single resize. What I'd like to do
>  is to tell the resize not to initialize the content, since this will
>  be overwritten anyway.

Isn't that what reserve() is for?


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 24.03.2012 01:09, schrieb henrikv:
>
> On 21 mar, 19:35, Francis
> Glassborow<francis.glassbo...@btinternet.com>   wrote:
>>
>>  Isn't that what reserve() is for?
>
>
> What I want to do is to allocate a vector for results calculated in a
> parallel loop. Reserve+push_back will not work, since it's not
> guaranteed that results will be stored in a predictable order. You
> might even get multiple push_back's executed at once, which I suspect
> isn't a great idea.


What you describe sounds like a data race to me, so every normal
assumptions have lost their foundation.

Please elaborate in more detail, but speculating upon games with
undefined behaviour doesn't look like something that the Standard
Library should pro-actively support.

HTH & Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 24/03/2012 00:09, henrikv wrote:
>
> On 21 mar, 19:35, Francis
> Glassborow<francis.glassbo...@btinternet.com>   wrote:
>>
>>  Isn't that what reserve() is for?
>
>
> What I want to do is to allocate a vector for results calculated in a
> parallel loop. Reserve+push_back will not work, since it's not
> guaranteed that results will be stored in a predictable order. You
> might even get multiple push_back's executed at once, which I suspect
> isn't a great idea.
>

If multiple simultaneous push_backs are possible then you will have to
deal with the problem of multiple threads. How are you going to
determine which element of the vector will be assigned to each
result?. And how will you manage to store results computed
concurrently in a predictable order.

Those issues can be dealt with, but being concerned about the cost of
default initialising your vector seems to be unnecessary.

Just make sure that the objects you are creating have a default
constructor that does nothing.
>
>


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 29.03.2012 21:28, schrieb Pedro Lamar   o:
>
> Em sexta-feira, 23 de mar   o de 2012 21h11min22s UTC-3, Kevin McCarty  escreveu:
>
>>  Case 1)  Interfacing with old (C?) code that will initialize a
>>  contiguous block of memory in-place.  One can't always expect that
>>  existing code can be rewritten to take a vector and call push_back or
>>  emplace_back on it.
>>
>>  E.g., supposing the existence of something called std::no_initialize
>>  (whatever that might be)
>>
>>  // some old 3rd-party library function; maybe it calls fread()?
>>  extern "C" initialize_mem(size_t sz, int * mem);
>>
>>  vector<int>    ints(42, std::no_initialize);
>>  initialize_mem(ints.size(), ints.data());
>
>
> In the OP's use case, there is a known amount of "results" for which space must be allocated.
>
> And it is desired to have space allocated, but no constructors run on it.
>
> Isn't uninitialized-land where operator new and std::allocator live? Why not go there?


Yes, this is certainly possible. Just provide an allocator, where
construct (and presumably also destroy) is basically a no-op. I
certainly would not recommend this technique generally, because it
requires a cool head and a stable nervous system ;-)

Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]