Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Noob question: why the confusing syntax (data typevariable_name(value)) for initialization

Reply
Thread Tools

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

 
 
krishna
Guest
Posts: n/a
 
      09-23-2008
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
 
Reply With Quote
 
 
 
 
news.aioe.org
Guest
Posts: n/a
 
      09-23-2008
krishna wrote:
> 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) {}
};
 
Reply With Quote
 
 
 
 
Stephen Horne
Guest
Posts: n/a
 
      09-24-2008
On Tue, 23 Sep 2008 16:06:58 -0700 (PDT), krishna
<(E-Mail Removed)> wrote:

>What is the need of this syntax for initializing values, isn't this
>ambiguous to function call?


Specifically for initialisers, well, an initialiser *is* a function
call. Specifically a constructor call. Though it may be translated to
something else, as with int which doesn't have a constructor as such.

IIRC in variable declarations, the initialiser and assignment syntax
are defined as equivalent - they always refer to a constructor if one
is available.

That said, despite the other replies, in a sense, you are right.

A common criticism of C, C++ and similar languages is the amount of
ambiguity in the grammars. This can be difficult for both people and
for compilers.

For compilers, it means that they have to keep track of "context" -
what the code actually means so far - in order to parse the next bit
correctly. So there are times when the parser needs to know that a
particular identifier actually refers to a datatype in order to parse
the next bit of code, even though that datatype may have been declared
hundreds of lines ago or even in a library somewhere.

In otherwise, parsing and semantic analysis have to run somewhat
concurrently. This is nasty hackishness.

People have essentially the same problem. You often need to know what
an identifier refers to in order to determine what construct a piece
of code is using - as opposed to the ideal in which the code gives
plenty of clues as to what is being done with what. The reader should
be trying to understand the logic, not the syntax.

For the most part, the solution is naming conventions. We all know
that 'int' is a type, but for user-defined types there are various
conventions to ensure that it's clear. An '_t' suffix, or a 'C' or 'I'
prefix for classes and interface-classes respectively, are common.

Much as I'm a big fan of C++, I have to admit that languages like
Pascal and Ada have this right. Better to avoid the ambiguity from the
start. But so long as the programmer takes responsibility for what he
is writing, it's not such a big deal.

 
Reply With Quote
 
Fred Zwarts
Guest
Posts: n/a
 
      09-24-2008
"krishna" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> 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.
 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-24-2008
krishna <(E-Mail Removed)> writes:

> 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__
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-24-2008
On Sep 24, 1:06 am, krishna <(E-Mail Removed)> wrote:
> 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".)

> 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<int> as its first argument, a pointer to a
function which returns an std::istream_iterator<int> as 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:(E-Mail Removed)
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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-24-2008
On Sep 24, 10:28 am, (E-Mail Removed) (Pascal J. Bourguignon)
wrote:
> krishna <(E-Mail Removed)> writes:
> > 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.


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:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Here a noob, there a noob.... JimDoire MCSE 0 04-10-2008 07:23 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Aaaargh! noob question static string array initialization anti-guru C++ 2 09-02-2004 08:59 AM
import module from package - confusing syntax David MacQuigg Python 2 07-04-2004 12:49 PM



Advertisments