Re: [std-proposals] Re: proposal to add vector::push_back_()

[wsdwsd]

I think efficiency is more important than robust.

In fact, the best way to deal safe problems is to use iterator-range to limit them.

If we don’t need efficiency, why we use a computer???????????

C++ is faster than C, okay?????

Sent from Windows Mail

From: Victor....@ncl.ac.uk
Sent: ‎Tuesday‎, ‎December‎ ‎3‎, ‎2013 ‎6‎:‎55‎ ‎AM
To: std-pr...@isocpp.org

On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:

In the past, I have got equal speed to an unchecked push_back by using
passing a "generating iterator" to 'insert' (basically write a custom
input iterator which returns a new member of your data whenever
operator* is called).

This has the advantage of not requiring any unsafe interfaces.

This idea was already discussed in this thread. It does have the advantages of achieving the same speed and not requiring any library modification, but it has some disadvantages: it's a boilerplate to write, and the average programmer would not come up with such an unnatural idea mixing iterators with generators, and instead would simply use the good old malloc.

Concerning the idea that unchecked_push_back is unsafe, it was already pointed that:

  * vector::operator[] has undefined behaviour when index is out of range

  * iterator invalidation is a much more serious issue, causing difficult-to-catch bugs

So the behaviour of unchecked_push_back is in line with other vector's methods. It was also pointed that an assertion can be used to check the pre-condition of unchecked_push_back in the debug mode.

It looks like initially the speed/safety trade-off for vector was decided in favour of speed, although some subsequent decisions (like disallowing realloc-like behaviour in allocators and the inhibition of move semantics unless the move constructor is noexcept) go in the opposite direction. So currently vector is neither fast nor safe :-(

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[wsdwsd]

Many low-level programmers don’t need safe-check, if we need safe-check, we should use “at”.

[wsdwsd]

I hate programmers who likes to talk about “robust”.

Often, the programs of them are not robust at all!!!!

Safe-check may cause more unsafe problems and more bugs.

A good program-habit is more important than safe-check!

It can avoid most of safe-problems to develop a good program-habit !!

"Playing” Containers, iterators, algorithms needs a feeling.

After I use the thinking of “iterator-range”, I can hardly get exceptions of out-of-range.

This is the feeling a C++ programmer needs, do you understand?

In fact, adding these operations may make C++ programs more safe.

Some programmers who want to use unsafe operations may use dynamic memory, and manage pointers by themselves, it’s more unsafe!!

PS: The people who can't understand me must not read through “C++ primer 4 or 5”.

Sent from Windows Mail

[R. Martinho Fernandes]

I agree that efficiency is more important than robust. That's why I wrote the most efficient program possible: https://gist.github.com/5363882.

[wsdwsd]

Who said unsafe operations are only used for 0.01% conditions? It's a big prejudice!
Many programs must cater for c-style interfaces. No unsafe_resize, we can hardly use a vector to do it.
After we add unsafe_emplace_back, many programs will use it to replace emplace_back. In fact, if A programmer use a emplace_back, he sometimes can't check wrong answers easily. For example, what he needs to add are 10 elements, but in fact, he adds 11 elements. He can't check the wrong easily. If he uses unsafe operations, when the answer is wrong, the program will crash or run a strange answer. This will tell programs you may wrong.
Just as vectors can't replace arrays, so we made std::array. std::arrays are more unsafe than vectors.


Sent from my Windows Phone

---

From: Andrew Lutomirski
Sent: ‎2013/‎12/‎4 5:54
To: std-pr...@isocpp.org
Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()

On Tue, Dec 3, 2013 at 12:58 PM,  <Victor....@ncl.ac.uk> wrote:
> On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal wrote:
>>
>> Vector is plenty fast and safe. Nobody has shown a serious application
>> where the performance cost of checking size in push_back made any measurable
>> difference in an overall application in an application compiled in release
>> mode.
>
>
>
> You are making a sweeping generalization here. I had a significant
> performance deterioration due to this issue, like 10% for the whole program,
> when I moved from my home-brewed vector-like class to vector. More
> precisely, the innermost loop was a call to std::transform with
> std::back_inserter(vector) as the output range. And it was serious enough
> for me (of course, you're free to choose which applications you consider
> "serious"). I believe that push_back in an innermost loop is quite common,
> although I don't have any statistics to back it up. Another common case
> where vector is VERY slow (for a different reason) is given at the end.
>
>
>>
>> The average programmer is not writing an application where the size check
>> inside push_back is significant enough to make a significant difference in
>> application performance. Vector is designed for the 99.9% case. This
>> proposed optimization is describing an optimization for a 0.01% case.
>>
>
> Confess, you just faked these numbers (they don't even add up to 100% ;-).

>
>
>>
>> >   * vector::operator[] has undefined behaviour when index is out of
>> > range

>> So do arrays, and all other types of indexed memory access.
>>
>
> That was precisely my point: unchecked_push_back would correspond to the
> *p++=... idiom, and its safety guarantee is in line with the other methods
> of vector. In fact, reserve+unchecked_push_back form a very natural
> interface for vector.

Is there any obvious reason that reserve + unchecked_push_back is
better than resize_uninitialized + push_back (+ resize if needed)?
That is, how common is this issue with vectors of nontrivial types?

--Andy

[Billy O'Neal]

> If he uses unsafe operations, when the answer is wrong, the program will crash or run a strange answer. This will tell programs you may wrong. 

If and only if those unsafe operations result in a crash or strange answer. Undefined behavior means undefined -- and unfortunately often works as expected.

Billy O'Neal

https://github.com/BillyONeal/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com

On Tue, Dec 3, 2013 at 4:36 PM, wsdwsd <eulo...@live.com> wrote:

Who said unsafe operations are only used for 0.01% conditions? It's a big prejudice!
Many programs must cater for c-style interfaces. No unsafe_resize, we can hardly use a vector to do it.
After we add unsafe_emplace_back, many programs will use it to replace emplace_back. In fact, if A programmer use a emplace_back, he sometimes can't check wrong answers easily. For example, what he needs to add are 10 elements, but in fact, he adds 11 elements. He can't check the wrong easily. If he uses unsafe operations, when the answer is wrong, the program will crash or run a strange answer. This will tell programs you may wrong.
Just as vectors can't replace arrays, so we made std::array. std::arrays are more unsafe than vectors.


Sent from my Windows Phone

---

From: Andrew Lutomirski
Sent: 2013/12/4 5:54

--
 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

[wsdwsd]

Library containers can be very fast.

Your mean is just as " move-segments"is useless.

We should make vectors  more open to users.

Sent from my Windows Phone

---

From: Ville Voutilainen
Sent: ‎2013/‎12/‎6 7:40
To: std-pr...@isocpp.org
Cc: an...@luto.us; Victor....@ncl.ac.uk

Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()

On 6 December 2013 01:26, Bengt Gustafsson
<bengt.gu...@beamways.com> wrote:
> I think the use case where the speed gain is most profound is when using a
> vector<char> or similar as a buffer into which a file contents or network
> packet is received.


Sorry if I have missed something, but if this gain is indeed profound, can you
provide a real-life measurement of it?

I have, in principle, nothing against adding facilities to vector that remove
the remnants of overhead from it. I am not adamantly against it. I would
like to have practical numbers supporting such facilities, so that we don't
end up discussing ephemeral illusions (and I'm NOT saying this idea
is one, I mean both the arguments for and against it!).

Having said that, vector was never, as far as I understood it, meant to
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safety.
Being the crazy person that I am, I wouldn't find it far-fetched to have
these 'unsafe' facilities in a (pardon the deliberately stupid name)
'fast_vector' or 'unsafe_vector'.

And yes, I would absolutely be for any reasonable facility that is
better than telling people "if you really care _that_ much about
performance, use raw arrays and new and write your own container".

[wsdwsd]

No.class:
vector<vector<int>> vec(1000,vector<int>(1000));

Sent from my Windows Phone

-----Original Message-----
From: "Victor....@ncl.ac.uk" <Victor....@ncl.ac.uk>
Sent: ‎2013/‎12/‎10 6:32
To: "std-pr...@isocpp.org" <std-pr...@isocpp.org>
Cc: "an...@luto.us" <an...@luto.us>; "Victor....@ncl.ac.uk" <Victor....@ncl.ac.uk>
Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()

On Thursday, 5 December 2013 23:39:59 UTC, Ville Voutilainen wrote:
Sorry if I have missed something, but if this gain is indeed profound, can you
provide a real-life measurement of it?

Nobody posted measurements for resize_default_constructed(), but we do have measurements for unchecked_push_back early in the thread, showing 40% speedup (for the whole loop) when an int wrapping class is used.


I'd *guess* that resize_default_constructed() would have similar speedup for elementary types, but no speedup for classes with initialising constructors.

Having said that, vector was never, as far as I understood it, meant to
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safety.

Just a few days ago I posted some comments arguing that vector is neither safe nor fast, with examples.

Being the crazy person that I am, I wouldn't find it far-fetched to have
these 'unsafe' facilities in a (pardon the deliberately stupid name)
'fast_vector' or 'unsafe_vector'.

Sad but true :-( That's exactly what I did, bar the name.

And yes, I would absolutely be for any reasonable facility that is
better than telling people "if you really care _that_ much about
performance, use raw arrays and new and write your own container".

Or rather malloc / realloc, as one doesn't want to call the default constructors (they may do something for non-basic types).

[wsdwsd]

In fact, unsafe_push_back() is very useful. unsafe_resize() is also useful.

In  my opinion, if one thing could make us avoid to use “new[], delete[],  malloc , free” or to reduce the use of pointers, it’s good and could be added into C++.

In fact, std::vector<> is the dynamic-array of C++ style.

Sent from Windows Mail

[Billy O'Neal]

I still remain unconvinced that the type for this is vector. If the user wants unsafe semantics, there's no reason they can't use a separate type which has uninitialized semantics, and can have checks e.g. to make sure T is a POD type.

The argument of "well there is code out there that accepts plain vector" doesn't sell me -- that code should be accepting a range.

Billy O'Neal

https://github.com/BillyONeal/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com

--
 
---

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

[wsdwsd]

“uninitialized_resize()”s not enough.

We should both have uninitialized_resize(), uninitialized_push_back(), uninitialized_emplace_back,uninitialized_insert.

The uses of them are quite different.

in many conditions uninitialized_resize() can’t replace uninitialized_push_back().

I have posted the condition on the net. You could read it.

We should add them all, do you understand??

Sent from Windows Mail

From: Zhihao Yuan
Sent: ‎Tuesday‎, ‎December‎ ‎10‎, ‎2013 ‎1‎:‎14‎ ‎PM
To: std-pr...@isocpp.org

On Sun, Sep 8, 2013 at 3:17 PM,  <Victor....@ncl.ac.uk> wrote:
>
> On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wrote:
>>
>> We could consider a totally different way to handle this, which also has
>> other uses. Admittedly, this can easily crash if misused (just as index out
>> of range or too many push_back_ calls). I will call this tentatively
>> uninitialized_resize(size_t sz). It just moves the end pointer and
>> reallocates as required, but leaves the new elements uninitialized.
>
>
> I think this will never be adopted as vector no longer can enforce its
> invariants. Example:
> {
>     vector<Widget> v;
>     v.uninitialized_resize(10);
>     // at this point the desctructors are called, resulting in a crash
> }

AFAICS this is intended.  The vector can only be destructed
when the invariants are back to work; thus, until the 10 elements
are filled in.  If an exception is thrown before this is done, UB.

PS: It does not mean I'm in favor of this pattern.

Sorry for replying dated posts.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

[inkwizyt...@gmail.com]

you probably need `uninitialized_vector` not `std::vector`.
probably most of your needs would be fulfilled by warper around array of unions.