Connecting Tech Pros Worldwide Forums | Help | Site Map

Noob question: why the confusing syntax (data typevariable_name(value)) for initialization

krishna
Guest
 
Posts: n/a
#1: Sep 24 '08
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
e.g., int func_name(20); this looks like function call (of course not
totally as there is no function body), but is declaration and
initialization of an integer variable 'func_name', is it step towards
completeness of OOP abstraction in the language, here one could say we
are creating and initializing an integer object, but then again it
(this way of object initialization) is not so much OOPy (so to speak),
so, maybe that's not true.

Thanks for your time

Krishna

news.aioe.org
Guest
 
Posts: n/a
#2: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


krishna wrote:
Quote:
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
e.g., int func_name(20); this looks like function call (of course not
totally as there is no function body), but is declaration and
initialization of an integer variable 'func_name', is it step towards
completeness of OOP abstraction in the language, here one could say we
are creating and initializing an integer object, but then again it
(this way of object initialization) is not so much OOPy (so to speak),
so, maybe that's not true.
>
Thanks for your time
>
Krishna
Looks like a function call with no function body? When did function calls start
to have a body? You mean function declaration? When did function declarations
start to take a const as an argument? I am not so sure about the reasoning
behind why the language allows such an initialization, though nothing object
oriented or ambiguous about it, it follows the same pattern as member
initialization in the constructor definitions.

class X
{ int y;
public:
X() : y(10) {}
};
Victor Bazarov
Guest
 
Posts: n/a
#3: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


krishna wrote:
Quote:
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
How is that ambiguous? Type followed by a name is [normally] an object
declaration. A object declaration followed by parenthesized expression
or the symbol '=' followed by an expression is initialisation. And
since it's a declaration statement it cannot be confused with a function
call. A function call can only appear within an expression.
Quote:
e.g., int func_name(20); this looks like function call
No, it doesn't. It starts with 'int', so it's a declaration.
Quote:
(of course not
totally as there is no function body),
A function *call* does not require a body.
Quote:
but is declaration and
initialization of an integer variable 'func_name', is it step towards
completeness of OOP abstraction in the language,
"OOP abstraction"? Not sure what you mean. But the initialisation
syntax is common for all types, fundamental and user-defined alike.
If you define a class that has a constructor that can be called with
a single argument, you can write

myclass object(singleargument);

does that confuse you as well? Does that look like a function call?
Well, it is. It's a statement that *results* in a call to the class
constructor. To generalise the syntax one needs to allow the same
syntax for other scalar types, integral, pointers, references.
Quote:
here one could say we
are creating and initializing an integer object, but then again it
(this way of object initialization) is not so much OOPy (so to speak),
so, maybe that's not true.
Object called 'func_name' is certainly misleading. OOPy or not, the
statement you brought for this discussion *is* an object declaration
and initialisation. Objects in C++ have the type and they are often
associated with a name. In your case it's an object of type 'int'
and it has the name 'func_name'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


Fred Zwarts
Guest
 
Posts: n/a
#4: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


"krishna" <krishna.k.0001@gmail.comwrote in message news:eb21c488-73a0-46e0-aaf2-9c1b8b9e215c@x16g2000prn.googlegroups.com...
Quote:
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
e.g., int func_name(20); this looks like function call (of course not
totally as there is no function body), but is declaration and
initialization of an integer variable 'func_name', is it step towards
completeness of OOP abstraction in the language, here one could say we
are creating and initializing an integer object, but then again it
(this way of object initialization) is not so much OOPy (so to speak),
so, maybe that's not true.
Note that the alternative way of initializing

int func_name = 20;

looks ambiguous, as well. It looks like an assignment.
In C++ assignment is very different from initialization.
So, both ways of writing an initializer are "ambiguous".
The ambiguity is solved by the context in both cases.
Pascal J. Bourguignon
Guest
 
Posts: n/a
#5: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


krishna <krishna.k.0001@gmail.comwrites:
Quote:
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
My theory is that it's because C and C++ language designers
are lazy bums who can't type with more than two fingers.

So they had somewhere code to parse ident(expr[,expr]*),
and since they need to match a member ident to an expression,
they just copy-and-pasted the grammar rule and the parsing code.

See:
http://steve-yegge.blogspot.com/2008...le-secret.html


--
__Pascal Bourguignon__
James Kanze
Guest
 
Posts: n/a
#6: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


On Sep 24, 1:06 am, krishna <krishna.k.0...@gmail.comwrote:
Quote:
What is the need of this syntax for initializing values, isn't
this ambiguous to function call?
History. It's generally recognized as an embarassing feature.
(I believe it has been referred to as "C++'s most embarassing
parse".)
Quote:
e.g., int func_name(20); this looks like function call (of
course not totally as there is no function body), but is
declaration and initialization of an integer variable
'func_name',
You mean it looks like a function declaration, not a function
call. And it gets worse. Consider:

int f( x ) ;

Whether this declares a variable initialized with x, or a
function which takes an argument of type x, depends on whether x
is declared as a variable or a type. Or:

T1 f( T2( x ) ) ;

This is a declaration of a function, always (supposing T1 and T2
are types). Even if what you meant was to explicitly convert x
to type T2, and use it to initialize a variable of type T1.
This leads to some very strange error messages at times:

std::vector< int v( std::istream_iterator< int >( source ),
std::istream_iterator< int >() ) ;

actually declares a function named v, which takes an
std::istream_iterator<intas its first argument, a pointer to a
function which returns an std::istream_iterator<intas its
second argument, and returns an std::vector<int>. Which is
perfectly legal, but when you try to use v later, as a vector,
you get some strange error messages about a function not being
legal in such and such a context.

If the language were being designed from scratch, with no
concerns of backwards compatiblity or history, I'm sure that the
declaration syntax would be significantly different. But it's
not, and wasn't. In the early days, and even now to some
extent, there is a requirement of C compatibility. And since
the declaration syntax in C is horribly broken, no matter what
C++ does with it will cause problems somewhere.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
Guest
 
Posts: n/a
#7: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


On Sep 24, 10:28 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Quote:
krishna <krishna.k.0...@gmail.comwrites:
Quote:
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
Quote:
My theory is that it's because C and C++ language designers
are lazy bums who can't type with more than two fingers.
My theory is that C's designers only had teletypes. If you've
ever worked near a teletype which is outputting something, you
can understand their desire to reduce the number of characters
to a minimum.

As for the motivation of C++'s designer, it's clear: C
compatibility. (I think it was Stroustrup who categorized C's
declaration syntax as an experiment which failed.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jeff Schwab
Guest
 
Posts: n/a
#8: Sep 24 '08

re: Noob question: why the confusing syntax (data typevariable_name(value)) for initialization


krishna wrote:
Quote:
What is the need of this syntax for initializing values, isn't this
ambiguous to function call?
e.g., int func_name(20); this looks like function call (of course not
totally as there is no function body), but is declaration and
initialization of an integer variable 'func_name', is it step towards
completeness of OOP abstraction in the language, here one could say we
are creating and initializing an integer object, but then again it
(this way of object initialization) is not so much OOPy (so to speak),
so, maybe that's not true.
As others have already pointed out, there is no ambiguity in your
example. There are cases in which something clearly meant to be object
construction is seen by the compiler as a function call, but this is not
one of those cases.

I believe the C++ construction syntax was designed to mimic a function
call, because constructors are functions. You're not really "calling" a
constructor, but one is (in principle) being invoked for you when you
use this syntax.
Closed Thread