Re: 1. Design an algorithm to print integers divisible by 3, from 1 to N. N should be input by the user.

[Alf P. Steinbach]

On 27.03.2016 06:06, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> An algorithm takes two iterators as its first two arguments,
>> so I have to encode N into two iterators in main, and then
>> call my custom algorithm with these two iterators.
>> { int N; ::std::cin >> N; ::std::vector< int >v( N );
>> algorithm( v.begin(), v.end() ); }
>
> You might think that it wastes resources to create a vector
> of N ints just to encode the number N. This remembers me of
> a part of an interview with Alexander Stepanov from 1998
> where he said:
>
> »It would be much nicer if begin and end were global - it
> would allow us to define them for C arrays. It would be
> so much nicer if operator* was global with the default
> definitions:
>
> template <class T> T& operator*(T& x) { return x;}
>
> template <class T> const T& operator*(const T& x) { return x;}
>
> It would allow us to write:
>
> copy(0, 25, ostream_iterator<int>("\n"));«.
>
> In the meantime, the global »begin« and »end« became a
> reality, even »cbegin« and »cend«. And today, they are
> recommended instead of the element functions. Maybe one
> day we will even get the global dereference operators that
> dereferences non-iterators to themselves!

Oh thanks. I've always attributed this idea to Dietmar Kuehl. Well, at
least the idea of the triad of functions begin(), end() and (c++17)
size(), ever since I failed to attribute it at all in a blog posting
long ago, and tried to make up for it.

Hrmf.

So, it was Stepanov, I should have guessed. :)


Cheers!,

- Alf

PS: Now that C++ is in the process of gaining a global size() function,
I have changed my view of it. I now think a size() function is *wrong*,
because it conflates two or three logical functions. Namely,
static_size() for arrays, n_items() for a dynamic size collection, and
length() for a string, say. In particular n_items() does not naturally
map to the size() member function of std::bitset, but rather to its
dynamic count(), which corresponds to the dynamic .size() of a std::set.

[Alf P. Steinbach]

On 27.03.2016 07:34, Stefan Ram wrote:
>
[snip]

>> PS: Now that C++ is in the process of gaining a global size() function,
>> I have changed my view of it. I now think a size() function is *wrong*,
>> because it conflates two or three logical functions. Namely,
>> static_size() for arrays, n_items() for a dynamic size collection, and
>> length() for a string, say. In particular n_items() does not naturally
>> map to the size() member function of std::bitset, but rather to its
>> dynamic count(), which corresponds to the dynamic .size() of a std::set.
>

> »Logical function« goes in this direction, I think:
>
> If there should be a global, general »size« it must have a
> single (not using distinct cases) English-language
> specification that allows one to deduce its meaning for any
> special case so that it can be used meaningfully and
> consistent in generic algorithms in as many cases as
> possible where this makes sense.

Yes. Here's my (static, constexpr) static_size:

template< class Type, size_t n >
constexpr
auto static_size( In_ref_<Raw_array_of_<n, Type>> )
-> Size
{ return n; }

template< class Type, size_t n >
constexpr
auto static_size( In_ref_<Array_of_<n, Type>> )
-> Size
{ return n; }

template< size_t n >
constexpr
auto static_size( In_ref_<std::bitset<n>> )
-> Size
{ return n; }

And here's the (dynamic) n_items:

template< class Type >
auto n_items( In_ref_<Type> o )
-> Size
{ return o.size(); }

template< size_t n >
auto n_items( In_ref_<std::bitset<n>> o )
-> Size
{ return o.count(); } // Corresponds to std::set<int>::size()

template< class Type, size_t n >
constexpr
auto n_items( In_ref_<Raw_array_of_<n, Type>> a )
-> Size
{ return static_size( a ); }

The latter is in the process of being [1]overhauled, in order to support
overloads for base classes called with derived class arguments.

In addition there's length_of_literal, length and is_empty.

Shameless plug: this is all part of the still-in-flux [2]cppx library.


Cheers!,

- Alf

Notes:
[1] <url:
http://stackoverflow.com/questions/36232418/make-fooderived-object-x-call-foobase-const-x-instead-of-template-fun/36232419#36233442>
[2] <url: http://alf-p-steinbach.github.io/cppx/>