How all the cool kids are getting array lengths from C++11 onwards

[Frederick Gotham]

Is everybody now doing the following since C++11?


#include <type_traits>
#include <iostream>

int values[76];

auto main(void) -> int
{
//Old way
std::cout << sizeof(values)/sizeof(*values) << std::endl;

//New way
std::cout << std::extent<decltype(values)>::value << std::endl;
}


Or is there an even nicer way?

[Ian Collins]

On 22/10/2019 20:28, Frederick Gotham wrote:
>
>
> Is everybody now doing the following since C++11?
>
>
> #include <type_traits>
> #include <iostream>
>
> int values[76];
>
> auto main(void) -> int

That is just so wrong..

> {
> //Old way
> std::cout << sizeof(values)/sizeof(*values) << std::endl;
>
> //New way
> std::cout << std::extent<decltype(values)>::value << std::endl;
> }
>
>
> Or is there an even nicer way?

Use std::array.

--
Ian.

[Frederick Gotham]

On Tuesday, October 22, 2019 at 8:36:49 AM UTC+1, Ian Collins wrote:

> > auto main(void) -> int
>
> That is just so wrong..

I already explained that I do this so that I know I'm not dealing with a C++03 compiler.

[Ian Collins]

There are much better ways that don't involve C idioms..

--
Ian.

[Bonita Montero]

Use this:

template<typename T, int_t N>
std::size_t array_size( T (&at)[N] )
{
return N;
}

[Öö Tiib]

#include <array> // for array and also size since C++17
#include <iostream> // for cout

int main()
{
int legacy[76];
std::array<int,76> values;

// Since C++11
// there is ugly std::extent for legacy
std::cout << values.size() << std::endl;

// Since C++17 there is uniform way
std::cout << std::size(legacy) << std::endl;
std::cout << std::size(values) << std::endl;
}

[Öö Tiib]

That void there is redundant on any case and usenet posts do not document
in code that at least C++11 is expected.

[Frederick Gotham]

On Tuesday, October 22, 2019 at 10:18:56 AM UTC+1, Öö Tiib wrote:

> > > > auto main(void) -> int

> That void there is redundant on any case and usenet posts do not document
> in code that at least C++11 is expected.

I put "extern" before function declarations, and I use 'void' instead of empty parentheses in function declarations and definitions so that it doesn't look like a function call.

[Ian Collins]

That makes no sense a all...

--
Ian.

[Öö Tiib]

Huh. How can either "auto main() -> int" or "int main()" possibly look
like function call?

[Frederick Gotham]

I will admit that I put the 'void' in there to make it ever so slightly more grotesque in nature to the people who find it grotesque in the first place.

I find this situation quite similar to rollerblades and quad skates. Personally I don't want to go on quad skates but I don't mind people being on quad skates around me. Myself though I bought a pair of Kaze 110mm three-wheelers last month.

I could make similar comparisons.

[Bonita Montero]

> There are much better ways that don't involve C idioms..

The advantages of std::array over a C-stype array are insignificant.

[melzzzzz]

Bonita Montero <Bonita....@gmail.com> Wrote in message:r
> > There are much better ways that don't involve C idioms..The advantages of std::array over a C-stype array are insignificant.

Except you can't pass c array as array, for that, you need
struct... therefore array struct...
--
Press any key to continue or any other to quit....

[Bonita Montero]

> Except you can't pass c array as array, for that, you need
> struct... therefore array struct...

I think no one has missed that feature so far.
And it's very inefficient.

[Scott Lurndal]

Frederick Gotham <cauldwel...@gmail.com> writes:
>
>
>Is everybody now doing the following since C++11?

No, the old way will continue to work forever and is
much more readable.

[Chris Vine]

std::array prevents pointer decay, which is pretty significant I think
as it enables the array size to remain part of the type.

As a simple class wrapper around a C array object, beginners may not
realise that assigning to a std::array object copies all the array
elements - that is a necessary consequence of eliminating pointer decay.
When you don't want element copying, you pass the std::array object by
(possibly const) reference, which seems fine to me.

[Bonita Montero]

> As a simple class wrapper around a C array object, beginners may not
> realise that assigning to a std::array object copies all the array
> elements - that is a necessary consequence of eliminating pointer decay.

Cases where you pass an array by value to a function should be extremely
rare and it is inefficient as well.

> When you don't want element copying, you pass the std::array object by
> (possibly const) reference, which seems fine to me.

When you pass it by reference you are fixed to a certain size for the
array you pass to the function. That's usually not what you want.

[Melzzzzz]

On 2019-10-22, Bonita Montero <Bonita....@gmail.com> wrote:
>> As a simple class wrapper around a C array object, beginners may not
>> realise that assigning to a std::array object copies all the array
>> elements - that is a necessary consequence of eliminating pointer decay.
>
> Cases where you pass an array by value to a function should be extremely
> rare and it is inefficient as well.

You pass it by reference or pointer and you don't need to clutter
functions...



--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Juha Nieminen]

What's wrong with using std::size()?

[Juha Nieminen]

Frederick Gotham <cauldwel...@gmail.com> wrote:
> #include <type_traits>
> #include <iostream>
>
> int values[76];
>
> auto main(void) -> int
> {
> //Old way
> std::cout << sizeof(values)/sizeof(*values) << std::endl;
>
> //New way
> std::cout << std::extent<decltype(values)>::value << std::endl;
> }
>
> Or is there an even nicer way?

Just use std::size();

[Bonita Montero]

>> Cases where you pass an array by value to a function should
>> be extremely rare and it is inefficient as well.

> You pass it by reference or pointer and you don't need to clutter
> functions...

The above was a response to the statement that you can pass
std::arrays by value. So what you say doesn't make sense here.
But when you pass it by reference or pointer you're fixed to
a certain size of the array; that's usually inappropriate.

[Melzzzzz]

On 2019-10-22, Bonita Montero <Bonita....@gmail.com> wrote:

That's whole point. If you want variable size use vector...

[Juha Nieminen]

Bonita Montero <Bonita....@gmail.com> wrote:
>> When you don't want element copying, you pass the std::array object by
>> (possibly const) reference, which seems fine to me.
>
> When you pass it by reference you are fixed to a certain size for the
> array you pass to the function. That's usually not what you want.

Note that if the array contains, for example, integers or floating point
values, and the function in question performs some arithmetic on those
values, the array having a fixed known size helps the compiler quite a
lot in optimization (more precizely SIMD vectorization).

With a size not known at compile time the compiler will also usually
perform vectorization optimization, but the result becomes more
complicated because it needs to take into account all possible
sizes that are not nice multiples of SSE/AVX register sizes.

[Bonita Montero]

> Note that if the array contains, for example, integers or floating point
> values, and the function in question performs some arithmetic on those
> values, the array having a fixed known size helps the compiler quite a
> lot in optimization (more precizely SIMD vectorization).

LOL, when you believe in auto-vectorization you also believe in santa
claus. Auto-vectorization only works for some predefined code-patterns
the compiler knows. In most cases you would have to do the vectorization
yourself through SIMD-intrinsics.

[Bonita Montero]

>> The above was a response to the statement that you can pass
>> std::arrays by value. So what you say doesn't make sense here.
>> But when you pass it by reference or pointer you're fixed to
>> a certain size of the array; that's usually inappropriate.

> That's whole point. If you want variable size use vector...

No, we were talking about the case where we want a fixed size array
which is passed to a function by reference. In this case passing the
pointer to a C-style array or a std::array is most appropriate.

[Chris Vine]

On Tue, 22 Oct 2019 15:55:32 +0200
Bonita Montero <Bonita....@gmail.com> wrote:
> > As a simple class wrapper around a C array object, beginners may not
> > realise that assigning to a std::array object copies all the array
> > elements - that is a necessary consequence of eliminating pointer decay.
>
> Cases where you pass an array by value to a function should be extremely
> rare and it is inefficient as well.

I agree and I wasn't saying anything different. If you hadn't snipped
my text to change its meaning, you would see that I mentioned this
as a possible downside of avoiding pointer decay. When you do want
pointer decay and so you want to use a C array, that's fine.

> > When you don't want element copying, you pass the std::array object by
> > (possibly const) reference, which seems fine to me.
>
> When you pass it by reference you are fixed to a certain size for the
> array you pass to the function. That's usually not what you want.

Your "usually" is different to my "usually". Pointer decay of C arrays
is "usually" a pain. Accordingly to my "usually", you usually do want
to retain the size as part of the type, which may mean passing the
std::array object by reference. But as I have said, if you want pointer
decay then employ pointer decay of a C array; or equivalently take the
address of std::array::front() (both are equally unsafe).

[Bonita Montero]

> Your "usually" is different to my "usually". Pointer decay of C arrays
> is "usually" a pain. Accordingly to my "usually", you usually do want
> to retain the size as part of the type, which may mean passing the
> std::array object by reference.

Then pass a pointer and a size_t.
Passing a std::array with a fixed size doesn't fit in most cases.

[Melzzzzz]

On 2019-10-22, Bonita Montero <Bonita....@gmail.com> wrote:

So you play games?
Fuck off.

[Keith Thompson]

Frederick Gotham <cauldwel...@gmail.com> writes:
> On Tuesday, October 22, 2019 at 10:35:33 AM UTC+1, Öö Tiib wrote:

[...]

>> Huh. How can either "auto main() -> int" or "int main()" possibly look
>> like function call?
>
> I will admit that I put the 'void' in there to make it ever so
> slightly more grotesque in nature to the people who find it grotesque
> in the first place.

That's called trolling. Please don't do that.

> I find this situation quite similar to rollerblades and quad
> skates. Personally I don't want to go on quad skates but I don't mind
> people being on quad skates around me. Myself though I bought a pair
> of Kaze 110mm three-wheelers last month.
>
> I could make similar comparisons.

So you use "auto" and "-> int" to make it deliberately incompatible
with pre-2011 C, and you use "(void)" whose only purpose is to make it
compatible with C.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Bonita Montero]

>>>> The above was a response to the statement that you can pass
>>>> std::arrays by value. So what you say doesn't make sense here.
>>>> But when you pass it by reference or pointer you're fixed to
>>>> a certain size of the array; that's usually inappropriate.

>>> That's whole point. If you want variable size use vector...

>> No, we were talking about the case where we want a fixed size array
>> which is passed to a function by reference. In this case passing the
>> pointer to a C-style array or a std::array is most appropriate.

> So you play games?
> Fuck off.

You mostly don't have a sens for the things we're talking about
but often confuse associations.

[Chris Vine]

Or for the few cases where passing a fixed size doesn't work, you can
make the receiver function a template function. (In fact, you showed
how to do it up-thread.)

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<K8DrF.201357$GS....@fx37.iad> thusly:

Get off my lawn!
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Jorgen Grahn]

On Tue, 2019-10-22, Frederick Gotham wrote:

> On Tuesday, October 22, 2019 at 8:36:49 AM UTC+1, Ian Collins wrote:
>
>> > auto main(void) -> int
>>

>> That is just so wrong..
>
> I already explained that I do this so that I know I'm not dealing
> with a C++03 compiler.

I recommend not doing it in examples posted to comp.lang.c++, unless
you want endless side discussions about it.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

+1.

Although /if/ I use a C array today, I think I'm more likely to use
std::begin and std::end on it, or do something else which doesn't
involve calculating its size.

[Bonita Montero]

>> Then pass a pointer and a size_t.
>> Passing a std::array with a fixed size doesn't fit in most cases.

> Or for the few cases where passing a fixed size doesn't work, you can
> make the receiver function a template function. (In fact, you showed
> how to do it up-thread.)

Do you really think someone would accept instantiating a function for
each array-length and still don't having variable lengths at runtime?

[Öö Tiib]

You move goal-posts in each post.
If you need fixed length array then use (reference of) std:;array.
If you need variable length array then use (reference of) std::vector.
If you need sub-range of elements of array then use two iterators.
Raw array does not solve difference between those needs in any way.

[Frederick Gotham]

On Tuesday, October 22, 2019 at 4:10:35 PM UTC+1, Keith Thompson wrote:

> >> Huh. How can either "auto main() -> int" or "int main()" possibly look
> >> like function call?
> >
> > I will admit that I put the 'void' in there to make it ever so
> > slightly more grotesque in nature to the people who find it grotesque
> > in the first place.
>
> That's called trolling. Please don't do that.

No it's not. It would be trolling if I was doing something wrong and then trying to make the wrong thing look more grotesque.

The irony here is that I think you are the biggest troll here. 'Troll' being a less severe word than I intend. What you do is very intricate and falls below some people's radars. Of course we have posts from time to time here like the guy who said the F word in the past few hours, but that's far less harmful than what you've been doing for a few years (including your personal email follow-up's).

With that said, I don't think you realise what you're doing.

> > I find this situation quite similar to rollerblades and quad
> > skates. Personally I don't want to go on quad skates but I don't mind
> > people being on quad skates around me. Myself though I bought a pair
> > of Kaze 110mm three-wheelers last month.
> >
> > I could make similar comparisons.
>
> So you use "auto" and "-> int" to make it deliberately incompatible
> with pre-2011 C, and you use "(void)" whose only purpose is to make it
> compatible with C.

Yes to the first one. With regard to the second one, I always use "(void)" instead of "()" in function declarations/definitions; I just like the feel of it. Plus, if that 'void' was mandatory then we never would have had the problem of object definitions resembling function declarations.

[David Brown]

I think the idea of deliberately using the "auto -> int" syntax as a way
of being incompatible with pre-C++11 is absurd. Use that syntax if it
improves your code in some way. If you really want to force
incompatibility with C++03 despite not having any /useful/ post-C++03
syntax, there are better ways to limit the compatibility than to write
uglier code.

But regarding "void" to mark empty parameters, I think that is fine. In
my own projects, it is rare to be pure C++ - I almost invariably have
some C modules as well, and empty parameters in a function declaration
has a different meaning in C and C++. Using "void" gives the same
meaning in both languages, and is thus my preference.

There are plenty of times in C and C++ where some parts of the syntax or
code can be omitted without affecting the behaviour, and people have
different preferences or standards there. Some people like to write
"unsigned", others prefer "unsigned int", and so on. Use whatever makes
the code clearer, easier to read, more likely to be right, and less
likely to be wrong - based on the kind of code you are writing and the
people who will be working with it.

But pick /good/ reasons for doing it, especially if you are straying
from popular convention - "just to be incompatible" is /not/ a good reason.

[Frederick Gotham]

On Wednesday, October 23, 2019 at 9:04:23 AM UTC+1, David Brown wrote:

> If you really want to force
> incompatibility with C++03 despite not having any /useful/ post-C++03
> syntax, there are better ways to limit the compatibility than to write
> uglier code.
>
> But regarding "void" to mark empty parameters, I think that is fine.

If you are trying to induce emesis in me then you're going the right way about it.

[David Brown]

Are you deliberately trying to alienate people in this group who have
given you useful advice? Making posts like a small child who has found
a dictionary is one way to achieve that.

[Frederick Gotham]

On Wednesday, October 23, 2019 at 10:02:32 AM UTC+1, David Brown wrote:

> > If you are trying to induce emesis in me then you're going the right way about it.
> >
>
> Are you deliberately trying to alienate people in this group who have
> given you useful advice? Making posts like a small child who has found
> a dictionary is one way to achieve that.

Thanks for asking me to explain myself.

Back when I was 15 and in school, I had an English teacher who told us that a particular bird was ugly. I think he was referring to the raven or the crow, can't remember exactly which one. I do distinctly remember though that he followed up the statement with "and that's an objective view".

Like my old English teacher, I don't think that you are able to comprehend the fact that there are things that you don't like. Since my way of defining the 'main' function works just the same as your way, it seems we simply have a case here of a human being not liking when people do things other ways.

Hence my reference to vomit.

[David Brown]

On 23/10/2019 11:32, Frederick Gotham wrote:
> On Wednesday, October 23, 2019 at 10:02:32 AM UTC+1, David Brown wrote:
>
>>> If you are trying to induce emesis in me then you're going the right way about it.
>>>
>>
>> Are you deliberately trying to alienate people in this group who have
>> given you useful advice? Making posts like a small child who has found
>> a dictionary is one way to achieve that.
>
>
> Thanks for asking me to explain myself.

I didn't.

>
> Hence my reference to vomit.
>

Hence my reference to making posts like a small child.

End of thread, I think.

[Öö Tiib]

Success or failure in this world usually *depends on* if other people
like or dislike what you do. Being deliberately grotesque is not what
(software) engineering is about. However if you start to vomit because
someone disliked your choice to be deliberately grotesque ... then
whom you anticipate to like that reaction?

[Bonita Montero]

> You move goal-posts in each post.
> If you need fixed length array then use (reference of) std:;array.
> If you need variable length array then use (reference of) std::vector.
> If you need sub-range of elements of array then use two iterators.
> Raw array does not solve difference between those needs in any way.

A pointer and a size_t or a start and an end-pointer fits all cases.

[Frederick Gotham]

On Wednesday, October 23, 2019 at 11:39:10 AM UTC+1, Öö Tiib wrote:

> Success or failure in this world usually *depends on* if other people
> like or dislike what you do. Being deliberately grotesque is not what
> (software) engineering is about. However if you start to vomit because
> someone disliked your choice to be deliberately grotesque ... then
> whom you anticipate to like that reaction?

People who live and let live.

[Bo Persson]

That's because your "a start and an end-pointer" *is* the "use two
iterators" case. :-)


Bo Persson

[Bonita Montero]

> That's because your "a start and an end-pointer" *is* the "use two
> iterators" case.  :-)

Don't you understand? When you have a function that takes a start and
end pointer you can refer to a vector, array or std::array. But you
can't when you're fixed to std::vector<T>::iterator.

[Paavo Helde]

That's why in all STL algorithms the iterator type is a template parameter.

[Bo Persson]

Who said you should be "fixed to" some type?

template<class iterator>
void f(iterator start, iterator end);

will work for any pair of iterators, *including* your pointers.


Bo Persson

[Bonita Montero]

>> Don't you understand? When you have a function that takes a start and
>> end pointer you can refer to a vector, array or std::array. But you
>> can't when you're fixed to std::vector<T>::iterator.

> That's why in all STL algorithms the iterator type is a template parameter.

And this helps a function to accept all the three above types?

[Bonita Montero]

>> Don't you understand? When you have a function that takes a start and
>> end pointer you can refer to a vector, array or std::array. But you
>> can't when you're fixed to std::vector<T>::iterator.

> Who said you should be "fixed to" some type?
> template<class iterator>
> void f(iterator start, iterator end);
> will work for any pair of iterators, *including* your pointers.

Of course, but for the above three types this pure syntactic sugar.

[Paavo Helde]

They are function templates, not functions. Of course they do support
all those three types, and more. That's a major feature of STL.

int array[] = {1,3,2,4};
std::sort(std::begin(array), std::end(array));
// or:
std::sort(array, array+sizeof(array)/sizeof(array[0]));

etc...

[Bonita Montero]

> They are function templates, not functions. Of course they do support
> all those three types, and more. That's a major feature of STL.

For the discussed case that's all simply syntactic sugar.

[Christian Gollwitzer]

Am 23.10.19 um 15:48 schrieb Bonita Montero:

so?

[James Kuyper]

On 10/23/19 3:14 AM, Frederick Gotham wrote:
> On Tuesday, October 22, 2019 at 4:10:35 PM UTC+1, Keith Thompson wrote:

...

>>> I will admit that I put the 'void' in there to make it ever so
>>> slightly more grotesque in nature to the people who find it grotesque
>>> in the first place.
>>
>> That's called trolling. Please don't do that.
>
>
> No it's not. It would be trolling if I was doing something wrong and then trying to make the wrong thing look more grotesque.

The defining characteristic of trolling is saying something for the
purpose of provoking a reaction. Which is precisely the reason you gave
for doing this. It's derived from the word "troll" as it is used in
fishing, with the provocation corresponding to the bait, and the
reaction that you've provoked corresponding to a fish taking the bait.
It really doesn't matter whether the bait is "wrong" or "right" in any
absolute sense, only that people will react to it.

[Keith Thompson]

Frederick Gotham <cauldwel...@gmail.com> writes:
[...]

> The irony here is that I think you are the biggest troll here. 'Troll'
> being a less severe word than I intend. What you do is very intricate
> and falls below some people's radars. Of course we have posts from
> time to time here like the guy who said the F word in the past few
> hours, but that's far less harmful than what you've been doing for a
> few years (including your personal email follow-up's).
>
> With that said, I don't think you realise what you're doing.

I'll reply to this by email.

[...]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Juha Nieminen]

Bonita Montero <Bonita....@gmail.com> wrote:
>> Note that if the array contains, for example, integers or floating point
>> values, and the function in question performs some arithmetic on those
>> values, the array having a fixed known size helps the compiler quite a
>> lot in optimization (more precizely SIMD vectorization).
>
> LOL, when you believe in auto-vectorization you also believe in santa
> claus. Auto-vectorization only works for some predefined code-patterns
> the compiler knows. In most cases you would have to do the vectorization
> yourself through SIMD-intrinsics.

Have you even looked at what modern compilers like recent versions of
gcc and clang produce using automatic vectorization? Because I have.

It's not always perfect, but it's miles better than no vectorization
of any kind. Often they are able to do surprisingly complex automatic
vectorization of relatively complex structures.

Consider, for example, this kind of code:

//-------------------------------------------------------------------
#include <array>

struct Point4D
{
float x, y, z, w;
};

using Point4DVec = std::array<Point4D, 4>;

Point4DVec foo(const Point4DVec& v1, const Point4DVec& v2, float f)
{
Point4DVec result;
for(std::size_t i = 0; i < result.size(); ++i)
{
result[i].x = (v1[i].x - v2[i].x) * f;
result[i].y = (v1[i].y - v2[i].y) * f;
result[i].z = (v1[i].z - v2[i].z) * f;
result[i].w = (v1[i].w - v2[i].w) * f;
}
return result;
}
//-------------------------------------------------------------------

gcc compiles that to:

vbroadcastss ymm2, xmm0
vmovups ymm3, YMMWORD PTR [rsi]
vmovups ymm0, YMMWORD PTR [rsi+32]
vsubps ymm1, ymm3, YMMWORD PTR [rdx]
vsubps ymm0, ymm0, YMMWORD PTR [rdx+32]
mov rax, rdi
vmulps ymm1, ymm1, ymm2
vmulps ymm0, ymm0, ymm2
vmovups YMMWORD PTR [rdi], ymm1
vmovups YMMWORD PTR [rdi+32], ymm0
vzeroupper
ret

[Bonita Montero]

> Have you even looked at what modern compilers like recent versions of
> gcc and clang produce using automatic vectorization? Because I have.

Have you checked the compiler-docs? They document which code-patterns
they can detect and vectorize. That are only very special patterns.

[David Brown]

Can you give links to these documentation pages for gcc and clang?

[Bonita Montero]

> Can you give links to these documentation pages for gcc and clang?

No, but I'll bet they're not cleverer as Intel-C++:
https://software.intel.com/en-us/cpp-compiler-developer-guide-and-reference-automatic-vectorization-overview

[David Brown]

So when you wrote:

> Have you checked the compiler-docs? They document which code-patterns
> they can detect and vectorize. That are only very special patterns.

in response to a comment about gcc and clang auto-vectorisation, you
really didn't know what you were talking about?

Both clang and gcc have vectorised code like Juha's for many years - and
both produce a great deal better code for it than ICC in my brief test.
ICC does not vectorise the code at all.

(That may, of course, vary for different code samples - and it may be
dependent on compiler flags.) Give it a shot on <https://godbolt.org>
yourself.


And while it is certainly the case that compilers can only
auto-vectorise certain types of code, it is /not/ the case that it is so
limited that these tools list the code patterns in their documentation.
All they do is provide some tips and suggestions about how to increase
the likelihood of automatic vectorisation.


Why not try investigating what people write in posts, rather than
mocking them from a position of ignorance?

[Öö Tiib]

On Thursday, 24 October 2019 15:14:35 UTC+3, David Brown wrote:
>
> Why not try investigating what people write in posts, rather than
> mocking them from a position of ignorance?

As described by social psychologists David Dunning and Justin
Kruger, the cognitive bias of illusory superiority results from an
internal illusion in people of low ability and from an external
misperception in people of high ability; that is, "the miscalibration
of the incompetent stems from an error about the self, whereas
the miscalibration of the highly competent stems from an error
about others."
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[Bonita Montero]

> ICC does not vectorise the code at all.

Check the ICC documentation ...

[Bonita Montero]

https://gcc.gnu.org/projects/tree-ssa/vectorization.html

[Frederick Gotham]

On Wednesday, October 23, 2019 at 6:18:17 PM UTC+1, James Kuyper wrote:

> The defining characteristic of trolling is saying something for the
> purpose of provoking a reaction. Which is precisely the reason you gave
> for doing this. It's derived from the word "troll" as it is used in
> fishing, with the provocation corresponding to the bait, and the
> reaction that you've provoked corresponding to a fish taking the bait.
> It really doesn't matter whether the bait is "wrong" or "right" in any
> absolute sense, only that people will react to it.

When practising etymology, it's quite easy to come to wrong conclusions.

I think it's likely that the modern use of "troll" on internet forums actually comes from the doll: https://en.wikipedia.org/wiki/Troll_doll

This makes the most sense to me out of all the possibilities (including your angling one).

[Scott Lurndal]

I've been on usenet for almost forty years; It has always been well understood that the
term derives from the fishing usage.

[Real Troll]

On 22/10/2019 08:28, Frederick Gotham wrote:
>
> Is everybody now doing the following since C++11?
>
> #include <type_traits>
> #include <iostream>
>
> int values[76];
>
> auto main(void) -> int
> {
> //Old way
> std::cout << sizeof(values)/sizeof(*values) << std::endl;
>
> //New way
> std::cout << std::extent<decltype(values)>::value << std::endl;
> }
>
>
> Or is there an even nicer way?


values.size();

[James Kuyper]

>On Wednesday, October 23, 2019 at 6:18:17 PM UTC+1, James Kuyper wrote:
>
>> The defining characteristic of trolling is saying something for the
>> purpose of provoking a reaction. Which is precisely the reason you gave
>> for doing this. It's derived from the word "troll" as it is used in
>> fishing, with the provocation corresponding to the bait, and the
>> reaction that you've provoked corresponding to a fish taking the bait.
>> It really doesn't matter whether the bait is "wrong" or "right" in any
>> absolute sense, only that people will react to it.
>
>
> When practising etymology, it's quite easy to > come to wrong conclusions.
>
> I think it's likely that the modern use of "troll" on internet forums actually comes from > the doll: https://en.wikipedia.org/wiki/Troll_doll

That etymology is inconsistent with the way I've seen it used, and the online dictionaries I've checked agree with the fishing etymology, which is consistent with the way I've seen it used.

See <https://en.m.wiktionary.org/wiki/troll#Verb>, meaning #8.

[David Brown]

On 24/10/2019 16:23, Bonita Montero wrote:
> https://gcc.gnu.org/projects/tree-ssa/vectorization.html

That page is not part of the gcc compiler documentation, so it does not
fulfil your claims. It does not describe limits of the code patterns
that can be vectorised, contrary to your claims. It gives some examples
of code that /can/ be vectorised, as part of the development project for
adding auto-vectorisation to gcc, which was integrated in the compiler
some ten years ago (contrary to your claims that compilers can't
auto-vectorise except in some very limited ways).


It is quite clear that you don't know about auto-vectorisation in
compilers - how well it works, how to write code that works with it,
what compilers support it. You were simply trying to look smart by
mocking someone who /does/ know about it.

Clutching at straws and making up more nonsense, perhaps hoping no one
will bother checking your posts or links, will not help. The correct
response would be to admit that you were wrong, accept that you have
learned something, and apologise for your mocking.

[David Brown]

On 24/10/2019 16:16, Bonita Montero wrote:
>> ICC does not vectorise the code at all.
>
> Check the ICC documentation ...

I have read it. It does not describe a specific set of code patterns
that the compiler can vectorize, contrary to your claim. And I have
tried Juha's code with ICC, and the compiler does not vectorise it (at
least, not using the flags I tested. gcc and clang both vectorised the
code nicely with those same flags).

[David Brown]

It is conceivable that the internet usage of the term "troll" is related
to the mythical monster "troll", from Norse mythology (and later
inspiring monsters in fictional works like those of Tolkien). Certainly
net "trolls" are as unpleasant and disliked as "real" trolls, and it is
common to caricature net trolls as real trolls.

But the idea that it is related to "Troll dolls" is clearly ridiculous.

(My money is still on the fishing term - it fits the usage very
accurately, and is confirmed by people who have used Usenet pretty much
since its conception.)

Rather than argue further, I recommend you take a couple of hours break
from Usenet and watch this film. It is time well spent!

<https://en.wikipedia.org/wiki/Trollhunter>

[Ben Bacarisse]

For a lot of people in the UK, the reference that springs to mind will
be to Julian and Sandy "trolling about" in Round the Horn. That polari
word probably comes from the fishing usage, but that one will be far
less well known to many Brits of a certain age.

--
Ben.

[Alf P. Steinbach]

On 22.10.2019 11:11, Öö Tiib wrote:
>
> // Since C++17 there is uniform way
> std::cout << std::size(legacy) << std::endl;
> std::cout << std::size(values) << std::endl;

With C++20 we will get std::ssize(), which returns signed type. :)

template <class C>
constexpr ptrdiff_t ssize(const C& c);
// Returns: static_cast<ptrdiff_t>(c.size())

template <class T, ptrdiff_t N>
constexpr ptrdiff_t ssize(const T (&array)[N]) noexcept;
// Returns: N.

<url: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1227r1.html>

I had the impression that there would also be a signed `ssize_t` type,
perhaps just as an alias of `ptrdiff_t`, but alas: my googling now
indicates there will not be such a type, so just

using Size = ptrdiff_t;
using Index = Size;

- Alf

[Ian Collins]

On 25/10/2019 09:44, David Brown wrote:
>
>
> It is quite clear that you don't know about auto-vectorisation in
> compilers -

.. and you have been successfully tolled again :)

--
Ian.

[Bonita Montero]

> That page is not part of the gcc compiler documentation, ...

"Auto-vectorization in GCC" under gcc.gnu.org.

> It does not describe limits of the code patterns that can be vectorised, ...

"Vectorizable Loops"

[Jorgen Grahn]

On Thu, 2019-10-24, David Brown wrote:
...

> It is conceivable that the internet usage of the term "troll" is related
> to the mythical monster "troll", from Norse mythology (and later
> inspiring monsters in fictional works like those of Tolkien). Certainly
> net "trolls" are as unpleasant and disliked as "real" trolls, and it is
> common to caricature net trolls as real trolls.
>
> But the idea that it is related to "Troll dolls" is clearly ridiculous.
>
> (My money is still on the fishing term - it fits the usage very
> accurately, and is confirmed by people who have used Usenet pretty much
> since its conception.)

The fishing term, boosted by the mythological creatures. I bet a less
catchy (pun unintended) fishing term wouldn't have become so popular.

> Rather than argue further, I recommend you take a couple of hours break
> from Usenet and watch this film. It is time well spent!
>
> <https://en.wikipedia.org/wiki/Trollhunter>

Haven't seen it, but this one is nice, after a fashion:

https://en.wikipedia.org/wiki/Border_(2018_Swedish_film)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Keith Thompson]

Frederick Gotham <cauldwel...@gmail.com> writes:
> On Tuesday, October 22, 2019 at 4:10:35 PM UTC+1, Keith Thompson wrote:
>

>> >> Huh. How can either "auto main() -> int" or "int main()" possibly look
>> >> like function call?

>> >
>> > I will admit that I put the 'void' in there to make it ever so
>> > slightly more grotesque in nature to the people who find it grotesque
>> > in the first place.
>>
>> That's called trolling. Please don't do that.
>
> No it's not. It would be trolling if I was doing something wrong and
> then trying to make the wrong thing look more grotesque.
>

> The irony here is that I think you are the biggest troll here. 'Troll'
> being a less severe word than I intend. What you do is very intricate
> and falls below some people's radars. Of course we have posts from
> time to time here like the guy who said the F word in the past few
> hours, but that's far less harmful than what you've been doing for a
> few years (including your personal email follow-up's).
>
> With that said, I don't think you realise what you're doing.

Since you haven't responded to my email, I'm going to assume that
you're not interested in explaining further. Feel free to email
me if you want to discuss this. Meanwhile, I'll just ignore your
vague insults.

Everyone, please don't increase the signal-to-noise ratio by posting
further about this here. Anyone who insists on doing so will have
to change the followup headers.

[Real Troll]

On 25/10/2019 20:03, Keith Thompson wrote:
>
> Everyone, please don't increase the signal-to-noise ratio by posting
> further about this here. Anyone who insists on doing so will have
> to change the followup headers.

People wants to discuss the meaning of Troll so where else can they
discuss this?

Follow up to alt.idiots

[David Brown]

I missed that one when it was on at the cinemas, but I plan to see it
sometime.