Alaa The Great wrote:
>
> On Sun, 15 Sep 2002 18:08:53 +0300, James Russell Kuyper Jr. wrote:
>
> > Alaa The Great wrote:
> > ....
> >> do you know of a single language feature that is there to reduce the
> >> amount of typing needed??
> >
> > +=, --, ?:, macros, references, typedef, namespace aliases, while(){} or
> > do{}while() loops (you can always use if() and goto), switch (can always
> > be replaced with if()s). Default arguments. That's just the ones that
> > came to me first; there's lots more.
>
> all of these except default arguments, references and namepace aliases are
> part of the C language my question was about adding features to the
> language C++ laways had the goal of C compatibility.

I was just responding to the question that you actually wrote. I leave
mind reading to other people.

> and between the three C++ features you mention the only feature which is
> there to save typing only is default arguments apparently default
> arguments where part of the language before function overloading and had
> a greater use back then.

A reference is basically something with the semantics of a const pointer
and (almost) the same syntax as an actual object of the pointed-at type.
As such, references do almost nothing that const pointers couldn't do
except cut down on typing.

That's almost equally true of namespace aliases. Basically, if there's
only one possible definition of an alias, you can replace all occurances
of the alias with copies of the definition, so it basically serves to
"save typeing".

> I can't see how the feature proposed can be compared to references which
> represent a general concept (call by reference as opposed to call by
> value).

Pointers represent call by reference, references simply do a more
convenient job of it: they save typing.

> and don't get me started in the C features for instance ? evaluates to an
> expression thats why you can use it in initialization and return
> statements, this is not mere shortcuts.

You can always re-write the code to use if()'s no matter where the ?:
goes. The rewrite is often quite messy, which is how ?: saves typing,
but that's the only thing it really does.

Note: saving on typing often corresponds to making things clearer.
That's mainly  because the less you have to type, the less you have to
parse. So "saving typing" is not a trivial advantage. Of course, ?: is a
bad example of that, because as the only trinary operator in the
language, it's often hard to understand.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 15 Sep 2002 18:08:53 +0300, James Russell Kuyper Jr. wrote:

> Alaa The Great wrote:
> ....
>> do you know of a single language feature that is there to reduce the
>> amount of typing needed??
>
> +=, --, ?:, macros, references, typedef, namespace aliases, while(){} or
> do{}while() loops (you can always use if() and goto), switch (can always
> be replaced with if()s). Default arguments. That's just the ones that
> came to me first; there's lots more.

all of these except default arguments, references and namepace aliases are
part of the C language my question was about adding features to the
language C++ laways had the goal of C compatibility.

and between the three C++ features you mention the only feature which is
there to save typing only is default arguments apparently default
arguments where part of the language before function overloading and had
a greater use back then.

in The Design and Evolution of C++ Stroustrup states:
"Given general function overloading, default arguments are logically
redundant and at best a minor notational convenience. However, C with
Classes had default argument lists for years before general overloading
became available in C++"

I can't see how the feature proposed can be compared to references which
represent a general concept (call by reference as opposed to call by
value).

and don't get me started in the C features for instance ? evaluates to an
expression thats why you can use it in initialization and return
statements, this is not mere shortcuts.

cheers,
Alaa

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
>
> In article <3D7F2F1F.FB76A441@wizard.net>, James Russell Kuyper Jr.
> <kuyper@wizard.net> writes
> >Ken Alverson wrote:
> >....
> >> The point of my example was not to show the necessity of the this()
> >> syntax, but rather to show the inadequacy of default parameters as a
> >> substitute, which your counter example has not refuted.
> >
> >OK. So, could you please provide an example to show the necessity of the
> >this() syntax?
>
> I can remember an old style computer science type exam question. A
> theoretical assembler instruction set was defined. The candidate was
> then asked to show how one of the instructions could be replaced by
> using a combination from the rest.
>
> When you get down to fundamentals I think you can manage with a single
> not-and instruction but whop would want to?

Sorry - "necessity" was an overstatement. I used the word only because I
was trying to mimic the wording of the message I was responding to. If I
hadn't been doing that, I would have said something more like:

"Could you please provide an example to show why the this() syntax is
valuable enough to justify changing the standard?"

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I see you are thinking of something like
class Foo
{
    int position;
    FILE *f;
public:
    Foo(FILE *f) : f(f) { do_something_to_f(); }
    Foo(const char *n) : f(fopen(n)) { do_something_to_f(); }
private:
    void do_something_to_f() { position = -1;}
};
but how about


class Foo
{
    const int unpositioned;
    int position;
    FILE *f;
public:
    Foo(FILE *f) : f(f) { do_something_to_f(); }
    Foo(const char *n) : f(fopen(n)) { do_something_to_f(); }
private:
    void do_something_to_f() { unpositioned = -1;position = unpositioned;}
};

Adding my $2 to this, I would like to see it handled
class Foo
{
    const int unpositioned = -1;
    int position = unpositioned;
    FILE *f;
public:
    Foo(FILE *f) : f(f) {}
    Foo(const char *n) : f(fopen(n)) {}
};

I frequently need to convert code written as a stand alone such as
    const int unpositioned = -1;
    int position = unpositioned;
    FILE *f;
void Foo(const char *n);
int main(void)
{
   Foo("x.txt");
   return 0;
};

into a library function where Foo may be called many times.  The conversion
would
be so much easier if I could just put
  class X {
   public:
in front of the first declaration,
  };
after the last declaration.  Add X:: to the actual function.
Then change main to

int function(void)
{
   X x;
   x.Foo("x.txt");
   return 0;
};

In this case, there isn't much typing.  But there could be a whole lot of
'em.  I can often put
them in an initialization function but not if there are a bunch of const
values sprinkled in.

Greg Brewer


""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:unufd2qi5bud0e@corp.supernews.com...
   < snip >
> class Foo
> {
>     FILE *f;
> public:
>     Foo(FILE *f) : f(f) { do_something_to_f(); }
>     Foo(const char *n) : f(fopen(n)) { do_something_to_f(); }
> private:
>     void do_something_to_f() { /* common operation on f */ }
> };
   < snip >
> Victor
> --
> Please remove capital A's from my address when replying by mail
>
>
> ---
> [ 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    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Greg Brewer" <nospam.greg@brewer.net> wrote...
> [...] how about
>
> class Foo
> {
>     const int unpositioned;
>     int position;

Shouldn't those be 'long'?  Never mind...

>     FILE *f;
> public:
>     Foo(FILE *f) : f(f) { do_something_to_f(); }
>     Foo(const char *n) : f(fopen(n)) { do_something_to_f(); }
> private:
>     void do_something_to_f() { unpositioned = -1;position = unpositioned;}
> };

The class above doesn't seem to need the 'unpositioned' except
for initialising the 'position' member.  So, why not just use
-1 for that?  If you don't like hard-coded constants, you could
actually declare (and defined) a static constant for that:

class Foo
{
    static const int unpositioned = -1;
    ...

>
> Adding my $2 to this, I would like to see it handled
> class Foo
> {
>     const int unpositioned = -1;

Why is it not 'static'?  Is there a particular reason to waste
sizeof(int) of bytes per object?

>     int position = unpositioned;
>     FILE *f;
> public:
>     Foo(FILE *f) : f(f) {}
>     Foo(const char *n) : f(fopen(n)) {}
> };
> [...]

Again, your argument doesn't hold under close scrutiny.  However,
I do agree that a method with a separate function is _not_ at all
suitable for initialising non-static consts and references.  In
that light it becomes apparent that such syntax could be useful.

My point is that in many cases the functionality is already there
or the design is not very well thought through, and that's why I
kept showing how it could be done using existing mechanisms.  Have
you heard of somebody who'd say "I discovered that C++ doesn't
provide this nice feature, well, too bad, I'll have to switch to
Java now"?  I haven't.  Of course, it doesn't mean that we can't
improve the language...

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:uo23i5j0e0qef1@corp.supernews.com...
>
> Again, your argument doesn't hold under close scrutiny.  However,
> I do agree that a method with a separate function is _not_ at all
> suitable for initialising non-static consts and references.  In
> that light it becomes apparent that such syntax could be useful.

I've thought of another example where it would be useful:

class X : A,B,C,D,E,F,G {
  X() : A(1), B(2), C(3), D(4), E(5), F(6), G(7) {}
public:
  X(const Foo& foo): this() {/* do something with foo */}
  X(const Bar& bar): this() {/* do something with bar */}
};

Ken


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

First, it's just an example I constructed from examples given by other
people.
Second,
  I might not use a static because I am passing a pointer to the class into
a .dll.
  Or I might want to define the class completely within the header file.
I was really just agreeing with the original poster, giving an example where
an initializer member function would not work as suggested.

And I was trying to add on to the suggestion with something I would find
helpful.  Plus, there are times when I would really rather not have to type
the name multiple times (or use copy/paste).  Take for example
class X
{
   int whateveryouwanttocallthis, i;
public:
   X(int w) : whateveryouwanttocallthis(0), i(w) {}
   X(void) : whateveryouwanttocallthis(0), i(0) {}
};
This is less desirable than
class X
{
   int whateveryouwanttocallthis, i;
public:
   X(int w) : whateveryouwanttocallthis(0), i(w) {}
   X(void) : X(0) {}
};
or even
class X
{
   int whateveryouwanttocallthis, i;
   void Set(void) {whateveryouwanttocallthis=0;}
public:
   X(int w) : i(w) {Set();}
   X(void) : i(0) {Set();}
};
And that is less desirable than
class X
{
   int whateveryouwanttocallthis=0, i;
public:
   X(int w) : i(w) {}
   X(void) : i(0) {}
};
because I only have to type whateveryouwanttocallthis once.

class X
{
   int whateveryouwanttocallthis=0, i;
public:
   X(int w) : i(w) {}
   X(void) : i(0) {}
};

But then, I think it is a trivial argument.  However, I want my work to be
as simple as simple as possible and I do think it is more legible when the
declaration and the value are in close proximity like this.

Greg

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:uo23i5j0e0qef1@corp.supernews.com...
> "Greg Brewer" <nospam.greg@brewer.net> wrote...
> > [...] how about
> >
> > class Foo
> > {
> >     const int unpositioned;
> >     int position;
>
> Shouldn't those be 'long'?  Never mind...
>
> >     FILE *f;
> > public:
> >     Foo(FILE *f) : f(f) { do_something_to_f(); }
> >     Foo(const char *n) : f(fopen(n)) { do_something_to_f(); }
> > private:
> >     void do_something_to_f() { unpositioned = -1;position =
unpositioned;}
> > };
>
> The class above doesn't seem to need the 'unpositioned' except
> for initialising the 'position' member.  So, why not just use
> -1 for that?  If you don't like hard-coded constants, you could
> actually declare (and defined) a static constant for that:
>
> class Foo
> {
>     static const int unpositioned = -1;
>     ...
>
> >
> > Adding my $2 to this, I would like to see it handled
> > class Foo
> > {
> >     const int unpositioned = -1;
>
> Why is it not 'static'?  Is there a particular reason to waste
> sizeof(int) of bytes per object?
>
> >     int position = unpositioned;
> >     FILE *f;
> > public:
> >     Foo(FILE *f) : f(f) {}
> >     Foo(const char *n) : f(fopen(n)) {}
> > };
> > [...]
>
> Again, your argument doesn't hold under close scrutiny.  However,
> I do agree that a method with a separate function is _not_ at all
> suitable for initialising non-static consts and references.  In
> that light it becomes apparent that such syntax could be useful.
>
> My point is that in many cases the functionality is already there
> or the design is not very well thought through, and that's why I
> kept showing how it could be done using existing mechanisms.  Have
> you heard of somebody who'd say "I discovered that C++ doesn't
> provide this nice feature, well, too bad, I'll have to switch to
> Java now"?  I haven't.  Of course, it doesn't mean that we can't
> improve the language...
>
> Victor
> --
> Please remove capital A's from my address when replying by mail
>
>
> ---
> [ 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    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:unq116d76ii6f7@corp.supernews.com...
> >
> > You can call a constructor of the same class with the this keyword.
I
> > this is a convenient feature, because it saves you from writing an
extra
> > function or two that all constructors can call. It's possible to use
the
> > member initializer list syntax for C++ (I think), or the "this
syntax" of
> > course
> >
>
> Every time such request is voiced I see a very compelling case
> against it:
>
>     class Foo
>     {
>         int m_x;
>     public:
>         Foo(int x = 0) : m_x(x) {}
>     };
>
> If you can present a better use for that [missing] feature,
> maybe somebody would consider it...

Consider any case where we currently use overloads that are
inappropriate for default values.  A contrived example:

class Foo {
  FILE* f;
public:
  Foo(FILE* f) : f(f) {}
  Foo(const char* filename) : this(fopen(filename)) {}
};

Ken


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ken Alverson" <Ken@Alverson.net> wrote...
> ""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
> news:unq116d76ii6f7@corp.supernews.com...
> > >
> > > You can call a constructor of the same class with the this keyword.
> I
> > > this is a convenient feature, because it saves you from writing an
> extra
> > > function or two that all constructors can call. It's possible to use
> the
> > > member initializer list syntax for C++ (I think), or the "this
> syntax" of
> > > course
> > >
> >
> > Every time such request is voiced I see a very compelling case
> > against it:
> >
> >     class Foo
> >     {
> >         int m_x;
> >     public:
> >         Foo(int x = 0) : m_x(x) {}
> >     };
> >
> > If you can present a better use for that [missing] feature,
> > maybe somebody would consider it...
>
> Consider any case where we currently use overloads that are
> inappropriate for default values.  A contrived example:
>
> class Foo {
>   FILE* f;
> public:
>   Foo(FILE* f) : f(f) {}
>   Foo(const char* filename) : this(fopen(filename)) {}
> };


OK, I'll play.

Here is your class refactored to fit the current C++ syntax:

class Foo {
   FILE* f;
public:
   Foo(FILE* f) : f(f) {}
   Foo(const char* filename) : f(fopen(filename)) {}
};

Was it too difficult?

Why can't we get out of contrived examples?  Can you give one
that _really_ shows the advantage the proposed syntax would
offer?

Holding my breath,

Victor
--
Please remove capital A's from my address when replying by mail

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:VVyf9.225627$kp.819945@rwcrnsc52.ops.asp.att.net...
> "Ken Alverson" <Ken@Alverson.net> wrote...
> > >
> > > If you can present a better use for that [missing] feature,
> > > maybe somebody would consider it...
> >
> > Consider any case where we currently use overloads that are
> > inappropriate for default values.  A contrived example:
> >
> > class Foo {
> >   FILE* f;
> > public:
> >   Foo(FILE* f) : f(f) {}
> >   Foo(const char* filename) : this(fopen(filename)) {}
> > };
>
>
> OK, I'll play.
>
> Here is your class refactored to fit the current C++ syntax:
>
> class Foo {
>    FILE* f;
> public:
>    Foo(FILE* f) : f(f) {}
>    Foo(const char* filename) : f(fopen(filename)) {}
> };
>
> Was it too difficult?
>
> Why can't we get out of contrived examples?  Can you give one
> that _really_ shows the advantage the proposed syntax would
> offer?

The point of my example was not to show the necessity of the this()
syntax, but rather to show the inadequacy of default parameters as a
substitute, which your counter example has not refuted.

In a slightly less contrived example, Foo(FILE*) would actually do
something to the file rather than just store it in a member variable.
Foo(const char*) would obviously want to cascade to that behavior once
the FILE* is obtained.

Ken


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Alverson wrote:
....
> The point of my example was not to show the necessity of the this()
> syntax, but rather to show the inadequacy of default parameters as a
> substitute, which your counter example has not refuted.

OK. So, could you please provide an example to show the necessity of the
this() syntax?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Now go and check a few million lines of code to see how often several
> data members of a class have the same type (which causes problems for
> this mechanism as a complete technique) Versus how often it would have
> been nice to default some parameter in a ctor that comes before one that
> you need to provide a non-default value to)  The mechanism is simple,
> easy to understand and is a logical extension of base class
> initialisers.

Francis, are there any proposals to have arrays intialised in the intialiser
list? Obviously not every element with something different but where the
same value can be applied for all members. It is just that I don't see why I
should have to use a vector for a 3 element array.

Currently I initialise array members in the body of a constructor as there
is no alternative.

Stephen Howe




---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 11 Sep 2002 02:12:30 +0200, Francis Glassborow wrote:

> In article <unq116d76ii6f7@corp.supernews.com>, Victor Bazarov
> <vAbazarov@dAnai.com> writes
>>If you can present a better use for that [missing] feature, maybe
>>somebody would consider it...
>
> It is already under consideration. Actually I think we need a better
> argument for not making this change as part of a general tidy up.
> Personally I would deprecate default parameters.

I like the extension proposed, but I don't like to see default parameters
to be deprecated. It depends on what you are doing which is better and
sometimes, default parameters are just cleaner and easier (IMHO).
Overloads could replace them, but sometimes they are a pain just because
of their number. Why not let the user decide? This in IMHO the C++ way,
just allow things, don't force them... my 2c.

Regards, Daniel

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Hmm, my example was even more stupid for java, because all members are
> initialized to zero automatically.

Which is a performance loss if the class members are supposed to be non-zero
to start with.

Stephen Howe


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ken Alverson" <Ken@Alverson.net> wrote...
> ""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
> news:VVyf9.225627$kp.819945@rwcrnsc52.ops.asp.att.net...
> > "Ken Alverson" <Ken@Alverson.net> wrote...
> > > >
> > > > If you can present a better use for that [missing] feature,
> > > > maybe somebody would consider it...
> > >
> > > Consider any case where we currently use overloads that are
> > > inappropriate for default values.  A contrived example:
> > >
> > > class Foo {
> > >   FILE* f;
> > > public:
> > >   Foo(FILE* f) : f(f) {}
> > >   Foo(const char* filename) : this(fopen(filename)) {}
> > > };
> >
> >
> > OK, I'll play.
> >
> > Here is your class refactored to fit the current C++ syntax:
> >
> > class Foo {
> >    FILE* f;
> > public:
> >    Foo(FILE* f) : f(f) {}
> >    Foo(const char* filename) : f(fopen(filename)) {}
> > };
> >
> > Was it too difficult?
> >
> > Why can't we get out of contrived examples?  Can you give one
> > that _really_ shows the advantage the proposed syntax would
> > offer?
>
> The point of my example was not to show the necessity of the this()
> syntax, but rather to show the inadequacy of default parameters as a
> substitute, which your counter example has not refuted.

I see.

> In a slightly less contrived example, Foo(FILE*) would actually do
> something to the file rather than just store it in a member variable.
> Foo(const char*) would obviously want to cascade to that behavior once
> the FILE* is obtained.

Do something in the body of the constructor, you mean?  So,
introduction of a separate function (have we forgotten the
rules of procedural programming: if some code is used more
than once, make it a separate function and call it?) is
completely out of the question?  This is what keeps those
suggestion bouncing off:

class Foo
{
    FILE *f;
public:
    Foo(FILE *f) : f(f) { do_something_to_f(); }
    Foo(const char *n) : f(fopen(n)) { do_something_to_f(); }
private:
    void do_something_to_f() { /* common operation on f */ }
};

Give _enough_ ground to prefer having all the code in one c-tor
and introduce another c-tor instead of having the common code in
a separate function.  So far no _real_ reason has been given, I
guess, and that's why that syntax is still considered unneeded.

Besides, the common function is useful if our design calls for
some kind of "reset" functionality.  That's the point _against_
preferring the code in a c-tor to a separate function.

There is probably a difference between "easy to use" and "useful"
when applied to a programming language.  Too many syntactic sugar
type of features make the language bulky, and compilers from it
complicated.  We already have something that is quite far from
its predecessor's ideals of minimalism.  Why make the situation
more severe?

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""James Russell Kuyper Jr."" <kuyper@wizard.net> wrote in message
news:3D7F2F1F.FB76A441@wizard.net...
> Ken Alverson wrote:
> ....
> > The point of my example was not to show the necessity of the this()
> > syntax, but rather to show the inadequacy of default parameters as a
> > substitute, which your counter example has not refuted.
>
> OK. So, could you please provide an example to show the necessity of
the
> this() syntax?

Actually, I am ambivalent on the issue - I wasn't arguing for the this()
syntax, even though I was arguing that default arguments are not a valid
substitute.

That said, the best example I can think of would be one in which the
alternate constructors cascade to a constructor that initializes several
reference members.  Such logic cannot be moved to an alternate routine,
since that routine cannot change the reference targets, and duplicating
the reference initialization to each alternate constructor creates the
possibility of them falling out of sync.

Ken


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Stephen Howe" <SPAMstephen.howeGUARD@tnsofres.com> wrote...
> > Now go and check a few million lines of code to see how often several
> > data members of a class have the same type (which causes problems for
> > this mechanism as a complete technique) Versus how often it would have
> > been nice to default some parameter in a ctor that comes before one that
> > you need to provide a non-default value to)  The mechanism is simple,
> > easy to understand and is a logical extension of base class
> > initialisers.
>
> Francis, are there any proposals to have arrays intialised in the
intialiser
> list? Obviously not every element with something different but where the
> same value can be applied for all members. It is just that I don't see why
I
> should have to use a vector for a 3 element array.
>
> Currently I initialise array members in the body of a constructor as there
> is no alternative.


I also think that it might help, but to be consistent we should
then allow to initialise any aggregate (or POD) in the initialiser
list:

    struct XY { int x, y; };

    class Foo {
        XY xy;
    public:
        Foo() : xy( { 1, 2 } ) {}
    //              ^^^^^^^^  Whatever syntax we decide to adopt.
    };

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D7F2F1F.FB76A441@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>Ken Alverson wrote:
>....
>> The point of my example was not to show the necessity of the this()
>> syntax, but rather to show the inadequacy of default parameters as a
>> substitute, which your counter example has not refuted.
>
>OK. So, could you please provide an example to show the necessity of the
>this() syntax?

I can remember an old style computer science type exam question. A
theoretical assembler instruction set was defined. The candidate was
then asked to show how one of the instructions could be replaced by
using a combination from the rest.

When you get down to fundamentals I think you can manage with a single
not-and instruction but whop would want to?



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:VVyf9.225627$kp.819945@rwcrnsc52.ops.asp.att.net...
> Here is your class refactored to fit the current C++ syntax:
>
> class Foo {
>    FILE* f;
> public:
>    Foo(FILE* f) : f(f) {}
>    Foo(const char* filename) : f(fopen(filename)) {}
> };
>
> Was it too difficult?

It's not about if it's difficult to repeat code, it's about referencing the
same identifier needlessly

Suppose you want to have temporary files for the default constructor
Also, you want to remember how the file was opened with a string and Foo
inherits from a Data class. The members of the data class will have to start
at zero. it would look like:

class Data
{
    int x, y, z;
public: Data() : x(0), y(0), z(0) {}
};

class Foo : public Data {
   FILE* f;
   string how;
 public:
    Foo(FILE* f, string &how) : Data(), f(f), how(how) {}
    Foo() : Data(), f(tmpfile()), how("w+b") {}
    Foo(const char* filename, string &how) : Data(), f(fopen(filename,
how.c_str())), how(how) {}
};

Compare this too:

class Foo : public Data {
   FILE* f;
   string how;
 public:
    Foo(FILE* f, string &how) : Data(), f(f), how(how) {}
    Foo() : this(tmpfile(), "w+b") {}
    Foo(const char* filename, string &how) : this(fopen(filename,
how.c_str()), how) {}
};

It looks cleaner, code is easier maintained and the language is more
orthogonal. What more can you wish for.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <VVyf9.225627$kp.819945@rwcrnsc52.ops.asp.att.net>, Victor
Bazarov <vAbazarov@dAnai.com> writes
>OK, I'll play.
>
>Here is your class refactored to fit the current C++ syntax:
>
>class Foo {
>   FILE* f;
>public:
>   Foo(FILE* f) : f(f) {}
>   Foo(const char* filename) : f(fopen(filename)) {}
>};
>
>Was it too difficult?

Now make that body non-empty. Oh yes, you can then refactor and have an
initialisation function that is called from the body but we are
beginning to loose that simplicity.

>
>Why can't we get out of contrived examples?  Can you give one
>that _really_ shows the advantage the proposed syntax would
>offer?

Clarity and consistency. Of course the advantages are not very large but
the cost is minuscule. There is the cost of having to explain the method
to every programmer who started out with Java (and increasingly large
number) who will then look in amazement and say why can't...? The good
ones will even come up with the proposed syntax and go away shaking
their heads in amazement at how silly C++ can be. It matters not whether
that is true, perceptions are everything here.
I think you have it the wrong way round, what is the problem with the
proposal? What is the cost? Note it is a pure extension.

As always we need to look at cost benefit. having said that, the costs
of continuing this dialogue, for me, have now exceeded any conceivable
benefit.
>
>Holding my breath,

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3d7f423a$0$8508$ed9e5944@reading.news.pipex.net>, Stephen
Howe <SPAMstephen.howeGUARD@tnsofres.com> writes
>Francis, are there any proposals to have arrays intialised in the intialiser
>list? Obviously not every element with something different but where the
>same value can be applied for all members. It is just that I don't see why I
>should have to use a vector for a 3 element array.

Not at the moment, but if there were, why would it not include a list of
values? If we went to the trouble to go part way we might as well get
full value. The question which implementors would have to address is
what the cost would be.
>
>Currently I initialise array members in the body of a constructor as there
>is no alternative.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 13 Sep 2002 23:14:13 +0300, Greg Brewer wrote:



> And I was trying to add on to the suggestion with something I would find
> helpful.  Plus, there are times when I would really rather not have to
> type the name multiple times (or use copy/paste).

do you know of a single language feature that is there to reduce the
amount of typing needed??

you propose a change to the C++ syntax just so you could save some
keystrokes or mouse clicks??!

I don't think this makes anysense, I agree with Victor,show us an exapmle
where this is needed, where no other solution exist or the solution is
inefficient or very ugly and non trivial.

cheers,
Alaa

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alaa The Great wrote:
....
> do you know of a single language feature that is there to reduce the
> amount of typing needed??

+=, --, ?:, macros, references, typedef, namespace aliases, while(){} or
do{}while() loops (you can always use if() and goto), switch (can always
be replaced with if()s). Default arguments. That's just the ones that
came to me first; there's lots more.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Alaa The Great" <alaa@annosoor.org> wrote in message
news:alv40a$11lfp$1@ID-148116.news.dfncis.de...
> On Fri, 13 Sep 2002 23:14:13 +0300, Greg Brewer wrote:
> do you know of a single language feature that is there to reduce the
> amount of typing needed??
>
> you propose a change to the C++ syntax just so you could save some
> keystrokes or mouse clicks??!
>
> I don't think this makes anysense, I agree with Victor,show us an exapmle
> where this is needed, where no other solution exist or the solution is

I can think of quite a few but that is just a side benefit.  The primary
benefits would be clarity (the declaration and the initial value in the same
spot), maintainability (oops, when he changed the initial value from
onevalue to another, he missed a ctor), and brevity (here is a bunch of
variable declarations and the initial value for those variables).

I don't see how you can say this does not make anysense; I would posit that
the current mechanism is the one that makes little sense.  If it had
original been set up as I suggest, I can't imagine anyone proposing adding
the current mechanism or the proposal being well received.

Greg


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Serve Lau"" <circe2@home.nl> wrote...
> In java you can do this (watch the default constructor):
>
> class Foo
> {
>     public Foo()
>     {
>         this(0);
>     }
>     public Foo(int x)
>     {
>         m_x = x;
>     }
>     int m_x;
> }
>
> You can call a constructor of the same class with the this keyword. I
think
> this is a convenient feature, because it saves you from writing an extra
> function or two that all constructors can call. It's possible to use the
> member initializer list syntax for C++ (I think), or the "this syntax" of
> course
>
> class Foo
> {
>    public: Foo() : Foo(0) {}
>    public: Foo(int x) { m_x = x; }
>
>    int m_x;
> };
>
> Would there be any chance of putting this in the next standard?


Every time such request is voiced I see a very compelling case
against it:

    class Foo
    {
        int m_x;
    public:
        Foo(int x = 0) : m_x(x) {}
    };

If you can present a better use for that [missing] feature,
maybe somebody would consider it...

BTW, Java doesn't have intialiser lists.  I strongly recommend
to learn to use them in C++.

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:unq116d76ii6f7@corp.supernews.com...
>     class Foo
>     {
>         int m_x;
>     public:
>         Foo(int x = 0) : m_x(x) {}
>     };
>
> If you can present a better use for that [missing] feature,
> maybe somebody would consider it...
>
> BTW, Java doesn't have intialiser lists.  I strongly recommend
> to learn to use them in C++.

Hmm, my example was even more stupid for java, because all members are
initialized to zero automatically.
I thought it doesn't take much common sense to see how it can improve code
maintainability, but I'll try with another abstract example that
*theoretically* shows the problem.

Suppose you have a class Foo with 2 constructors that fill pointers. But,
because they're pointers they do not have to be used right away at object
creation time, so you want to initialize to zero. Notice that the two
constructors both have an initializer list, if anything has to change for
the member variables you will have to change multiple places in the source,
and it's very easy to forget one having to recompile again, going back to
the other source file etc. It can be very cumbersome, especially with more
constructors and more members. What I see a lot is that people write a
Clear() member that you call from every constructor so that you have the
initializations all in one place. But then you're needlessly creating a
function you have already written before (a constructor).

class Foo {
public:

Foo(int *x, int *y) : x(x), y(y) {}

Foo(int *x) : x(x), y(0) {}

private:

int *x;

int *y;

};



Oh well, maybe it's too practical to be good :-)

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Serve Lau" <ok@dan.nl> wrote...
>
> ""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
> news:unq116d76ii6f7@corp.supernews.com...
> >     class Foo
> >     {
> >         int m_x;
> >     public:
> >         Foo(int x = 0) : m_x(x) {}
> >     };
> >
> > If you can present a better use for that [missing] feature,
> > maybe somebody would consider it...
> >
> > BTW, Java doesn't have intialiser lists.  I strongly recommend
> > to learn to use them in C++.
>
> Hmm, my example was even more stupid for java, because all members are
> initialized to zero automatically.
> I thought it doesn't take much common sense to see how it can improve code
> maintainability, but I'll try with another abstract example that
> *theoretically* shows the problem.

The problem?

> Suppose you have a class Foo with 2 constructors that fill pointers. But,
> because they're pointers they do not have to be used right away at object
> creation time, so you want to initialize to zero. Notice that the two
> constructors both have an initializer list, if anything has to change for
> the member variables you will have to change multiple places in the
source,
> and it's very easy to forget one having to recompile again, going back to
> the other source file etc. It can be very cumbersome, especially with more
> constructors and more members. What I see a lot is that people write a
> Clear() member that you call from every constructor so that you have the
> initializations all in one place. But then you're needlessly creating a
> function you have already written before (a constructor).
>
> class Foo {
> public:
>
> Foo(int *x, int *y) : x(x), y(y) {}
>
> Foo(int *x) : x(x), y(0) {}
>
> private:
>
> int *x;
>
> int *y;
>
> };

So, after proper refactoring your code should be

    class Foo {
    public:
        Foo(int *x, int *y = 0) : x(x), y(y) {}
    private:
        int *x, *y;
    };

Is it not an acceptable solution?  Is that what you're saying?
I don't see any advantage to allow to write

    class Foo {
    public:
        Foo(int *x, int *y) : x(x), y(y) {}
        Foo(int *x) : this(x, 0) {}    // proposed syntax
    private:
        int *x, *y;
    };

Do you?  Please compare the two variations _I_ presented and
tell me what is the advantage of the second over the first.

> Oh well, maybe it's too practical to be good :-)

Right :-)

Victor
--
Please remove capital A's from my address when replying by mail


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <unso8d2mja397d@corp.supernews.com>, Victor Bazarov
<vAbazarov@dAnai.com> writes
>Is it not an acceptable solution?  Is that what you're saying?
>I don't see any advantage to allow to write
>
>    class Foo {
>    public:
>        Foo(int *x, int *y) : x(x), y(y) {}
>        Foo(int *x) : this(x, 0) {}    // proposed syntax
>    private:
>        int *x, *y;
>    };


So let me change the example a little:

struct Bar {
  int * iptr;
  short* sptr;
  Bar(int* ip, short* sp):iptr(ip), sptr(sp){/* whatever */}
  Bar(int* ip):Bar(ip, 0) {}
  Bar(short* sp):Bar(0,sp){}
  Bar():Bar(0, 0){}
}

Now go and check a few million lines of code to see how often several
data members of a class have the same type (which causes problems for
this mechanism as a complete technique) Versus how often it would have
been nice to default some parameter in a ctor that comes before one that
you need to provide a non-default value to)  The mechanism is simple,
easy to understand and is a logical extension of base class
initialisers.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <unq116d76ii6f7@corp.supernews.com>, Victor Bazarov
<vAbazarov@dAnai.com> writes
>Every time such request is voiced I see a very compelling case
>against it:

How is that a compelling case. Default parameters are problematical for
several reasons but one of the main ones is that only the right hand
parameters can have default arguments.
>
>    class Foo
>    {
>        int m_x;
>    public:
>        Foo(int x = 0) : m_x(x) {}

This is clearly an error (and an easily diagnosed one as it is
infinitely recursive.
However a formulation such as:
   Foo(int x): m_x(x){}
   Foo() : Foo(0){}
is clearly implementable and makes perfectly good sense.
>    };
>
>If you can present a better use for that [missing] feature,
>maybe somebody would consider it...

It is already under consideration. Actually I think we need a better
argument for not making this change as part of a general tidy up.
Personally I would deprecate default parameters.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In java you can do this (watch the default constructor):

class Foo
{
    public Foo()
    {
        this(0);
    }
    public Foo(int x)
    {
        m_x = x;
    }
    int m_x;
}

You can call a constructor of the same class with the this keyword. I think
this is a convenient feature, because it saves you from writing an extra
function or two that all constructors can call. It's possible to use the
member initializer list syntax for C++ (I think), or the "this syntax" of
course

class Foo
{
   public: Foo() : Foo(0) {}
   public: Foo(int x) { m_x = x; }

   int m_x;
};

Would there be any chance of putting this in the next standard?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]