David R. Tribble wrote:
>
> ... much deleted ...
>
> I said it before, and I'll repeat: It looks like a void function, it works
> like a void function, and it damn well returns a value like a void function.
> I ought to be able to declare it as 'void' type, and compilers ought to be
> smart enough to handle this (they already know it's the ctor/dtor function
> from its name).  As it stands, it's a hole in the syntax of the language.
> And it's confusing at best, especially to beginners.
>

I feel that it is incorrect to say a constructor "returns a value like a
void function".

For a class X:

 extern f( const X& );
 f( X() ); // legal C++, but NOT legal if ctor signature is void X()

is valid code.

It is clear that the constructor is NOT returning a value "like a void
function" since no void function could be used in place of X().

--
 Scott J Irwin   Amerinex Applied Imaging, Inc
 sirwin@aai.com   409 Main St, Amherst, MA 01002
 413-256-8941   http://www.aai.com



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Srinivas Vobilisetti wrote:
>
> James Kanze wrote:
> >
> > "David R. Tribble" <david.tribble@central.beasys.com> writes:
>
> > |>
> > |>  I said it before, and I'll repeat: It looks like a void function,

    class Foo {
    public:
        Foo(); // doesn't look like a void function to me
    };

> > |> it works
> > |>  like a void function,

I can't call it. I can't take its address. It has hidden internal calls
to base class ctors, etc.

> > |> and it damn well returns a value like a void function.

Except that void functions do NOT return a value!

> > Except, of course, that the constructor is definitly not a void
> > function, since an expression explicitly calling the constructor
> > (e.g. "MyType()") does not have type void.

But that is *not* explicitly "calling the constructor". That is making
an explicit temporary of a certain type. Significant difference.

> I think if return types are added for ctor/dtor of class T,

They won't be added, but if they were, they would have to be optional. I
don't see how they would be of any use, then.

> the return types
> should be T& for ctor and void for dtor. This makes more sense too because an
> explicit call to a constructor T()

Again, this is *not* a call to the constructor.

> always returns an instance of class T.

The user is not calling any function, therefore there is no "return
value". The user is creating a temporary of a type. The expression
refers to the temporary object.

> I guess, That is the way even smalltalk does for method 'new' by returning
> 'self'.

Don't know about Smalltalk, but we're talking about C++ here. Smalltalk
is a language without static typing. Big difference.

--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

J. Kanze wrote:
>
> Srinivas Vobilisetti <srv@cs.wayne.edu> writes:
>

> > I think if return types are added for ctor/dtor of class T, the return
> > types
> > should be T& for ctor and void for dtor. This makes more sense too
> > because an
> > explicit call to a constructor T() always returns an instance of class
> > T. I
> > guess, That is the way even smalltalk does for method 'new' by returning
> > 'self'.
>
> By this logic, T& would be wrong, too, because an explicit call to a
> constructor is not an lvalue.  The return type would have to be T.
>

If the return type of a constructor is value instead of reference, we
end up calling constructor recursively. So, best bet would be const T&.

Srinivas


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Srinivas Vobilisetti <Srinivas.Vobilisetti@mci.com> writes:

|>  J. Kanze wrote:
|>  >
|>  > Srinivas Vobilisetti <srv@cs.wayne.edu> writes:
|>  >
|>
|>  > > I think if return types are added for ctor/dtor of class T, the return
|>  > > types
|>  > > should be T& for ctor and void for dtor. This makes more sense too
|>  > > because an
|>  > > explicit call to a constructor T() always returns an instance of class
|>  > > T. I
|>  > > guess, That is the way even smalltalk does for method 'new' by returning
|>  > > 'self'.
|>  >
|>  > By this logic, T& would be wrong, too, because an explicit call to a
|>  > constructor is not an lvalue.  The return type would have to be T.
|>  >
|>
|>  If the return type of a constructor is value instead of reference, we
|>  end up calling constructor recursively. So, best bet would be const T&.

Which is also an lvalue, and so doesn't solve the problem I raised.  In
addition, the "return value" of a constructor is NOT const; you can call
non-const functions on an explicit temporary, e.g.: MyType().f().

Frankly, I think that we've pretty much proved that any possible return
type for the constructor would be wrong, which sounds like a very strong
additional argument for not changing the status quo.

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <2.2.32.19961223215221.0030d254@central.beasys.com>,
"David R. Tribble" <david.tribble@central.beasys.com> wrote:

>If this were added to the standard (!), it could be marked as 'optional'
>syntax.  And it really would make parsing C++ declarations and expressions
>simpler.

How can it make parsing easier if it's optional? Wouldn't that rather
make it harder to parse?


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[1]
Why, oh why, can't I declare class constructor and destructor functions
as 'void'?  C++ tells us that a function that doesn't return a value is
a function of void type.  Except for constructors and destructors, which
aren't any type as far as I can tell.  Why?  If it acts, tastes, and smells
like a void function, isn't it a void function?

Seems to me that this is a hole in the syntax of the language.  In fact,
in my experience as a compiler writer, it appears that requiring a return
type on every function declaration would make the compiler's job a little
easier when parsing declarations/expressions.  (I understand that this
is proposed in the ANSI draft - for all functions except constructors
and destructors.)

[2]
Why can't I define a static member variable or function as explicitly
'static'?  On my (HP) compiler I get the message:
    error: static class member declared static

This is silly.  Of course it's static, so why won't C++ let me (re)state
that it's static?  Surely this can be classified as a 'benign' declaration.

I guess I can see the argument that a virtual function should not be
defined as explicitly 'virtual' except in its class declaration, for the
reason that it might be changed into a non-virtual function some day,
forcing me to change the declaration and the definition.  But 'static' is
another story.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>> Why, oh why, can't I declare class constructor and destructor functions
>> as 'void'?  C++ tells us that a function that doesn't return a value is
>> a function of void type.  Except for constructors and destructors, which
>> aren't any type as far as I can tell.  Why?  If it acts, tastes, and smells
>> like a void function, isn't it a void function?
>
>Because they aren't functions, and they don't return anything.
>
>Because they are not really functions.  A constructor is just some
>initialization code that runs when an object is created.  Similarly, a
>destructor is de-initialization code that runs when an object is
>destroyed.  The syntax of their declarations and definitions is
>similar to functions, but they are not true functions.  Note that you
>cannot call them recursively or take their addresses either.

Not 'really' functions?  They are in every linker implementation I've
encountered.  In a program, you have either data (objects) or code
(functions).  To say something is 'just some initialization code'
means it's code.  At a minimum, it's an expression (such as a dynamic
static initializer); otherwise it's a statement block or function.
The details about not being able to take its address, etc., doesn't
enter into it (after all, I can't take the address of register or
bitfield variables, but they're still data variables, and I can't call
::main() explicitly or recursively, but it's still function code).

I said it before, and I'll repeat: It looks like a void function, it works
like a void function, and it damn well returns a value like a void function.
I ought to be able to declare it as 'void' type, and compilers ought to be
smart enough to handle this (they already know it's the ctor/dtor function
from its name).  As it stands, it's a hole in the syntax of the language.
And it's confusing at best, especially to beginners.

If this were added to the standard (!), it could be marked as 'optional'
syntax.  And it really would make parsing C++ declarations and expressions
simpler.

As a minor note, it would also make my language-sensitive editor and
coding style work a little better.  For example, I like to align my
class member declarations so that all the member names, including functions,
line up, so that they're easier to see visually:

    Class SymTable
    {
    public:
                        SymTable();             // Constructor
                        ~SymTable();            // Destructor

        bool            add(const char *name);  // Insert a name
        int             find(const char *name); // Locate a name

    private:
        int             value_;                 // Value
        SearchKey       hash_;                  // Hashed key
    };

The missing return type on the ctor and dtor functions is a glaring
inconsistency.  It also makes it harder to write a grep-like tool that
finds member declarations.
________________________________________________________________________
David R. Tribble                    BEA Systems, Inc.
david.tribble@central.beasys.com    Dallas, TX 75248
http://www.beasys.com               +1-972-738-6125 Office
http://www.flash.net/~dtribble      +1-972-738-6111 Fax
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>> Why can't I define a static member variable or function as explicitly
>> 'static'?  On my (HP) compiler I get the message:
>>     error: static class member declared static
>
>It should be 'error <class static> class member declared <file static>'
>
>The `static' keyword is overloaded in C(++).  The first static means
>that the member is shared among all objects of the class.  The second
>static means that the object has `internal linkage': the identifier
>declared for the member does not refer to the file static object when
>used in any other `compilation unit'.  These two senses are opposed.
>
><file static> says that the definition in that compilation unit is
>not intended by any declaration in any other compilation unit.  This is
>clearly at odds with the notion of something shared by every object of
>some class regardless of what compilation unit defines the object.

Given these two definitions:
        static Type     local = 0;              // [1]
        static Type     Foo::member = 0;        // [2]

The compiler knows the difference between [1] and [2] because the name
of the variables either do or do not have class name prefixes.  The
compiler therefore can know that 'static' in [2] means <class static>
instead of <file static>.  I think compilers are quite capable of this,
and I think it would be less confusing to programmers and maintenance
staff to both declare and define static variables as explicitly 'static'.

Another thing to consider is the definition of static (shared) class
member functions:
        static Type Foo::func(int arg)
        { ... }

The 'static' would serve as an explicit definition that the function has
different semantics, specifically, that it doesn't have a 'this' object.

Obviously, if I change a static member variable to non-static, I have to
change (remove) the variable definition from my source file.  But that's
true of every member variable or function I change in my class anyway.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"David R. Tribble" <david.tribble@central.beasys.com> writes:

    [Concerning constructors and destructors...]
|>  Not 'really' functions?  They are in every linker implementation I've
|>  encountered.  In a program, you have either data (objects) or code
|>  (functions).

Strictly speaking, in a program, all you have is a sequence of bits.  On
most implementations I've seen, you can cast a pointer to function to
char*, and write it to cout.  Some of the bits are considered functions
because of the way you used them, that's all.

>From a hardware (machine instruction) point of view, there *IS* a great
deal of similarity between what the compiler generates for a function,
and what it generates for a constructor.  So?  There is also a great
deal of similarity between what the compiler generates for a pointer,
and what it generates for a reference.  But pointers aren't references.

|>  To say something is 'just some initialization code'
|>  means it's code.  At a minimum, it's an expression (such as a dynamic
|>  static initializer); otherwise it's a statement block or function.

     static MyType       x ;

Supposing MyType has a constructor.  Where is the expression, statement
block or function?  Just because something is "code" doesn't mean that
it is automatically part of a function.  (In the most common
implementation of exception handling, the compiler generates both code
that isn't in a function, and data that isn't a variable.  So what?)

|>  The details about not being able to take its address, etc., doesn't
|>  enter into it (after all, I can't take the address of register or
|>  bitfield variables, but they're still data variables, and I can't call
|>  ::main() explicitly or recursively, but it's still function code).
|>
|>  I said it before, and I'll repeat: It looks like a void function, it works
|>  like a void function, and it damn well returns a value like a void function.

Except, of course, that the constructor is definitly not a void
function, since an expression explicitly calling the constructor
(e.g. "MyType()") does not have type void.

|>  I ought to be able to declare it as 'void' type, and compilers ought to be
|>  smart enough to handle this (they already know it's the ctor/dtor function
|>  from its name).  As it stands, it's a hole in the syntax of the language.
|>  And it's confusing at best, especially to beginners.

If we're worried about confusing beginners, there are a lot of things
we'll have to change.  Perhaps all declarations should start with a
statement of what they are declaring: function, procedure, variable,
constant, etc.  (As Steve Clamage pointed out, this would really make
parsing easier.  As he also said, in what may be the understatement of
the year, it's not likely to happen.)  In this case, I would be very
much in favor of adding the keywords constructor and destructor, to
precede the declarations.

|>  If this were added to the standard (!), it could be marked as 'optional'
|>  syntax.  And it really would make parsing C++ declarations and expressions
|>  simpler.

It could only make parsing simpler if it were required.  In practice,
given the number of other problems in parsing C++, I don't think that it
would make a significant difference.

|>  As a minor note, it would also make my language-sensitive editor and
|>  coding style work a little better.  For example, I like to align my
|>  class member declarations so that all the member names, including functions,
|>  line up, so that they're easier to see visually:

Aha, now we come to the real reason.  I also format like this.  The
extra space before the destructor and constructor used to bother me a
little; with habit, it now seems normal, and I'm bothered when it is not
there (e.g.: virtual before the destructor).  If it really bothers you,
there is nothing to stop you from adding:

    #define ctor
    #define dtor

in a common header, and using them as the "types" of your constructors
and destructors.

|>      Class SymTable
|>      {
|>      public:
|>                          SymTable();             // Constructor
|>                          ~SymTable();            // Destructor
|>
|>          bool            add(const char *name);  // Insert a name
|>          int             find(const char *name); // Locate a name
|>
|>      private:
|>          int             value_;                 // Value
|>          SearchKey       hash_;                  // Hashed key
|>      };
|>
|>  The missing return type on the ctor and dtor functions is a glaring
|>  inconsistency.  It also makes it harder to write a grep-like tool that
|>  finds member declarations.

The inconsistency is in the eyes of the beholder.  As I say, given that
constructors and destructors are special, I've rather come to like the
fact that they are distinguished in some way, and it now bothers me that
in most cases, they are preceded by either explicit or virtual.

With regards to the "grep-like" tool, I don't see how the presence or
absence of a type name can make any real difference, given that the
number of words in the type name part can vary considerably, and will
not necessarily be taken from a small set of keywords.

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R. Tribble wrote:
...
> bitfield variables, but they're still data variables, and I can't call
> ::main() explicitly or recursively, but it's still function code).
...

You can't? I've seen programs in obsfuscated C contests that called
main(), and they worked on my compiler. Is this prohibited by the
proposed C++ standard? Is this a difference from the C standard, or was
my compiler non-conforming?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kuyper <kuyper@wizard.net> writes:

>David R. Tribble wrote:
>...
>> bitfield variables, but they're still data variables, and I can't call
>> ::main() explicitly or recursively, but it's still function code).
>...

>You can't? I've seen programs in obsfuscated C contests that called
>main(), and they worked on my compiler. Is this prohibited by the
>proposed C++ standard? Is this a difference from the C standard, or was
>my compiler non-conforming?

In C, "main" is an ordinary function; you can call it explicitly
and recursively.

C++ has always disallowed calling "main" explicitly or taking its
address. (See the ARM, 1990.)

Regarding the Obfuscated C Contest, conformance to the C standard is
not a requirement, and programs typically do not conform in any event.
---
Steve Clamage, stephen.clamage@eng.sun.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kuyper <kuyper@wizard.net> writes:

|>  David R. Tribble wrote:
|>  ...
|>  > bitfield variables, but they're still data variables, and I can't call
|>  > ::main() explicitly or recursively, but it's still function code).
|>  ...
|>
|>  You can't? I've seen programs in obsfuscated C contests that called
|>  main(), and they worked on my compiler. Is this prohibited by the
|>  proposed C++ standard? Is this a difference from the C standard, or was
|>  my compiler non-conforming?

This is a difference between C and C++.  In C, main is an ordinary
function; the only thing special about it is that the system will call
it on program start-up.  In C++, main is special; in one typical
implementation, for example, the compiler recognizes the function, and
inserts special code to initialize static variables at the beginning of
it.  (Obviously, executing this special code twice is a no-no.)

I think that attempting to call main recursively is undefined behavior,
so your compiler is not required to diagnose it, and it may even work.

It's interesting to note that this difference rarely appears in a list
of differences in the languages.  Of course, the number of C programs
which use this feature (except those in the obfuscated C contest) is
probably very small.

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> "David R. Tribble" <david.tribble@central.beasys.com> writes:

> |>
> |>  I said it before, and I'll repeat: It looks like a void function, it works
> |>  like a void function, and it damn well returns a value like a void function.
>
> Except, of course, that the constructor is definitly not a void
> function, since an expression explicitly calling the constructor
> (e.g. "MyType()") does not have type void.

I think if return types are added for ctor/dtor of class T, the return
types
should be T& for ctor and void for dtor. This makes more sense too
because an
explicit call to a constructor T() always returns an instance of class
T. I
guess, That is the way even smalltalk does for method 'new' by returning
'self'.

Srinivas
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Srinivas Vobilisetti <srv@cs.wayne.edu> writes:

> James Kanze wrote:
> >
> > "David R. Tribble" <david.tribble@central.beasys.com> writes:
>
> > |>
> > |>  I said it before, and I'll repeat: It looks like a void function, it works
> > |>  like a void function, and it damn well returns a value like a void function.
> >
> > Except, of course, that the constructor is definitly not a void
> > function, since an expression explicitly calling the constructor
> > (e.g. "MyType()") does not have type void.
>
> I think if return types are added for ctor/dtor of class T, the return
> types
> should be T& for ctor and void for dtor. This makes more sense too
> because an
> explicit call to a constructor T() always returns an instance of class
> T. I
> guess, That is the way even smalltalk does for method 'new' by returning
> 'self'.

By this logic, T& would be wrong, too, because an explicit call to a
constructor is not an lvalue.  The return type would have to be T.

--
James Kanze         +33 (0)3 88 14 49 00         email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]