Hacker News Reader

Comment by wrsh07 | Hacker News Reader

> I recommend sticking with push_back for day-to-day use.

This Google tip of the week gives a good explanation (explicit vs implicit) for why to prefer push back vs emplace if you don't need the benefit of emplace: https://abseil.io/tips/112

In particular:

> Let me answer that question by asking another: what do these two lines of code do?

vec1.push_back(1<<20); vec2.emplace_back(1<<20);

> The first line is quite straightforward: it adds the number 1048576 to the end of the vector. The second, however, is not so clear. Without knowing the type of the vector, we don’t know what constructor it’s invoking, so we can’t really say what that line is doing

View on HN

That argument is wrong, since push_back(1<<20) can invoke an implicit conversion to value_type, so by the same dint you also cannot say what that line is doing.

If you don't allow implicit constructors in your codebase, this can be avoided.

If you make the mistake of creating an implicit constructor when you shouldn't, yeah, but that's your mistake. The argument is fine.

Are you saying that for the first line, one could say that...

> Without knowing the type of the vector, we don’t know what constructor it’s invoking, so we can’t really say what that line is doing.

No, that's not what I'm saying. I have no idea where you saw me saying anything about those 2 lines or vectors in my sentences.

I am saying 1-arg constructors that aren't semantically "conversions" from that arg need to be be explicit, not implicit. If you make them implicit, that's your mistake; tools can catch that mistake statically.

Uh. I'll try to be more explicit. Let's say that someone in a library somewhere has made what you consider to be a mistake. Or they consider something to be a conversion but the constructor is not trivial. For the push_back construction, can you then say what the call does without knowing the types?

> Let's say that someone in a library somewhere has made what you consider to be a mistake. Or they consider something to be a conversion but the constructor is not trivial. For the push_back construction, can you then say what the call does without knowing the types?

I don't get the point of your question. You might as well ask: "Let's say someone in a library somewhere has defined their type's operator< to wipe your disk. If you see std::less<>()(a, b), can you say what the call does without knowing the types?"

To which the answer is... well, obviously, no. Same answer to your question.

What is this supposed to imply?

This conversation makes me really happy I have successfully avoided C++ for the past two years.

There was very little in this conversation that was C++ specific, so it's kind of baffling that this conversation led you to that conclusion. But in general: yes, that's a good thing. Don't use C++ if you don't need to. It has too many sharp edges and it shouldn't be used unless it's really necessary.

Let's narrow this down even more.

Someone has made an implicit constructor that makes a network call because... people are dumb. This implicit constructor takes an integer.

Does the following code make a network call?

    vec.push_back(4);

That obviously depends on the type of vec, which you've given no information about.

...could it be that

> Without knowing the type of the vector, we don’t know what constructor it’s invoking, so we can’t really say what that line is doing.

Yes? The sky is also blue. Did I ever disagree with either? What point are you trying to make?

Ah there's some context missing. As user dataflow notes, if you have a convention of single arg constructors being explicit (which Google does: https://google.github.io/styleguide/cppguide.html#Implicit_C...), then you can't run into this.

Note this isn't really specific to Google, or really much of a "convention" (insofar as a convention is something you can reasonably avoid following). This is the only correct way to write C++, really -- implicit 1-arg constructors are specifically called "converting constructors" [1], precisely because their very purpose is to define implicit conversions. You don't define them unless implicit conversions make sense for your type. The standard library pays attention to this just as much -- that's why size_t isn't implicitly convertible to std::vector.

[1] https://en.cppreference.com/w/cpp/language/converting_constr...

Of course (having learned most of my cpp at Google) I agree with you. However, the language default is incorrect (you have to opt out of implicit conversions rather than opt in) which is why I phrased it like that

push_back always sounds clunky and dissonant to me. Gotta wonder what was wrong with ".append" -- guess it wasn't applicable to stack-based containers or something.

I wonder if they designed the APIs for vector, list, deque, etc together

On deque it all feels fairly natural. Ruby's shift and unshift are cool, but I always struggle to remember the words

yes, they did

ruby and js got shift and unshift from perl, which got shift from sh, where it's the only way to iterate over an array or other list. (also, sh only has one array)

in the old country, instead of shift and unshift, we said cdr and cons. we didn't have push and pop; if we wanted to mess with the backside of a list we had to reverse it first. but our code ran ten times as fast as ruby and had implicit undo

at some point don hopkins suggested, i think it was, eat and barf for, respectively, push and pop on the front end. the back end would then necessarily be boof and shit (not shift). betcha wouldn't forget which end those pertained to

Push and pop belong on top, not back.

ikr

Append to which side? Push and pop are terms of are for queues and stacks which containers can be and the back and front tell us which end of the container we mean

Append implies the back or end of something, while "prepend" would be the analogous term for the front.

From a natural language perspective, I agree. In practice, however, I see far more container libraries use the terms: (1) add or append and (2) insert w/ index (instead of prepend). Do you know of any container libraries that use the term prepend? From time to time, I use it in a function for some kind of business logic, e.g., "prependMeetingInvite()".

JS dom manipulation has prepend and append. These always felt quite natural to me. While push back feels weird. The act of pushing feels out of place and I also think back and front may also be ambiguous.

Prefix would be the traditional term.

Wouldn’t prefix be the traditional counterpart to suffix, not to append?

Yes, it would. But prefix is also a verb that means to "to add something before another thing" which is the counterpart to append.

Suffix is also a verb that means “to add something after another thing”. I think the verb prefix is the counterpart to the verb suffix, the noun prefix is the counterpart to the noun suffix, and the verb prepend is the counterpart to the verb append.

You can look at the earliest sources of the STL from 1994 pre-standardization and the names were already used back then. It's not entirely unsurprising considering even back then there was a vector and a deque.

You have Alexander Stepanov to thank: http://stepanovpapers.com/STL/DOC.PDF

The thought was to have the symmetry of push and pop, on both ends of a sequence container. See table 11 on page 22 (actually page 24 of the PDF).

I agree that push_back/pop_back is a bit clunky, but I've gotten used to it tbh.

What I haven't gotten used to is the terms "shift" and "unshift" from other languages. But I never get confused by C++'s push_front/pop_front.

And I think the consistency has some value. Is it enough value to warrant the extra verbosity? Meh, I think it's more or less a wash.

A minor problem with "append" (and "prepend" for the front) is that, as far as I know, there isn't a really satisfying word for the reverse operation.

A search for the opposite of "append" suggests "remove", "subtract", "detach", "disconnect", "disjoin", "unfasten", "reduce", "diminish", and more. None of them really have the same "at the back" connotation that "append" has.

"Push" and "pop" are well known from stacks so it makes sense to use them for operations on one end of list-like containers. That still leaves the problem of what to call the similar operations on the other end.

I suppose we could sidestep that problem by only providing them at one end. So say push() adds to the back and pop() removes from the back.

If you want to operate at the front just reverse the list, do your push or pop, and then reverse the list again and let the optimizer deal with eliminating the two reverses. :-)

append is used for sequences. push_back is used for individual elements. Maybe not the most intuitive terminology, but there's value to separating the two ideas.

> suppose you have a std::vector<std::vector<int>> and you want to append a number to the end of the first vector, but you accidentally forget the subscript. ... if you write my_vec.emplace_back(2<<20), the code will compile, and you won’t notice any problems until run-time.

How is this not caught by the type system? 2<<20 is clearly no way, whatsoever, compatible with a vector<int> type.

Iiuc, it’ll call the vector<int> constructor with 2<<20 and make you a huge vector.

The compiler can't read your intention. Emplace means "forward these arguments to the constructor", so it forwards those arguments to the constructor (in this case, vector<int>).

With push back it would be caught by the compiler because you can't implicitly convert 2<<20 to a vector<int>

We cannot see the full code context from the blog post, but I felt similar about push_back() vs emplace_back() in the blog post example.

Either of these are more explicit and clear to me:

    widgets.push_back(Widget(foo, bar, baz));
    widgets.emplace_back(Widget(foo, bar, baz));

... even if computationally worse.

Reply on news.ycombinator.com