Alain Miniussi wrote in message <381B0206.8920F18B@sophia.cnrs.fr>...
>Valentin Bonnard wrote:

...
>I did not follow the thread, but I think you're refereing to
>3.4.3/3. (but the given exemple is a static array).


Thank you Alain-san, I am now convinced.

------
Tsutomu Yoshida
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hallo !

There are some other reasons not to use such constructs: "class B : private
class A { /* implementation of A*/ }" :

1) you can use ONLY inline functions (in most cases you don't want to (but if
the compiler decides which function should be inline this is ok (in this case
you don't need the keyword inline) ) ).

2) you must rewrite all public:/protected:/privte: keywords (this may be
buggy)

3) perhaps you must redefine some typedefs

4) Logic error: You don't implement class A, you implement class B.

Bye,

 Witold Kaminski.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Christopher Eltschka wrote:
>
> > Without implementing, every single member function
> > definition must be modified.
>
> Use macros ?

#define FOO_FULL Foo<T1, T2>
#define FOO_MEMBER_DEF(before) \
 template<class T1, class T2> before FOO_FULL::

FOO_MEMBER_DEF(FOO_FULL&) operator=(Foo const& other)
{
  ...
}

FOO_MEMBER_DEF(template<class U1, class U2> FOO_FULL&)
 operator=(Foo<U1, U2> const& other) // is this readable?
{
  ...
}

FOO_MEMBER_DEF() Foo(Foo const&) // is this allowed?
{
  ...
}

#define FOO_STRUCTOR_DEF template<class T1, class T2> FOO_FULL::

FOO_STRUCTOR_DEF Foo() // or do we need this?
{
  ...
}

Do you really see this as good solution?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> T.Yoshida wrote:
>
> > Valentin Bonnard wrote in message <3816CE9F.6B4D@wanadoo.fr>...
> >
> > >You mention the advantage of not having to qualify
> > >names with the class name, which may be quite long
> > >since all template arguments are needed. Actually, you
> > >overstate the need for qualification: function arguments
> > >need not be qualified, only the return type needs to.
> >
> > Is that really so?
>
> Yes, I am sure (no, I don't know the section number).

I did not follow the thread, but I think you're refereing to
3.4.3/3. (but the given exemple is a static array).

Alain
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gene Bushuyev wrote:
>
> Witold Kaminski, Student <kaminski@apfel.de> wrote in message
> news:38156292.E73A3ECE@apfel.de...
> >
> > I suggest to extend the c++ language with the keyword "implementing".
> >
>
> I actually think it's a bad idea.

I disagree.

> When you have big implementation files and
> more than one class, that is often the case in the real world, it's very
> important to see the full function name, including the class(es) name(s).

In my experience, this is not a general case in the real world. I guess
we have been to two different real worlds :-)

I prefer to put implementations of different classes into different
files.

Note that you don't have to use the proposed "implementing" feature if
it is supported in the future. You can still continue using the current
way if you find that you provide implementations of many classes in a
single file.

> Your desire is to avoid typing the full qualified names and everybody who
> worked with large projects knows that typing of the code per se is very
> insignificant part of the project.

It is still a significant part of the coding effort. It is also a type
of manual labour (the only manual labour for programmers) that
definitely involves some health risks. I don't see why programmers
should type redundant things if such stuff are not essential. I am
waiting for new IDEs which will generate code based on speech so that we
won't have carpal tunnel syndrome in old age :-)

And, as others have pointed out, such a feature may be more flexible in
the face of code changes.

> Editing the code, debugging and extending
> functionality would be more error prone with "implementing" than with
> current rules.

I don't see how these things become more error prone with the proposed
feature. There are many languages that allow implementation within the
class definition, and, I didn't find them particularly error-prone in
these aspects.

--
Biju Thomas
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hallo !

Valentin Bonnard wrote:

  Witold Kaminski, Student wrote:

  > My oppinion is that it should be forbidden to declare inline
functions in
  > the header (or in the header-file  generally).
  > The header is an interface not an implementation.

  My opinion is that you should learn about the keywords
  ``inline'' and ``private'' before making such comments
  (or maybe it was humorous ?)

Well I'm not shure, but I think you want to tell me this:

class A
{
    // declatation
};

class B : private A
{
    // implementation of A
};

The problem is, that name A and B mustn't be the same (can it ?). It is
a blemish, but you are right (if it works so) - the
difference between this and the word implementing is not big. (But
However I think the Implementation of class A (class
B) should be in a ".cpp" file. - So far I misunderstood you - sorry).
But you have one problem with "class B : private A" : you can't use more
than one file for the implemetation.


Bye,

    Witold Kaminski
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Biju Thomas <b_thomas@ibm.net> wrote in message
news:381B7718.B5F111ED@ibm.net...
[snip]
>
> I prefer to put implementations of different classes into different
> files.

Actually it's a common practice to arrange related classes into a single
compilation unit. It's normal to have 1000+ classes in a large project. I
don't see what good it would be to create 1000 files, one file for a class.
In fact I haven't seen a single commercial product that would follow one
class-one file rule. It doesn't prove anything, of cource, but somehow I
haven't seen anybody so far defending one file concept.
Even if you have only one class in your file you still cannot tell whether
the function is standalone or a class method. And you have to look at the
file name to recall what your class name is (unless you want to search for
the place where "implementing" is typed), and as it sometimes happens the
two not necessary convey the same idea.

> > Your desire is to avoid typing the full qualified names and everybody
who
> > worked with large projects knows that typing of the code per se is very
> > insignificant part of the project.
>
> It is still a significant part of the coding effort. It is also a type
> of manual labour (the only manual labour for programmers) that
> definitely involves some health risks. I don't see why programmers
> should type redundant things if such stuff are not essential. I am
> waiting for new IDEs which will generate code based on speech so that we
> won't have carpal tunnel syndrome in old age :-)

This is actually very small typing efforts. I always use copy/paste to add
class qualifications. It's fast and prevents from errors. In any case, the
typing efforts is the least significant part of the project. You can even
teach monkeys to push the buttons :-) It's much more difficult to teach
monkeys to debug and fix bugs or extend functionality.

>
> And, as others have pointed out, such a feature may be more flexible in
> the face of code changes.

I don't understand it. You still have one point of declaration and one point
of definition. I f you make changes you have to do them in this two places
whether with or without "implementing."

> I don't see how these things become more error prone with the proposed
> feature. There are many languages that allow implementation within the
> class definition, and, I didn't find them particularly error-prone in
> these aspects.

Error prone they are. Because as  I mentioned above you don't see the class
name the function belongs to, so there are more opportunities of making
error. When you are debugging code there are many places with similar or
even identical functions, if you don't see the class name you can easily
make the wrong conclusions.
Another unpleasant thing is that proposed "implementing" specifies very long
block. In case of some brackets mismatch, compiler diagnostic may be
confusing.

After saying all that, I wouldn't mind using "implementing" if there were
some kind of preprocessor that would automatically expand "implementing"
into conventional syntax.

Gene Bushuyev
[I love California. I practically grew up in Phoenix]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I agree. Using the suggested implementing syntax the code becomes more
readable. But I think the real advantage of this new keyword would be the
reduction of places the programmer has to change when adding
extra-parameters to the declaration. Using implementing the number of places
is reduced, there are only 2 places where changes have to be made.

Markus

--
---
JAVA-FAQ:
http://www.geocities.com/SiliconValley/Foothills/5270/JavaFAQ.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------289ABC05FC082229B2E787EE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think what Kaminski means is that there should be a simple syntax for
definition. Inlining is a total different thing. Instead of using the whole
scope (with scope resolution operator )each time , you could define using the
keyword "implementing". This would  be quiet helpful and readable.

Neelesh

Valentin Bonnard wrote:

> Witold Kaminski, Student wrote:
>
> > I suggest to extend the c++ language with the keyword "implementing".
>
> [...]
>
> > In stead of this you should write (or something like that):
> >
> > implementing template<class A,B,....> class blah
> > {
> >     t1 test1(t2 &x)
> >     {
> >         return t1();
> >     }
> >
> >     t1 test2(t2 &x)
> >     {
> >         return t1();
> >     }
> > }
> >
> > I think it is easier to read.
>
> You mean that you want to use Java syntax (function
> definitions together in the class ``definition'') in
> C++. You mention the advantage of not having to qualify
> names with the class name, which may be quite long
> since all template arguments are needed. Actually, you
> overstate the need for qualification: function arguments
> need not be qualified, only the return type needs to.
>
> Note that with inline functions you already have the
> syntax you prefer. I don't think the small syntaxical
> advantage is worth the change.
>
> --
>
> Valentin Bonnard
> ---
> [ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

--
Neelesh Vaikhary
Sr. Consultant

Xpedior,
Email : Neelesh.Vaikhary@Xpedior.com,
Phone : 415-399-7288 (W), 510-885-9367(H), 415-577-NEEL(C).


--------------289ABC05FC082229B2E787EE
Content-Type: text/x-vcard; charset=us-ascii;
 name="Neelesh.Vaikhary.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Neelesh Vaikhary
Content-Disposition: attachment;
 filename="Neelesh.Vaikhary.vcf"

begin:vcard
n:Vaikhary;Neelesh
tel;cell:415-577-NEEL
tel;fax:415-399-7002
tel;home:510-885-9367
tel;work:415-399-7288
x-mozilla-html:TRUE
url:www.Xpedior.com
org:Xpedior
version:2.1
email;internet:Neelesh.Vaikhary@Xpedior.com
title:Sr. Consultant
adr;quoted-printable:;;44 Montgomery Street,=0D=0ASuite # 3200;San Francisco;CA;94104;USA
x-mozilla-cpt:;21168
fn:Neelesh Vaikhary
end:vcard

--------------289ABC05FC082229B2E787EE--
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote in message <3816CE9F.6B4D@wanadoo.fr>...

>You mention the advantage of not having to qualify
>names with the class name, which may be quite long
>since all template arguments are needed. Actually, you
>overstate the need for qualification: function arguments
>need not be qualified, only the return type needs to.


Is that really so?
I interpret the return type of the member function being considered as a
name used in a member function definition. If my interpretation is correct,
there should be no need to qualify the return type. [sect.9.3 para.5]

---------
Tsutomu Yoshida
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Witold Kaminski, Student wrote:

> My oppinion is that it should be forbidden to declare inline functions in
> the header (or in the header-file  generally).
> The header is an interface not an implementation.

My opinion is that you should learn about the keywords
``inline'' and ``private'' before making such comments
(or maybe it was humorous ?)

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Neelesh Vaikhary wrote:

> I think what Kaminski means is that there should be a simple syntax for
> definition.

Yes

> Inlining is a total different thing.

Yes

> Instead of using the whole
> scope (with scope resolution operator )each time , you could define using the
> keyword "implementing". This would  be quiet helpful and readable.

I think that you should learn all the syntaxes which define
inline function (hint: one of these does not use the ``inline''
keyword at all).

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

T.Yoshida wrote:

> Valentin Bonnard wrote in message <3816CE9F.6B4D@wanadoo.fr>...
>
> >You mention the advantage of not having to qualify
> >names with the class name, which may be quite long
> >since all template arguments are needed. Actually, you
> >overstate the need for qualification: function arguments
> >need not be qualified, only the return type needs to.
>
> Is that really so?

Yes, I am sure (no, I don't know the section number).

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Witold Kaminski, Student <kaminski@apfel.de> wrote in message
news:38156292.E73A3ECE@apfel.de...
> Hello to all !
>
> I suggest to extend the c++ language with the keyword "implementing".
>

I actually think it's a bad idea. When you have big implementation files and
more than one class, that is often the case in the real world, it's very
important to see the full function name, including the class(es) name(s).
It's a pain to scroll all the way to the beginning to see what class you're
"implementing". It also can be a source of errors if you occasionally looked
at the wrong "implementing."
Note, that you can always use elaborate comments to mark where your
implementation starts and what class you are implementing.
Your desire is to avoid typing the full qualified names and everybody who
worked with large projects knows that typing of the code per se is very
insignificant part of the project. Editing the code, debugging and extending
functionality would be more error prone with "implementing" than with
current rules.

Gene Bushuyev.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:

> Without implementing, every single member function
> definition must be modified.

Use macros ?

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Witold Kaminski, Student wrote:

> I suggest to extend the c++ language with the keyword "implementing".

[...]

> In stead of this you should write (or something like that):
>
> implementing template<class A,B,....> class blah
> {
>     t1 test1(t2 &x)
>     {
>         return t1();
>     }
>
>     t1 test2(t2 &x)
>     {
>         return t1();
>     }
> }
>
> I think it is easier to read.

You mean that you want to use Java syntax (function
definitions together in the class ``definition'') in
C++. You mention the advantage of not having to qualify
names with the class name, which may be quite long
since all template arguments are needed. Actually, you
overstate the need for qualification: function arguments
need not be qualified, only the return type needs to.

Note that with inline functions you already have the
syntax you prefer. I don't think the small syntaxical
advantage is worth the change.

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello, thank you for your answer.

> You mean that you want to use Java syntax (function
> definitions together in the class ``definition'') in
> C++. You mention the advantage of not having to qualify
> names with the class name, which may be quite long
> since all template arguments are needed. Actually, you
> overstate the need for qualification: function arguments
> need not be qualified, only the return type needs to.

Well that's ok (I don't know that). But however, I think it is niceier to
use
the keyword "implementing".  And I think everthing making code better
readable
should be used.

> Note that with inline functions you already have the
> syntax you prefer. I don't think the small syntaxical
> advantage is worth the change.

My oppinion is that it should be forbidden to declare inline functions in
the header
(or in the header-file  generally).
The header is an interface not an implementation.


Bye,

    Witold Kaminski
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Witold Kaminski, Student wrote:
>
> > I suggest to extend the c++ language with the keyword "implementing".
>
> [...]
>
> > In stead of this you should write (or something like that):
> >
> > implementing template<class A,B,....> class blah
> > {
> >     t1 test1(t2 &x)
> >     {
> >         return t1();
> >     }
> >
> >     t1 test2(t2 &x)
> >     {
> >         return t1();
> >     }
> > }
> >
> > I think it is easier to read.
>
> You mean that you want to use Java syntax (function
> definitions together in the class ``definition'') in
> C++. You mention the advantage of not having to qualify
> names with the class name, which may be quite long
> since all template arguments are needed. Actually, you
> overstate the need for qualification: function arguments
> need not be qualified, only the return type needs to.
>
> Note that with inline functions you already have the
> syntax you prefer. I don't think the small syntaxical
> advantage is worth the change.

No, inline functions (as well as Java like definitions)
are a completely different beast:

// foo.h

#ifndef FOO_H_INC
#define FOO_H_INC

template<template<class T> class X> class Foo
{
public:
  void do_something();
  template<class U> void blabla(X<U>&);
  // ...
};

#include "foo.cc"

#endif

// foo.cc

#ifdef HAS_IMPLEMENTING

implementing template<template<class T> class X> class Foo
{
  void do_something()
  {
    ...
  }

  template<class U>
   void blabla(X<U>&)
  {
    ...
  }
};

#else

template<template<class T> class X>
 void Foo<X>::do_something()
{
  ...
}

template<template<class T> class X>
 template<class U>
  void Foo<X>::blabla(X<U>&)
{
  ...
}

#endif

You cannot do that with inline functions.
The point is that interface and implementation _are_
separated, but you can use the simpler syntax as in the
class anyway.

And it's more maintainable, too: Think about the work
you have to do if you want to add another template
parameter (with default value).

With implementing, there are only two places to
add the parameter (other than possibly in some code using
it, which should make use of the extra functionality):
The class definition, and the implementing clause.

Without implementing, every single member function
definition must be modified. Even with about ten
member functions (constructor, copy constructor,
assignment, destructor, some ordinary member functions)
it becomes quite tedious (and easy to forget one).
Especially if some members are member templates.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello to all !

I suggest to extend the c++ language with the keyword "implementing".

// the interface

template <class A,class B,....>
class blah
{
    typedef blah<A,B,....> self;
    typedef blup<self> t1;
    typedef blop<int> t2;
    t1 test1(t2& x);
    t1 test2(t2& x);
    // .....
};

// in out day we implement the class blah<..> in the following way:
//  (this is a short example)

template<class A,B,....>
blah<A,B,....>::t1 test1(blah<A,B,....>::t2& x)
{
    return t1();
}
template<class A,B,....>
blah<A,B,....>::t1 test2(blah<A,B,....>::t2& x)
{
    return t1();
}

In stead of this you should write (or something like that):

implementing template<class A,B,....> class blah
{
    t1 test1(t2 &x)
    {
        return t1();
    }

    t1 test2(t2 &x)
    {
        return t1();
    }
}

I think it is easier to read.

Bye,

    Witold Kaminski.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]