Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Concept of "cbegin"able?

26 views
Skip to first unread message

Alf P. Steinbach

unread,
Jun 30, 2018, 11:18:27 AM6/30/18
to
On 30.06.2018 15:35, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> a pair (AFAIK), a stream, or a fundamental object.
>
> PS: I'm not so sure about the stream part now.
> »cbegin« possibly might accept a stream.
> But maybe »cbegin« will not accept an
> »::std::atomic<int>«, for another example.
>

"const-iterable" maybe. At least it's a descriptive term that fits the bill.


Cheers!,

- Alf

James Kuyper

unread,
Jul 5, 2018, 8:08:47 PM7/5/18
to
On 06/30/2018 09:30 AM, Stefan Ram wrote:
> Do C++ programmers have a word for a value that will yield an
> iterator when being the argument value in a call to cbegin?
>
> For, example,
>
> cbegin( 2 )
>
> does not make sense, because »2« is not an ... .
>
> What must an object be so that it can be meaningfully be
> the argument of cbegin? Is there a single word for it?
>
> For example, cbegin would meaningfully accept an array,
> a vector, an initialization list, or a string, but not
> a pair (AFAIK), a stream, or a fundamental object.

24.7 p6 describes the only cbegin() in the standard that can take an
argument and isn't a member function. It returns std::begin(c), and as a
result of using a template with auto and decltype, doesn't care much
about what type c or std::begin(c) has. 24.7p1 describes std::begin(c)
as returning c.begin(). Again, as a result of templating, auto, and
decltype, it doesn't care much what type c or c.begin() has. Therefore,
I conclude that the only requirement for cbegin(c) is that c must have a
class type with a member function named begin() that can be invoked with
no arguments.

Am I missing something? If not, is there any point in naming such a concept?


0 new messages