int number {89}

[gdo...@gmail.com]

this is not the best idea for change.
int number = 86.9
could have been handled as an error by the compiler,
much like int number {86.9}

assignment, int number = 5; , this is a much less complex thought
and the meaning is clear.

string name{"Paul"};
string name = "Paul";

why the initialization is preferred syntax for c++20, good grief.
feels like change for change sake.

[gdo...@gmail.com]

if ( int value{7}; value == 7)
{ ... }
else
{...}

come on there can't be much use of this can there?
it seems it leads more hacking of code then well thought code.
like, I'm starting typing in code and oh yeah I realize a need an
integer here so let me stick it in. no worries though cause it's scope is limited.
hm? I guess that is in keeping with the 'c' way. I'm looking forward
to a chance to use it. don't think it makes the code more readable or
concise but oh well. '17 . c++20 here we come.

[David Brown]

I have always felt more comfortable with the "old-style" assignment
initialisation for simple types - using braces looks ugly to me. But
it's a matter of personal preference and habit.

If you want an error for "int number = 86.9;", then with gcc at least
you can use "-Werror=conversion". I expect clang has the same flag, but
I don't know about other compilers.

Trying to change the C++ standard here would be a disaster for existing
code (which is why errors for narrowing conversions were possible for
the new brace initialisation syntax, but could not be changed for old
assignment initialisation). So warning flags in compilers and linters
is the best you can do.

[Juha Nieminen]

gdo...@gmail.com <gdo...@gmail.com> wrote:
> if ( int value{7}; value == 7)
> { ... }
> else
> {...}
>
> come on there can't be much use of this can there?

It's not only to limit the visibility of the variable to the scope of the
conditional (which in itself is useful, don't get me wrong). Sometimes
you want the object in question to be destroyed at the end of the
conditional. Before you had to do it in an uglier way:

//----------------------------------------
code_code_code();

{
Type obj = something;
if(obj)
{
do_something_with(obj);
}
} // 'obj' will be destroyed here

more_code_here();
//----------------------------------------

Now you can achieve the same thing easier:

//----------------------------------------
code_code_code();

if(Type obj = something; obj)
{
do_something_with(obj);
} // 'obj' will be destroyed herre

more_code_here();
//----------------------------------------

[gdo...@gmail.com]

will since the committee would probably tell me to go pound sand...
hm, vector seems like a bad choice to describe and array.
you know the word array would have worked just fine. why I say that,
yes I know no one cares, but here it is anyway, when I think of vectors,
I think physics or computer graphics not a group of items of the same type to
hold data, to hold something. vectors? how about container? and don't give
me the too many letters to type thing, lol. have you seen how we now
cast a variable? good grief! static_cast <new_type> (expression) really
good grief.

container_of ints myStuff[]; // ints more than one int 🙂
container_of reals myOthersStuff[]; // reals more than one real 🙂

int myArray[]; was/is ok, well to me. std::vector<int> myArray; man! my fingers are
having flash back to Cobol. lol.

hm? std::Array_type<int> myArray(5) seems better to me. lol or
std::Array_type<int> myArray[5] since we use the square bracket to access
the indexed item.

yes, yes, now I get why people create different languages. one day after learning
c++ well enough I could join those great thinkers, or, or hmm, is typedef still
around. 🤣😇

[gdo...@gmail.com]

hm? this was bad. I'm surprised. when the scope of the variable has been reached
that space should be free and reclaimable.
Questions, when a local variable(s) is created it is pushed on the stack?
once the function is ended, isn't all the variables that were created
removed from the stack?

Questions: when a function returns the address, the function terminates but it gave,
returned an address. now the address return is a location, but the value there should not be considered valid right, right. I works out to be ok because the returned address had a type an given that address the system knows how many bytes are associated with that address and if not wrote to that address the data would be as last left, but really it is not usable. (unless it was global)

when does a function end at the '}' or at the 'return ' because the return never let's it reach the ending '}' ? so are those locals still on the stack still on the stack?

[James Kuyper]

On 11/30/22 21:41, gdo...@gmail.com wrote:
> will since the committee would probably tell me to go pound sand...
> hm, vector seems like a bad choice to describe and array.

It has long been a standard mathematical term to use for arrays that
have only a single row or a single column, which is a fairly good match
to the usage in C++. Keep in mind that there is also std::array<>.

> you know the word array would have worked just fine. why I say that,
> yes I know no one cares, but here it is anyway, when I think of vectors,
> I think physics or computer graphics not a group of items of the same type to
> hold data, to hold something. vectors? how about container? and don't give
> me the too many letters to type thing, lol. have you seen how we now
> cast a variable? good grief! static_cast <new_type> (expression) really
> good grief.

It might interest you to know that the named casts were deliberately
designed to be someone inconvenient to type, so as to discourage
unnecessary use of them. They are also long to make it easy to search a
program for them.

The C standard use "container" in a more general sense, which seems
fitting to me, since "container" in ordinary English is a rather vague
term that covers a lot of different things.

[James Kuyper]

On 11/30/22 23:57, gdo...@gmail.com wrote:
> On Monday, November 28, 2022 at 3:09:38 AM UTC-5, Juha Nieminen wrote:

...

>> It's not only to limit the visibility of the variable to the scope of
>> the conditional (which in itself is useful, don't get me wrong).
>> Sometimes you want the object in question to be destroyed at the end
>> of the conditional. Before you had to do it in an uglier way:
>> //---------------------------------------- code_code_code();
>> { Type obj = something; if(obj) { do_something_with(obj); } } //
>> 'obj' will be destroyed here
>> more_code_here(); //----------------------------------------
>> Now you can achieve the same thing easier:
>> //---------------------------------------- code_code_code();
>> if(Type obj = something; obj) { do_something_with(obj); } // 'obj'
>> will be destroyed herre
>> more_code_here(); //----------------------------------------
>
> hm? this was bad. I'm surprised. when the scope of the variable has
> been reached
> that space should be free and reclaimable.

An object with automatic storage duration does in fact get destroyed and
the memory deallocated when the end of its scope is reached. I'm curious
- which of the above examples appears, in your opinion, to be
inconsistent with that rule? Both of the comments that says "'obj' will
be destroyed here" is located on precisely the line where the scope of
'obj' ends.

> Questions, when a local variable(s) is created it is pushed on the
> stack? once the function is ended, isn't all the variables that were
> created
> removed from the stack?

No, each block in a program can have it's own automatically allocated
objects, and such objects should be destroyed and the memory they
resided in deallocated at the end of the block. That will be at the end
of the function only for the outermost block of the function.

Whether a stack of any kind is involved is outside the scope of the C++
language definition. It talks about object lifetimes and scopes, but not
stacks (except for std::stack<>, which is a different issue). On systems
that, for instance, use activation records rather than stacks, the same
rules apply, but their implications for how activation records are
created and destroyed are different from the implications for how stacks
are pushed and popped.

> Questions: when a function returns the address, the function
> terminates but it gave,
> returned an address. now the address return is a location, but the
> value there should not be considered valid right, right. I works out
> to be ok because the returned address had a type an given that address
> the system knows how many bytes are associated with that address and
> if not wrote to that address the data would be as last left, but
> really it is not usable. (unless it was global)

The object that used to reside in the location that the pointer points
at might have already been replaced by something else, which is why it's
undefined behavior to dereference such a pointer.

> when does a function end at the '}' or at the 'return ' because the
> return never let's it reach the ending '}' ? so are those locals still
> on the stack still on the stack?

A return statement ends all of the nested blocks that it occurs inside,
in reverse order of nesting. Objects with automatic storage duration
defined in those blocks will be destroyed and deallocated in that same
order.

[Juha Nieminen]

gdo...@gmail.com <gdo...@gmail.com> wrote:
> when does a function end at the '}' or at the 'return ' because the return
> never let's it reach the ending '}' ? so are those locals still on the
> stack still on the stack?

Sure. Every time you write 'return' the compiler will just leave everything
it added to the stack there, and thus every function call that has a
'return' will cause a stack leak, and thus every program out there that
uses any 'return' statements are quicky running out of stack space and
crashing at some point because of that. Which would be pretty much every
program in existence.

How do you think it works?

[Juha Nieminen]

gdo...@gmail.com <gdo...@gmail.com> wrote:
> will since the committee would probably tell me to go pound sand...
> hm, vector seems like a bad choice to describe and array.
> you know the word array would have worked just fine. why I say that,
> yes I know no one cares, but here it is anyway, when I think of vectors,
> I think physics or computer graphics not a group of items of the same type to
> hold data, to hold something. vectors? how about container? and don't give
> me the too many letters to type thing, lol. have you seen how we now
> cast a variable? good grief! static_cast <new_type> (expression) really
> good grief.

In mathematics an Nx1 matrix is called a vector.

[Paavo Helde]

01.12.2022 06:57 gdo...@gmail.com kirjutas:
>
> when does a function end at the '}' or at the 'return ' because the return never let's it reach the ending '}' ? so are those locals still on the stack still on the stack?

If the implementation uses a stack, then a return statement will restore
the stack pointer register to its previous value before the call. As
this is the only thing which defines the size of the stack, any bytes
beyond that cannot be considered "alive" any more in any sense. These
bytes can and will be reused for new stack objects immediately.

And yes, if the local objects on stack have destructors, the
implementation needs to call these destructors when executing the return
statement. Otherwise it would be horribly broken.

Suggesting to study some assembler to understand what it means for a
variable to exist in memory, at the low level. Hint: the only reason why
a region of memory can be considered as an object is that the program
thinks so.

[Öö Tiib]

Yes, with fixed N it is called vector. Alexander Stepanov has been sometimes
ranting how sorry he feels for that name "vector". Then history unfolded ... boost
added another "array" that was moved to std ... and so now we have naming
in C++ kind of upside down.

That is fine ... usage of tool with controversial naming helps to forgive,
to accept and to use whatever absurdities in problem domain slang of our
customers and interfaces of fruits of our cooperation partners. After all
all words are just noise made by squirting air through meat.
<https://www.mit.edu/people/dpolicar/writing/prose/text/thinkingMeat.html>
What matters is what was meant by doing that.

[Scott Lurndal]

James Kuyper <james...@alumni.caltech.edu> writes:
>On 11/30/22 23:57, gdo...@gmail.com wrote:
>> On Monday, November 28, 2022 at 3:09:38 AM UTC-5, Juha Nieminen wrote:
>...
>>> It's not only to limit the visibility of the variable to the scope of
>>> the conditional (which in itself is useful, don't get me wrong).
>>> Sometimes you want the object in question to be destroyed at the end
>>> of the conditional. Before you had to do it in an uglier way:
>>> //---------------------------------------- code_code_code();
>>> { Type obj = something; if(obj) { do_something_with(obj); } } //
>>> 'obj' will be destroyed here
>>> more_code_here(); //----------------------------------------
>>> Now you can achieve the same thing easier:
>>> //---------------------------------------- code_code_code();
>>> if(Type obj = something; obj) { do_something_with(obj); } // 'obj'
>>> will be destroyed herre
>>> more_code_here(); //----------------------------------------
>>
>> hm? this was bad. I'm surprised. when the scope of the variable has
>> been reached
>> that space should be free and reclaimable.
>
>An object with automatic storage duration does in fact get destroyed and
>the memory deallocated when the end of its scope is reached.

True for non-pod, but not necessarily true for POD; consider:

int
func(int a)
{
int c;
while (a > 0) {
int d;
/* do something with a and d and c */
}

/* d is now out of scope, but wont' be
deallocated until the 'func' returns */
if (c < 0) {
int e; /* most likely will used the same VA used for 'd' */

/* do something */
}
}
/*at this point the storage for d and e will be "deallocated" when
the stack is cleaned up by function return
*/

[David Brown]

Logically, it is true for non-POD /and/ for POD, regardless of where the
object is actually placed - stack, register, "optimised away", or a
combination of these, or anything else. A compiler can optimise
combining stack allocations and de-allocations, but that has nothing to
do with when the object exists and ceases to exist as far as the
language is concerned. Don't confuse optimisation and implemented
object code with the logic of the abstract machine.