Add “value” function for associative containers

[Andrey Matveyakin]

I propose to add a function called “value” to all standard associative containers. It should work like “operator[]” or “at” function except that it returns a default value when there is not such key in the container.

The signature is

T container::value(const Key& key, const T& default_value = T()) const;
for std::map, std::unordered_map, etc. and

T container::value(int index, const T& default_value = T()) const;
for std::vector, etc.

Qt users are already familiar with the “value” function: all the Qt containers (QList, QMap, QHash, etc.) have it. Java provides similar functionality via “get” function. The “value” function is very convenient in many cases and its equivalent expression (find + if or ternary operator) bloats the code a lot, so I no reason why we can't have it.

[Tony V E]

--
 

std::experimental::optional will have a value_or() function with similar signature (ie with a default_value).  Maybe that's what it should be called?

Tony

[Billy O'Neal]

What do you want to happen when T is noncopyable?

You can always write your own function that has the semantics you want; e.g. value_or_default(Container, Index).

Billy O'Neal

https://github.com/BillyONeal/

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

--
 
---
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.
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/.

[matve...@gmail.com]

Name is not really important for me. I just thought that the one used in Qt is good because it's short and Qt programmers are already familiar with it. But the consistency across the standard library is of course more important. So if all the functions like these will be called “value_or” — let it be.

вторник, 28 января 2014 г., 2:32:31 UTC+4 пользователь Tony V E написал:

[Matthew Woehlke]

On 2014-01-27 17:45, Billy O'Neal wrote:
> What do you want to happen when T is noncopyable?

Ideally there would exist some form of specialization such that the
method would not exist in that case.

> You can always write your own function that has the semantics you want;
> e.g. value_or_default(Container, Index).

I could write my own implementation of (almost?) anything in STL... that
doesn't mean STL shouldn't include things that are widely useful. IMHO
this qualifies; I've also wished for such a method.

--
Matthew

[matve...@gmail.com]

That's exactly what I wanted to say.

вторник, 28 января 2014 г., 3:12:04 UTC+4 пользователь Matthew Woehlke написал:

On 2014-01-27 17:45, Billy O'Neal wrote:
> What do you want to happen when T is noncopyable?

Ideally there would exist some form of specialization such that the
method would not exist in that case.

I don't see how this can be extended to noncopyable types either, because “value” (or “value_or”) is supposed to return a copy of T in case the container has the requested key. So if T is noncopyable the program should refuse to compile.
 

> You can always write your own function that has the semantics you want;
> e.g. value_or_default(Container, Index).

I could write my own implementation of (almost?) anything in STL... that
doesn't mean STL shouldn't include things that are widely useful. IMHO
this qualifies; I've also wished for such a method.

Exactly. In my view the code looks better when such basic functions are implemented as class members. For comparison: was there any reason why the “at” function added in C++11 can not be implemented externally? I don't think “at” is really much more useful.
 

--
Matthew

[Andrey Matveyakin]

Sorry, I didn't want to answer from 2 emails. That happened accidentally.

[Evgeny Panasyuk]

28 January 2014 г., 3:18:25 UTC+4 matve...@gmail.com:

> You can always write your own function that has the semantics you want;
> e.g. value_or_default(Container, Index).

I could write my own implementation of (almost?) anything in STL... that
doesn't mean STL shouldn't include things that are widely useful. IMHO
this qualifies; I've also wished for such a method.

Exactly. In my view the code looks better when such basic functions are implemented as class members. For comparison: was there any reason why the “at” function added in C++11 can not be implemented externally? I don't think “at” is really much more useful.

Non-member functions are more preferable than methods when possible.
For example, Alexander Stepanov, author of STL, at his Notes on Programming says ( http://www.stepanovpapers.com/notes.pdf ):
"While we could make a member function to return length, it is better to make it a global friend function. If we do that, we will be able eventually to define the same function to work on built-in arrays and achieve greater uniformity of design. I made size into a member function in STL in an attempt to please the standard committee. I knew that begin, end and size should be global functions but was not willing to risk another fight with the committee. In general, there were many compromises of which I am ashamed. It would have been harder to succeed without making them, but I still get a metallic taste in my mouth when I encounter all the things that I did wrong while knowing full how to do them right. Success, after all, is much overrated. I will be pointing to the incorrect designs in STL here and there: some were done because of political considerations, but many were mistakes caused by my inability to discern general principles.)"

Also refer SO: http://stackoverflow.com/questions/1638394/when-should-functions-be-member-functions

[Andrey Matveyakin]

 
So many people so many views on which way is more preferable. I want to apologies that I'm not ready to support “member vs non-member” dispute with steadfast arguments about real (non-visual) benefits of member-function. May be, there aren't any. But I want to point out is that the committee insisted on member functions in the very beginning and continues to add member functions now (e.g. the above-mentioned std::map::at), so there must be some reason.

Besides it is always possible to have 2 versions: both member and non-member, as with “begin” and “end”.

And even if we come to a conclusion that a non-member function is the best solution, I still want to see it in the standard library. It is handy, widespread and not completely trivial: at least 2 versions are required:
* based on “find” for std::map and
* based on checking range by hand for std::vector.