c++ 20

[gdo...@gmail.com]

import <iostream>;

int main()
{
int answer {42};

std::cout << "The answer to life, the universe, and everything is "
<< answer
<< std::endl;

return 0;
}

wow, import and a semicolon

assignment in { }
man! i been gone for a long time.
love the import and semicolon,
not to sure about assignment using { }
int answer = 42; yeah i don't see the need to change that yet,
but i'm in the preface section of the book, lol. lol,lol. those things just shocked me. lol, lol, lol

[The Doctor]

In article <c3bedc33-c96f-4705...@googlegroups.com>,

Such are C based languages.
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Sellers of safety are often sellers of tyranny. -unknown Beware https://mindspring.com

[David Brown]

On 21/06/2022 23:48, gdo...@gmail.com wrote:
>
> import <iostream>;
>
> int main()
> {
> int answer {42};
>
> std::cout << "The answer to life, the universe, and everything is "
> << answer
> << std::endl;
>
> return 0;
> }
>
> wow, import and a semicolon
>
> assignment in { }

That is not assignment, it is initialisation. Though assignment and
initialisation often look the same for simple object types, there is a
huge difference for more complicated objects. It's worth learning the
difference.

The form you see here is "uniform initialisation", introduced in C++11.

<https://isocpp.org/wiki/faq/cpp11-language#uniform-init>

[Malcolm McLean]

Point2 p{42, 100};

Is handy, as is

movecursorto({x,y});

for consistency, {x} must intialise a scalar, but you're right that you probably shouldn't use it
in real code.

[David Brown]

Some people prefer to write

int answer { 42 };

rather than

int answer = 42;

There are two key advantages to the uniform initialisation style. One
is consistency - it is useful for more complicated initialisations, and
some people prefer the consistency of using it for all initialisations.
The other is that it disallows narrowing conversions. This means you
will get an error for :

int answer { 42.1 };

uint8_t x { 300 };

float y { 120.4 };

Each of these would be accepted with "old-style" assignment initialisation.

Whether you think these advantages are important, or whether you think
the braces initialisation is uglier, is a subjective matter. The OP is
clearly learning (or re-learning, or updating) the language. He/she
needs to understand all the forms of initialisation, but the choice of
which to use can depend on many factors - such as the preferences in the
learning material in use.

[Bonita Montero]

Am 21.06.2022 um 23:48 schrieb gdo...@gmail.com:
>
> import <iostream>;
>
> int main()
> {
> int answer {42};
>
> std::cout << "The answer to life, the universe, and everything is "
> << answer
> << std::endl;
>
> return 0;
> }
>
> wow, import and a semicolon

That's while import doesn't work on the preprocessor level.

[Mut...@dastardlyhq.com]

On Wed, 22 Jun 2022 10:18:47 +0200
David Brown <david...@hesbynett.no> wrote:
>Some people prefer to write
>
> int answer { 42 };
>
>rather than
>
> int answer = 42;

Which simply proves that some people are wierd. { } is fine for assignment list
demarcation (though IMO [] would have made more sense) but is silly for a
simple assignment.

[David Brown]

It is not an assignment - initialisation is not the same thing.

(Personally, I prefer copy-initialisation, such as "int answer = 42;",
for simple types. But there's no denying that there are advantages to
uniform initialisation for those that don't mind the syntax.)

[Bo Persson]

The point is exactly that it isn't an assignment. It is an initialization.

[Mut...@dastardlyhq.com]

Hair splitting.

vector<int> v{1,2,3}

is assigning values to the vector.

[Bo Persson]

Possibly :-)

>
> vector<int> v{1,2,3}
>
> is assigning values to the vector.
>

No, it creates a new vector with these values. That's initialization,
like in setting its initial value.

Assignment is when there already is an objects, and it gets a new value.


answer = 43;

is an assignment.

[David Brown]

No, that is initialisation.

This is a C++ group. In the C++ language, there are important
differences between initialisation and assignment, and if you want to
understand the language you should make a point of learning about these
differences.

If you prefer to use a limited approximation to the language, and use
incorrect terms, that's your choice - it will be good enough for simple
coding. But it would be nice if you didn't try to confuse learners by
using inaccurate terms.

[Scott Lurndal]

Bo Persson <b...@bo-persson.se> writes:
>On 2022-06-22 at 18:07, Mut...@dastardlyhq.com wrote:
>> On Wed, 22 Jun 2022 12:33:14 +0200
>> Bo Persson <b...@bo-persson.se> wrote:
>
>>>>
>>>
>>> The point is exactly that it isn't an assignment. It is an initialization.
>>
>> Hair splitting.
>
>Possibly :-)
>
>>
>> vector<int> v{1,2,3}
>>
>> is assigning values to the vector.
>>
>
>No, it creates a new vector with these values. That's initialization,
>like in setting its initial value.

You are both correct, that particular syntax is assigning initial values to the vector.

Whether the language has canonical language for each is not particularly relevent, but
the idea that there are now two ways to accomplish the same goal is typical of the
perhaps flawed direction C++ has taken.

[Ben Bacarisse]

If it's hair splitting, it's a pretty wide hair. At file scope the
initialisation

int a = 1;

is allowed, but an assignment is not even valid syntax. And the
initialisation

int &b = a;

is entirely different to the assignment

b = a;

One binds a reference and the other assigns to the referenced object.
Then there are initialisations like

char s[] = "hello";

for which there is just no equivalent assignment. And of course for
class instances with a constructor, the difference can be like chalk and
cheese.

It's really handy to know the difference.

--
Ben.

[Chris M. Thomasson]

[...]

Hey now:

component x = {-1, 1, 0, -4};

Fine with me. ;^)

[Mut...@dastardlyhq.com]

On Wed, 22 Jun 2022 19:05:54 +0200

Bo Persson <b...@bo-persson.se> wrote:
>On 2022-06-22 at 18:07, Mut...@dastardlyhq.com wrote:
>> On Wed, 22 Jun 2022 12:33:14 +0200
>> Bo Persson <b...@bo-persson.se> wrote:
>>> On 2022-06-22 at 10:40, Mut...@dastardlyhq.com wrote:
>>>> On Wed, 22 Jun 2022 10:18:47 +0200
>>>> David Brown <david...@hesbynett.no> wrote:
>>>>> Some people prefer to write
>>>>>
>>>>> int answer { 42 };
>>>>>
>>>>> rather than
>>>>>
>>>>> int answer = 42;
>>>>
>>>> Which simply proves that some people are wierd. { } is fine for assignment
>>> list
>>>> demarcation (though IMO [] would have made more sense) but is silly for a
>>>> simple assignment.
>>>>
>>>
>>> The point is exactly that it isn't an assignment. It is an initialization.
>>
>> Hair splitting.
>
>Possibly :-)
>
>>
>> vector<int> v{1,2,3}
>>
>> is assigning values to the vector.
>>
>
>No, it creates a new vector with these values. That's initialization,
>like in setting its initial value.
>
>Assignment is when there already is an objects, and it gets a new value.

Initialisation is the whole process, assignment is specifically setting the
values and the terminology doesn't depend on whether a value is already there.
Like I said, you're splitting hairs but call it whatever you want, I'm not
getting into another idiotic language argument with someone for whom english is
a 2nd language anyway.

[Mut...@dastardlyhq.com]

On Wed, 22 Jun 2022 19:16:02 +0200

David Brown <david...@hesbynett.no> wrote:
>On 22/06/2022 18:07, Mut...@dastardlyhq.com wrote:
>> On Wed, 22 Jun 2022 12:33:14 +0200
>> Bo Persson <b...@bo-persson.se> wrote:
>>> On 2022-06-22 at 10:40, Mut...@dastardlyhq.com wrote:
>>>> On Wed, 22 Jun 2022 10:18:47 +0200
>>>> David Brown <david...@hesbynett.no> wrote:
>>>>> Some people prefer to write
>>>>>
>>>>> int answer { 42 };
>>>>>
>>>>> rather than
>>>>>
>>>>> int answer = 42;
>>>>
>>>> Which simply proves that some people are wierd. { } is fine for assignment
>>> list
>>>> demarcation (though IMO [] would have made more sense) but is silly for a
>>>> simple assignment.
>>>>
>>>
>>> The point is exactly that it isn't an assignment. It is an initialization.
>>
>> Hair splitting.
>>
>> vector<int> v{1,2,3}
>>
>> is assigning values to the vector.
>>
>
>No, that is initialisation.
>
>This is a C++ group. In the C++ language, there are important
>differences between initialisation and assignment, and if you want to
>understand the language you should make a point of learning about these
>differences.

Ah, we're in to patronising territory already which is usually an indication
that the poster is backing into a corner.

>If you prefer to use a limited approximation to the language, and use
>incorrect terms, that's your choice - it will be good enough for simple
>coding. But it would be nice if you didn't try to confuse learners by
>using inaccurate terms.

I'm using the standard english terms, I'm not interested in how its described
in some dusty corner of the spec. And FWIW I doubt there are any learners on
here. How you describe something has zero effect on code unless you believe
in psychokinesis. Perhaps you do.

Just in case you're still confused:

https://www.oxfordlearnersdictionaries.com/definition/english/assign

"to say that something has a particular value or function, or happens at a
particular time or place"

Eg at vector initialisation time.

HTH.

[Christian Gollwitzer]

Am 23.06.22 um 08:16 schrieb Mut...@dastardlyhq.com:

>
> I'm using the standard english terms, I'm not interested in how its described
> in some dusty corner of the spec.

But you are talking to people who use them in their standard defined
meaning. You missed that words have multiple meanings, and especially in
science and technology these meanings sometime differ from the general
usage.

E.g. a "theory" in colloquial English is a vague idea for an
explanation, what scientists call a "hypothesis", while a "theory" in
science is a model backed up by and generalising all available evidence.

Likewise, "assignment" and "initialisation" are technical terms for C++
programmers, and when you call them "wurzlbrmpft" and "kohlrabi" you
would just induce confusion among the people who use them in their
defined meaning, and even more when you mix them up.


Christian

[David Brown]

Bo is correct. Words like "initialisation" and "assignment" have
specific meanings in the language, and it is useful to get in the habit
of using them accurately. You are right that assignment can happen
without a value being in the object ("int x; x = 1;"). But the object
has to exist and have completed its initialisation, if any, before an
assignment can happen.

> Like I said, you're splitting hairs but call it whatever you want,

It is what the standards call it, not necessarily what any C++ user
wants. (Most C++ users would want the whole thing simplified a bit.)

> I'm not
> getting into another idiotic language argument with someone for whom english is
> a 2nd language anyway.
>

Bo's English is at least as good as yours.

[David Brown]

This is not a "dusty corner" of the language specification - it's an
important concept in C++. The distinction between initialisation and
assignment is not an easy matter, and you can reasonably argue that it
is more complicated that it really should be. But you have to learn it,
and you should try to use the terms accurately. It makes no practical
difference for simple object types, such as "int" here, but it /does/
make a difference with more complicated code.

> And FWIW I doubt there are any learners on
> here. How you describe something has zero effect on code unless you believe
> in psychokinesis. Perhaps you do.
>
> Just in case you're still confused:
>
> https://www.oxfordlearnersdictionaries.com/definition/english/assign
>
> "to say that something has a particular value or function, or happens at a
> particular time or place"
>
> Eg at vector initialisation time.
>

Why would you think a dictionary entry is of relevance to technical
terms with specific meanings in a programming language standard?

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
>>No, that is initialisation.
>>
>>This is a C++ group. In the C++ language, there are important
>>differences between initialisation and assignment, and if you want to
>>understand the language you should make a point of learning about these
>>differences.
>
> Ah, we're in to patronising territory already which is usually an indication
> that the poster is backing into a corner.

There's nothing patronizing about that response. It's simply stating an
important fact about C++.

>>If you prefer to use a limited approximation to the language, and use
>>incorrect terms, that's your choice - it will be good enough for simple
>>coding. But it would be nice if you didn't try to confuse learners by
>>using inaccurate terms.
>
> I'm using the standard english terms, I'm not interested in how its described
> in some dusty corner of the spec.

You should not be using "standard english terms" when it comes to such things
in C++ because if you do so you'll be causing confusion and even
misunderstandings. "Initialization" and "assignment" have very specific
meanings in C++ and can't be used interchangeably.

One quite prominent way of seeing the difference is that for custom
types assignment can be disabled (you'll get a compiler error if you try)
while initialization is enabled. (The other way around is possible too.)

There are, in fact, some utility classes in the standard library where
that's exactly the case, most prominently std::unique_ptr. You can
initialize it but you can't (copy) assign one. (You can move assign, but
that's a bit different.)

[Juha Nieminen]

And, in fact, they are two rather different types of initialization: The first
one is calling a constructor taking an int, while the second one is calling
a copy constructor (although the compiler is optimize that construction-the-
temporary-and-calling-the-copy-constructor away and just call the regular
constructor with the given value).

I have seen some people even use this idiom, with no understanding of that
difference:

auto vec = std::vector { 1, 2, 3, 4 };

While normally the compiler is allowed to optimize the temporary and the
copy constructor call away, I'm actually not sure it can do that in this
case. I find this idiom abhorrent.

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 09:12:45 +0100
Christian Gollwitzer <auri...@gmx.de> wrote:
>Am 23.06.22 um 08:16 schrieb Mut...@dastardlyhq.com:
>>
>> I'm using the standard english terms, I'm not interested in how its described
>
>> in some dusty corner of the spec.
>
>But you are talking to people who use them in their standard defined

Yes I know the autism level is high on here.

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 11:33:22 +0200
David Brown <david...@hesbynett.no> wrote:
>On 23/06/2022 09:11, Mut...@dastardlyhq.com wrote:
>> Initialisation is the whole process, assignment is specifically setting the
>> values and the terminology doesn't depend on whether a value is already
>there.
>
>Bo is correct. Words like "initialisation" and "assignment" have
>specific meanings in the language, and it is useful to get in the habit
>of using them accurately. You are right that assignment can happen
>without a value being in the object ("int x; x = 1;"). But the object
>has to exist and have completed its initialisation, if any, before an
>assignment can happen.

Exactly. Initialisation consists of allocating the memory. Then you ASSIGN
the values to that memory.

>> I'm not
>> getting into another idiotic language argument with someone for whom english
>is
>> a 2nd language anyway.
>>
>
>Bo's English is at least as good as yours.

Highly unlikely.

[Mut...@dastardlyhq.com]

Because spoken languages are defined in dictionaries, not in computer
progamming manuals. Memory gets assigned a value.

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 11:07:49 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>There are, in fact, some utility classes in the standard library where
>that's exactly the case, most prominently std::unique_ptr. You can
>initialize it but you can't (copy) assign one. (You can move assign, but
>that's a bit different.)

I don't see your point. You're still assigning a value to it, the fact that
you can only do it the once is neither here nor there.

[David Brown]

On 23/06/2022 15:20, Mut...@dastardlyhq.com wrote:
> On Thu, 23 Jun 2022 11:33:22 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 23/06/2022 09:11, Mut...@dastardlyhq.com wrote:
>>> Initialisation is the whole process, assignment is specifically setting the
>>> values and the terminology doesn't depend on whether a value is already
>> there.
>>
>> Bo is correct. Words like "initialisation" and "assignment" have
>> specific meanings in the language, and it is useful to get in the habit
>> of using them accurately. You are right that assignment can happen
>> without a value being in the object ("int x; x = 1;"). But the object
>> has to exist and have completed its initialisation, if any, before an
>> assignment can happen.
>
> Exactly. Initialisation consists of allocating the memory. Then you ASSIGN
> the values to that memory.

That is not correct usage of the technical terms (and it is the
technical terms that matter). Initialisation does not consist solely of
allocating memory, nor is allocation of memory necessary for many
initialisations.

>
>>> I'm not
>>> getting into another idiotic language argument with someone for whom english
>> is
>>> a 2nd language anyway.
>>>
>>
>> Bo's English is at least as good as yours.
>
> Highly unlikely.
>

I've noticed a fair number of grammatical errors in your writing, but
none in Bo's posts. Of course I have not examined all his posts. My
experience with well-educated Scandinavians (and I am confident I have
more experience with them than you) is that their written English is
frequently more accurate than native English speakers. They sometimes
have tell-tail habits in their spoken English, and they won't use the
same range of idioms.

Certainly any argument on the basis of Bo's mastery of English as a
second language is unjustified.

[Juha Nieminen]

Seriously, how hard it is to just say "ah, sorry, my bad, I stand corrected.
I learned something new today", instead of just going into this endless and
futile quest of trying to "win" and to "be right" in such a petty little
thing?

Admitting not having known something, or having made a small mistake, is not
a bad thing, nor is it shameful. You don't have to always "win". You don't
have to always "be right". You can perfectly well be mistaken, admit it,
learn from the mistake, and nobody will ridicule you.

The longer you continue this silly quest of yours of trying to defend your
mistake as not being a mistake, the deeper you will be digging that hole
where you wouldn't even have to be. In other words, and rather ironically,
you are shaming yourself by trying so desperately to be right, rather
than admitting that you didn't know (or were mistaken).

This is really not a hill to die on. Just say "I stand corrected" and
move on. Nobody will blame you for that.

(Now expecting your "I didn't read any of that" with an assortment of
insults response...)

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 16:10:27 +0200

David Brown <david...@hesbynett.no> wrote:
>On 23/06/2022 15:20, Mut...@dastardlyhq.com wrote:
>> On Thu, 23 Jun 2022 11:33:22 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> On 23/06/2022 09:11, Mut...@dastardlyhq.com wrote:
>>>> Initialisation is the whole process, assignment is specifically setting the
>
>>>> values and the terminology doesn't depend on whether a value is already
>>> there.
>>>
>>> Bo is correct. Words like "initialisation" and "assignment" have
>>> specific meanings in the language, and it is useful to get in the habit
>>> of using them accurately. You are right that assignment can happen
>>> without a value being in the object ("int x; x = 1;"). But the object
>>> has to exist and have completed its initialisation, if any, before an
>>> assignment can happen.
>>
>> Exactly. Initialisation consists of allocating the memory. Then you ASSIGN
>> the values to that memory.
>
>That is not correct usage of the technical terms (and it is the
>technical terms that matter). Initialisation does not consist solely of
>allocating memory, nor is allocation of memory necessary for many
>initialisations.

So the value doesn't get assigned to the memory. It just magically appears
there?

>> Highly unlikely.
>>
>
>I've noticed a fair number of grammatical errors in your writing, but
>none in Bo's posts. Of course I have not examined all his posts. My

I write my posts in vi without any spell checking plugins and given I'm working
I have better things to do that double check spellings to keep pedants like you
happy.

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 14:56:27 -0000 (UTC)

Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:
>> On Thu, 23 Jun 2022 11:07:49 -0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>There are, in fact, some utility classes in the standard library where
>>>that's exactly the case, most prominently std::unique_ptr. You can
>>>initialize it but you can't (copy) assign one. (You can move assign, but
>>>that's a bit different.)
>>
>> I don't see your point. You're still assigning a value to it, the fact that
>> you can only do it the once is neither here nor there.
>
>Seriously, how hard it is to just say "ah, sorry, my bad, I stand corrected.
>I learned something new today", instead of just going into this endless and
>futile quest of trying to "win" and to "be right" in such a petty little
>thing?

Its not me arguing the toss or making a big deal out of it. Computer memory has
values assigned to it whereas initialisation is what happens at power on. End.
Just because C++ uses a different definition doesn't change that fact nor does
it make my original post wrong.

>Admitting not having known something, or having made a small mistake, is not
>a bad thing, nor is it shameful. You don't have to always "win". You don't
>have to always "be right". You can perfectly well be mistaken, admit it,
>learn from the mistake, and nobody will ridicule you.

Oh bless, you're so kind.

[Christian Gollwitzer]

Am 23.06.22 um 17:14 schrieb Mut...@dastardlyhq.com:

> On Thu, 23 Jun 2022 16:10:27 +0200
> David Brown <david...@hesbynett.no> wrote:

>> That is not correct usage of the technical terms (and it is the
>> technical terms that matter). Initialisation does not consist solely of
>> allocating memory, nor is allocation of memory necessary for many
>> initialisations.
>
> So the value doesn't get assigned to the memory. It just magically appears
> there?

Believe it or not, in some cases that is exactly what's happening. For
example, if you have a static file scope variable

static int x = 42;

int somefunc() {
}

then this might be translated into a section of the executable which
contains the static variables. Therefore, upon starting the program, the
values 42 will just "magically" be there (it comes with the code). There
is no explicut "MOV"-instructino or the like.

Of course, these things go beyond the C++ standard, and you should not
worry about them. The compiler will do the right thing for you.

Christian

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 17:29:18 +0200
Christian Gollwitzer <auri...@gmx.de> wrote:
>Am 23.06.22 um 17:14 schrieb Mut...@dastardlyhq.com:
>> On Thu, 23 Jun 2022 16:10:27 +0200
>> David Brown <david...@hesbynett.no> wrote:
>
>>> That is not correct usage of the technical terms (and it is the
>>> technical terms that matter). Initialisation does not consist solely of
>>> allocating memory, nor is allocation of memory necessary for many
>>> initialisations.
>>
>> So the value doesn't get assigned to the memory. It just magically appears
>> there?
>
>Believe it or not, in some cases that is exactly what's happening. For
>example, if you have a static file scope variable
>
>static int x = 42;
>
>int somefunc() {
>}
>
>then this might be translated into a section of the executable which
>contains the static variables. Therefore, upon starting the program, the
>values 42 will just "magically" be there (it comes with the code). There

Yes, thats right, its all magic.

>is no explicut "MOV"-instructino or the like.

Nooooooo! Really?? Incredible!

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
>>Admitting not having known something, or having made a small mistake, is not
>>a bad thing, nor is it shameful. You don't have to always "win". You don't
>>have to always "be right". You can perfectly well be mistaken, admit it,
>>learn from the mistake, and nobody will ridicule you.
>
> Oh bless, you're so kind.

You didn't answer my question. How hard it is to just say "I stand corrected"
and move on?

What exactly are you gaining from this hill you are decided to die on?

Just take the advice: There's absolutely no reason for you to behave like
this. You don't need to "win" the argument. There's nothing to "win".
There's only something to lose: Your reputation.

[Mut...@dastardlyhq.com]

On Thu, 23 Jun 2022 17:33:09 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:
>>>Admitting not having known something, or having made a small mistake, is not
>>>a bad thing, nor is it shameful. You don't have to always "win". You don't
>>>have to always "be right". You can perfectly well be mistaken, admit it,
>>>learn from the mistake, and nobody will ridicule you.
>>
>> Oh bless, you're so kind.
>
>You didn't answer my question. How hard it is to just say "I stand corrected"
>and move on?

When I do stand so I'll let you know.

[Peter Chapin]

When I teach C++ I describe the difference by saying that assignment has
to do the work of destruction followed by the work of initialization.
You "assign" to a well-defined object and that object needs to be
destroyed, in effect, before it can accept a new value. However, you
"initialize" an undefined object; giving the object its first value is
the point of initialization. Thus you *must not* destroy it before
storing the initial value into it since the object isn't in a
functioning state yet.

One consequence of this is that initialization can be faster than
assignment, and thus it is nice to initialize every object if possible.
(Hence the rationale for allowing declarations, and their corresponding
initializations, to occur throughout the code).

Of course for integers there is no difference, since integers don't have
destructors, which is why programmers from other languages are often
confused about the distinction.

Peter

[daniel...@gmail.com]

On Wednesday, June 22, 2022 at 4:19:05 AM UTC-4, David Brown wrote:
>
> There are two key advantages to the uniform initialisation style. One
> is consistency - it is useful for more complicated initialisations, and
> some people prefer the consistency of using it for all initialisations.

But you can't use it for _all_ initializations, sometimes what looks like
uniform initialization actually means initializer list. If you wanted to
construct a vector of ten ints, you would need to use

std::vector<int> v(10);

rather than

std::vector<int> v{10};

which means something else. The notion of uniformity is somewhat
contradictory to the spirit of C++, which is more along the lines of
in this situation do one thing, in that, do another.

Daniel

[Gawr Gura]

I believe, in this case, that the copy elision is not only possible but
required after C++17. There shouldn't be a difference between

auto vec = std::vector{ 1, 2, 3, 4 };

and

std::vector vec{ 1, 2, 3, 4 };

https://godbolt.org/z/drd3xYYzE


Please correct me if I'm wrong.

[David Brown]

Agreed. Things are seldom perfect in a programming language that has
grown over time. As the features and possibilities grow, so do the
inconsistencies and quirks. But it is not easy to do something about
that, while also maintaining compatibility with existing code.

[Juha Nieminen]

Gawr Gura <gawr...@mail.hololive.net> wrote:
>> I have seen some people even use this idiom, with no understanding of that
>> difference:
>>
>> auto vec = std::vector { 1, 2, 3, 4 };
>>
>> While normally the compiler is allowed to optimize the temporary and the
>> copy constructor call away, I'm actually not sure it can do that in this
>> case. I find this idiom abhorrent.
>
> I believe, in this case, that the copy elision is not only possible but
> required after C++17. There shouldn't be a difference between
>
> auto vec = std::vector{ 1, 2, 3, 4 };
>
> and
>
> std::vector vec{ 1, 2, 3, 4 };

Is the compiler required to elide the copy constructor call in this case?
Is there a difference between:

std::string str = "hello";

and

std::string str = std::string("hello");

[Paavo Helde]

23.06.2022 18:14 Mut...@dastardlyhq.com kirjutas:
> On Thu, 23 Jun 2022 16:10:27 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 23/06/2022 15:20, Mut...@dastardlyhq.com wrote:
>>> On Thu, 23 Jun 2022 11:33:22 +0200
>>> David Brown <david...@hesbynett.no> wrote:
>>>> On 23/06/2022 09:11, Mut...@dastardlyhq.com wrote:
>>>>> Initialisation is the whole process, assignment is specifically setting the
>>
>>>>> values and the terminology doesn't depend on whether a value is already
>>>> there.
>>>>
>>>> Bo is correct. Words like "initialisation" and "assignment" have
>>>> specific meanings in the language, and it is useful to get in the habit
>>>> of using them accurately. You are right that assignment can happen
>>>> without a value being in the object ("int x; x = 1;"). But the object
>>>> has to exist and have completed its initialisation, if any, before an
>>>> assignment can happen.
>>>
>>> Exactly. Initialisation consists of allocating the memory. Then you ASSIGN
>>> the values to that memory.
>>
>> That is not correct usage of the technical terms (and it is the
>> technical terms that matter). Initialisation does not consist solely of
>> allocating memory, nor is allocation of memory necessary for many
>> initialisations.
>
> So the value doesn't get assigned to the memory. It just magically appears
> there?

Here is an example of initialization without assignment (assignment
would not be possible because the object is const):

const int x = 3;

In case you really do not know initialization and assignment are
different operations in C++, here is an instrumented class to show you
the difference:

#include <iostream>

class A {
public:
A(int x) {
std::cout << "Formatting file servers' hard drives ...\n";
}
A& operator=(int x) {
std::cout << "Sending an e-mail about that to your boss ...\n";
return *this;
}
};

int main() {
A a = 3;
a = 3;
}

[Gawr Gura]

You should certainly refer to the standard rather than just trust me.
However, my understanding is that yes the compiler is required to elide
both the copy constructor call and the assignment operator call
specifically in this case. As far as I understand it, the compiler is
required to treat both as being equivalent to

std::string str("hello");

https://godbolt.org/z/TYGMbjvoo

[Frederick Virchanza Gotham]

On Sunday, June 26, 2022 at 11:20:06 PM UTC+1, Gawr Gura wrote:

> However, my understanding is that yes the compiler is required to elide
> both the copy constructor call and the assignment operator call
> specifically in this case.

I would have to read this page slowly a few times:

https://en.cppreference.com/w/cpp/language/copy_elision

If my memory serves me right . . . about 15 years ago, the C++ compiler could elide copy-construction if it wanted to.

Nowadays, I don't know if it's been made mandatory or not. The above article might give an answer on that (I quickly skimmed over it and couldn't see a definitive answer but maybe I missed it).

[Gawr Gura]

The first thing on that page is a description of the guaranteed copy
elision rules. Specifically, the second bullet point covers the case of
copy elision in the initializer.