Dependent definitions

[Paul]

The below code works just fine to output 3. However, I'm uncomfortable about
defining y in terms of x in the same expression that defines x.
The code assumes that int x = 7, y = f(x); is equivalent to
int x = 7; int y = f(x);

Are they in fact equivalent? Is it a rule of C++ that
something1 , something2, ... always results in evaluating something1
before something2 etc. etc ?
I know that the comma operator works that way, but the below isn't
the comma operator.

Thanks,
Paul


int f(int)
{
return 3;
}

int main()
{
int x = 7, y = f(x);
std::cout << y;
}

[Alf P. Steinbach]

Your ¹instinct that it's safer to use separate declarations is correct.

The declaration you have, with multiple declarators, is /technically/
correct, but it's easy to get wrong. And one can easily get confused
about types. E.g.

int const x = 1, y = 2;

Well, is `y` `const` or not?


Cheers!,

- Alf

¹ Women have intuition, while men have instinct. It's the same really.

[Paul]

According to the WellWhyDontYouJustTryItAndSee rules, it can be observed
that y is const in your example. However, this surprised me.
I assumed it was akin to the old chestnut int* x = 0, y = 0; Here y
is an int, not a pointer.

Paul

[Ben Bacarisse]

Paul <peps...@gmail.com> writes:

> On Saturday, January 14, 2017 at 3:18:14 PM UTC, Alf P. Steinbach wrote:

<snip>
>> Your šinstinct that it's safer to use separate declarations is correct.

>>
>> The declaration you have, with multiple declarators, is /technically/
>> correct, but it's easy to get wrong. And one can easily get confused
>> about types. E.g.
>>
>> int const x = 1, y = 2;
>>
>> Well, is `y` `const` or not?
>
> According to the WellWhyDontYouJustTryItAndSee rules, it can be observed
> that y is const in your example. However, this surprised me.
> I assumed it was akin to the old chestnut int* x = 0, y = 0; Here y
> is an int, not a pointer.

There's a style in C++ of gluing parts of the declarator onto the type
(int*, char& and so on). I've never got on with that because the * is,
syntactically, associated with the name, not the "base type" (if you
know what I mean). To me it's not (written to give some idea of timing)
"intstar x initially 0 and y initially 0" but "int... starx initially
zero and y initially zero". "int* x;" looks almost as odd to me as
"return* y;"

I get that it's the done thing in C++ (it carries BS's seal of approval)
but I can't get one with it.

Things are messier with const since that keyword can appear in either
place.

int const *x, *const y;

but I've been using C and C++ for so long that with helpful spacing even
these are clear to me. (Here y is const but x is not. Both point to
const int.)

--
Ben.

[David Brown]

This is the kind of question you only have to ask if you are dealing
with other people's code. If you are writing code yourself, simply
don't do that sort of thing - it makes it harder to understand, and

easier to get wrong. Write:

int x = 7;
int y = f(x);

No one can possibly misinterpret that.

[Paul]

On Saturday, January 14, 2017 at 11:11:29 PM UTC, David Brown wrote:

...

> This is the kind of question you only have to ask if you are dealing
> with other people's code.

...

But I've never heard of a software role that doesn't involve "dealing with
other people's code."

Paul

[David Brown]

The extent to which you are dealing with other people's code can vary a
lot, but in some cases you don't have much interaction with source code
that you haven't written yourself.

But my point is that while you might come across code like "int x = 7, y
= f(x);" and therefore you would have to know what it means, it is not
something that (IMHO) you should write yourself.

[Andrey Tarasevich]

On 1/14/2017 7:05 AM, Paul wrote:
> The code assumes that int x = 7, y = f(x); is equivalent to
> int x = 7; int y = f(x);
>
> Are they in fact equivalent? Is it a rule of C++ that
> something1 , something2, ... always results in evaluating something1
> before something2 etc. etc ?

Yes, there is.

-------------------------------------------------------------------

8 Declarators [dcl.decl]

3 Each init-declarator in a declaration is analyzed separately as if it
was in a declaration by itself.(99

---

99) A declaration with several declarators is usually equivalent to the
corresponding sequence of declarations each with a single declarator.
That is

T D1, D2, ... Dn;

is usually equivalent to

T D1; T D2; ... T Dn;

where T is a decl-specifier-seq and each Di is an init-declarator. An
exception occurs when a name introduced by one of the declarators hides
a type name used by the decl-specifiers, so that when the same
decl-specifiers are used in a subsequent declaration, they do not have
the same meaning, as in

struct S ... ;
S S, T; // declare two instances of struct S

which is not equivalent to

struct S ... ;
S S;
S T; // error

Another exception occurs when T is auto (7.1.6.4), for example:

auto i = 1, j = 2.0; // error: deduced types for i and j do not match

as opposed to

auto i = 1; // OK: i deduced to have type int
auto j = 2.0; // OK: j deduced to have type double

-------------------------------------------------------------------

--
Best regards,
Andrey Tarasevich