danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301220928.570919a1@posting.google.com>...
> philippe_mori@hotmail.com ("Philippe Mori") wrote in message news:<wkkX9.50883$_N5.492963@news20.bellglobal.com>...
> > I don't think so. For me, the re-opening make the proposition far
> > more interesting since it would allows far more better encapsulation.
> > We would be able to put all implementation function in source file.
>
> I definitevely am terrified about this. Let's differentiate:
> re-opening for defining, ok, BUT re-opening for declaring, scary.
> What I LIKE of C++ instead of C, is the 'closure' concept. You don't
> need to make giants greps or searches all around the code for puting
> everything together (as you do need in C), as far as the 'closed'
> concept is active.
> I like the isomorphism between '[logical] encapsulation' AND 'physical
> encapsulation' (everything together). Would you like something like
>
> [file1]
> struct A
> {
>    int a1;
> };
>
> [file2]
> struct A
> {
>    int a2;
> };
>
> [file3]
> struct A
> {
>    int a3;
> };
>
>    ?
>
> I do not.

But C++ today does not enforce this isomorphism you're talking about.

// Foo.h:

class Foo {

  public:

#include "FooPublic.h"

  private:

#include "FooPrivate.h"

};

// FooPublic.h:

void F();
void G();


// FooPrivate.h:

int mX;
float mY;


I've seen real code like this. It's as bad as you think. Maybe worse.

Bob Bell

---
[ 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                       ]

philippe_mori@hotmail.com ("Philippe Mori") wrote in message news:<wkkX9.50883$_N5.492963@news20.bellglobal.com>...
> > > [...]
> > > why not allow all classes to be reopened?  Think about it.  Your
> > > header file only needs to define the public interface, which
> > > includes public methods, and the object size (i.e. the data members).
> > > Then, in the source module, you could reopen the class and add
> > > private methods.
> > > [...]
> >
> > It seems to me that this adds more compiler complexity than the
> > original proposal, with negligible benefit.  Right now, if a compiler
> > sees a class being defined twice, it can simply issue a diagnostic.
> > With the namespace proposal, that strategy is still valid.  By
> > allowing the definition of the class to be extended in a second
> > declaration, you make the language considerably more complicated.
> > The "class namespace" only has to place the definitions in the
> > right scope, which is a much simpler task.
> >
> > Dave
> >
>
> I don't think so. For me, the re-opening make the proposition far
> more interesting since it would allows far more better encapsulation.

It allows for no encapsulation.

// My.h:
class Foo {
   int x;
};

// My.cpp:
class Foo {
   void F();
};


// Your.cpp:
class foo {
   void G() { x = 10; }
};

Anyone can access the private members of your class by simply
reopening it. You might as well make your members public.

Bob Bell

---
[ 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                       ]

belvis@pacbell.net (Bob Bell) wrote in message news:<c87c1cfb.0301281310.4491924@posting.google.com>...

Oops!

> // Your.cpp:
> class foo {

--------^  Should be "F"

> Anyone can access the private members of your class by simply
> reopening it. You might as well make your members public.

Assuming that the class name is spelled correctly. :-)

Bob

---
[ 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                       ]

""Philippe Mori"" <philippe_mori@hotmail.com> wrote in message
news:JXjY9.12891$5K5.1015470@news20.bellglobal.com...
> [...]
> I think that we could make the redeclaration of template arguments
> optional...
> The compiler could figure them out most of the time and we can
> provide them in other cases.

I don't think this is consistent with the rest of C++.  If we're going to
have that level of inference, let's have 'auto'-as-deduced-type and
typeof().

> So we would have something like:
>
> template <typename T, int i>
> class A {
>     template <typename T2> void f(T2 t);
> };
>
> template template void A::f(T2 t) {
>     // Does something here...
> }
>
> No new keyword.

The namespace proposal also introduces no new keywords, but
also makes it slightly nicer to define a large number of member
functions, which your proposal does not address.

> We only remove all unnecessary angle brackets and
> template arguments that are not required. They would be required
> only when we have some specialisations and they are ambiguities.

However, there is such a thing as too little information as well.  Now,
if you put the definitions in their own file, you can't see the template
parameters at all, so if the number of template params changes, it's
not obvious that you updated the implementation properly.

> In fact for specialisation, we would need them one time and not
> twice. For ex for a specialisation with i = 0:
>
>     template template voidA<T, 0>::f(T2 t) { ... }

One thing that rubs me the wrong way about this proposal is that it's
the only time in C++ you would see a keyword repeated. ;>

Dave



---
[ 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                       ]

kanze@gabi-soft.de (James Kanze) wrote
> Just that smaller code isn't, per se, better.

Right.

Some languages, including (I believe) most "scripting" languages,
allow you to skip a declaration of a variable -- just start using it.
This too makes for smaller source code. However, if you mistype the
name of a variable, you've actually just created a new variable,
usually without any error or warning message.
    // Pseudo-C++
    int find_value(int ary[], int size, int value) {
        for (index=0; index<size; ++index)
            if (ary[idx]==value) return index;
        return -1; // Not found
    }
This simple program is 4 bytes shorter than a real one, because
we didn't have to declare that index is an int. It's also more
buggy than a real one, because index is spelled two different
ways ("index" and "idx").

Very often, verbose is ver-yer-own-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                       ]

usenet_cpp@lehrerfamily.com (Joshua Lehrer) wrote
> cpdaniel@nospam.mvps.org ("Carl Daniel") wrote
> why not allow all classes to be reopened?  Think about it.  Your
> header file only needs to define the public interface, which includes
> public methods, and the object size (i.e. the data members).  Then, in
> the source module, you could reopen the class and add private methods.
>  Assuming you already had a vtable, in the reopening of the class you
> could add overrides to any exiting virtual functions.  Why does the
> fact that you override a private virtual method need to be in your
> public header?  Why does the existence of a non-virtual private method
> need to be in your public header?

I'm not sure about that, but I do know that most of the rules about
what you can and cannot do with an incomplete class are based on
what we know about the class. I'm certain that most of the same
concepts would apply to all classes, if there was the possibility
of "extending" the class elsewhere.

For example, to use a class name in a new-expression, we have to know
the amount of memory to allocate, and whether or not it has a constructor.
The first requirement means that we have to already know about any
private members, as well as whether there are any virtual functions or
not. For the second case, even if we know that there's no constructor
declared, we have to know about any base classes or embedded elements --
because if one of those has a constructor, then so does the derived class.

As for private non-virtual methods: well, you may have a point here.
Since it takes no room in the instantiated class, and since it's
private to the other class members, maybe it would make sense to
allow these to be added after the fact. Really, this wouldn't be much
different than declaring some anonymous namespace functions in the
class that implements the class functions, except that private functions
have member access.

Still, from a conceptual point of view -- well, I believe that Daniel
Gutson put it very well, when he pointed out the way that this breaks
encapsulation. "Data hiding" doesn't just mean "don't let non-member
functions see this data," it also means "make sure that we can easily
find all of the functions that do get to access this data." This new
rule could potentially pervert that whole idea.

---
[ 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                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote
> ok...as the other threads advocate; shorter code *might* not be more
> maintainable, but it often is. However, what we're
> discussing here has to do with automation of trivial tasks, and that's what
> RAII does. If you don't have RAII, you do
> copy and paste and try-catch-finally stuff as seen in Java; clearly not a
> good thing. Returning to Stroustrup's comments,
> I believe he said something like "the number of errors (in a program)
> increase at least linear with the size of the program".
> So my point is that even trivial boiler-plate code can introduce errors.

Quote taken out of context, I'm sure. (Well, by definition all quotes
are out of context... also, I don't know where Stroustrup said this,
so I can't know what he actually did mean.)

My point, however, is that you can take this type of thinking too far.
Let's assume for a moment that what you implied is true -- the "size
of the program" is measured in lines of code (as opposed to bytes of
compiled code, bytes in the final executable, size of the documentation,
etc.) -- a big assumption, not always warranted, but very often done
in real-world projects without even any discussion first.

Would you say that removing comments from a program is likely to
reduce the error count? Because if not, we need to add at least one
qualifier to the statement above. Same thing for blank lines. So
now we have

    The number of errors (in a program) increate at least linear
    with the number of lines of source, not including blank lines
    or comments.

But how about vertical compression? Go look at the Obfuscated C Contest
for examples of (what ought to be) 200-line programs compressed into
16 lines. Ignore for now the (vitally important) problem of code
maintenance. Does this type of code compression reduce the error count?
I assume you'll agree with me that it does not.

    The number of errors (in a program) increase at least linear
    with the number of source-code statements, regardless of blank
    lines or comments.

Does that solve the problem? No, because in most C++ programs most of
the statements are expression statements, and there's always the
comma operator. You can sometimes reduce statement count just by
changing certain semicolens into commas; surely that doesn't reduce
the error count. (Do it in the wrong place, and it increases the
error count!) Similarly, we can replace if-then with the trinary
operator.

Maybe what we really need to recognize is the number of statements
that the program *ought* to use. I hope you can agree that the
"natural" number of statements (if you're not trying to make a point)
relates to the amount of work to be done and the algorithm selected.
I think the fairest way to say this is,

    The number of errors (in a program) increase at least linear
    with the complexity of that program.

Now I can agree with your original hypothesis by pointing out that
RAII can help to simplify the complexity of a program.

Remember how the subject used to be about re-opening class scope
to add private, non-virtual functions? I don't think this simplifies
the complexity of a program at all. I think it adds to the complexity.
That's true even if the total number of source code lines /
statements / whatevers remains constant.

---
[ 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                       ]

> > > Is that really an issue today? Does the OP (Thorsten Ottosen) use an
> > > editor that doesn't have copy-and-paste?
>
> > I guess you don't use templates either since we can just use
> > copy-and-paste. Are you a Java programmer? :-)
>
> His point is obviously overstated, but copy and paste (or editor
> shortcuts/abreviations) do mean that it is not significantly more work
> to write the current syntax than what is being proposed.
>
> The real problem with copy and paste is program maintenance.  If we
> could be 100% sure of getting the templated class right the first time,
> and never having to modify it, there would be a bit less argument for
> templates as well.  (Only a bit less, because there are still the issues
> of using templated components provided by a third party, automatic
> instantiation, etc.)
>
> The question thus becomes one of maintenance.  What is the probability
> of the template declarations changing.  And how does any new syntax
> weigh against the additional local redundancy -- it is certainly easier
> to read a program when the class/template of the function is immediately
> visible in the header of the function.
>

I think that we could make the redeclaration of template arguments
optional...
The compiler could figure them out most of the time and we can provide
them in other cases.

So we would have something like:

template <typename T, int i>
class A {
    template <typename T2> void f(T2 t);
};

template template void A::f(T2 t) {
    // Does something here...
}

No new keyword. We only remove all unnecessary angle brackets and
template arguments that are not required. They would be required only
when we have some specialisations and they are ambiguities.

In fact for specialisation, we would need them one time and not twice.
For ex for a specialisation with i = 0:

    template template voidA<T, 0>::f(T2 t) { ... }



---
[ 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                       ]

> > [...]
> > why not allow all classes to be reopened?  Think about it.  Your
> > header file only needs to define the public interface, which
> > includes public methods, and the object size (i.e. the data members).
> > Then, in the source module, you could reopen the class and add
> > private methods.
> > [...]
>
> It seems to me that this adds more compiler complexity than the
> original proposal, with negligible benefit.  Right now, if a compiler
> sees a class being defined twice, it can simply issue a diagnostic.
> With the namespace proposal, that strategy is still valid.  By
> allowing the definition of the class to be extended in a second
> declaration, you make the language considerably more complicated.
> The "class namespace" only has to place the definitions in the
> right scope, which is a much simpler task.
>
> Dave
>

I don't think so. For me, the re-opening make the proposition far
more interesting since it would allows far more better encapsulation.
We would be able to put all implementation function in source file.

But there is a problem. To be really usefull, we would need to be
able to add private variable members. Otherwise, it often better to
uses existing p-impl idiom. In fact, what we really want to make
private (and invisible), it is the data...

For private member functions, we can often remplace them by
namespace functions in the source file and provide extra parameters
for the data.

So finally, the extension is in fact less usefull that it might appears
at first.


In fact, what would be great would be to support re-opening fully
(including adding data members) and also fully support template
functions to be defined in source file (instead of header). But that
would require compiler and linker support and probably either
extra generated files or a database...

I know that some recent compiler does support template in source
file... I think, it would be about the same difficulty to fully support
re-opening. This could be complicate if reopening can be done from
multiple files.

Maybe, we would need some mechanism in the language to specify
the implementation file. That file would be processed first to
integrated any required change to the class. We would typically then
need the equivalent of "original .h file" + "implementation data member"
=> "new merged .h file". That file would be modified only when
the original changes or the implementation changes in a way that
would change the class size.



---
[ 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                       ]

philippe_mori@hotmail.com ("Philippe Mori") wrote in message news:<wkkX9.50883$_N5.492963@news20.bellglobal.com>...
> > > [...]
> > > why not allow all classes to be reopened?  Think about it.  Your
> > > header file only needs to define the public interface, which
> > > includes public methods, and the object size (i.e. the data members).
> > > Then, in the source module, you could reopen the class and add
> > > private methods.
> > > [...]
> >
> > It seems to me that this adds more compiler complexity than the
> > original proposal, with negligible benefit.  Right now, if a compiler
> > sees a class being defined twice, it can simply issue a diagnostic.
> > With the namespace proposal, that strategy is still valid.  By
> > allowing the definition of the class to be extended in a second
> > declaration, you make the language considerably more complicated.
> > The "class namespace" only has to place the definitions in the
> > right scope, which is a much simpler task.
> >
> > Dave
> >
>
> I don't think so. For me, the re-opening make the proposition far
> more interesting since it would allows far more better encapsulation.
> We would be able to put all implementation function in source file.

I definitevely am terrified about this. Let's differentiate:
re-opening for defining, ok, BUT re-opening for declaring, scary.
What I LIKE of C++ instead of C, is the 'closure' concept. You don't
need to make giants greps or searches all around the code for puting
everything together (as you do need in C), as far as the 'closed'
concept is active.
I like the isomorphism between '[logical] encapsulation' AND 'physical
encapsulation' (everything together). Would you like something like

[file1]
struct A
{
   int a1;
};

[file2]
struct A
{
   int a2;
};

[file3]
struct A
{
   int a3;
};

   ?

I do not.

---
[ 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                       ]

""Magnus Lidbom"" <magnus_lidbom@hotmail.com> wrote in message
news:_gYV9.6472$FF4.391385@newsb.telia.net...
>
> How about:
>
> class Foo::
> {
>     int f() const
>     {
>          //...
>     }
> };
> ?
> Seems quite intuitive to me, a class Foo scoped block. No new keyword
needed.
>

Why not simply reopen the class as a namespace since a class is already a
kind of namespace:

template<class T> class A {
    void f();
};
template<class T> namespace A {
    void f() { ... }
}

class B {
    void g();
};
namespace B {
    void g() { }
}


Jacques


---
[ 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                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") writes:
[snip]
> hm...Stroustrup explained that the RAII thing delayed the language at least
> a year
> because it could remove copy-and-paste into the language.
[snip]

What do you mean by this comment? (I'm not advocating or attacking the
    template region extension suggestion; I'm just confused by this
    sentence. )

---
[ 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                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
news:<b07ka2$p4g$1@sunsite.dk>...
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0301161145.71ebc1bb@posting.google.com...
> [snip]
> > Is that really an issue today? Does the OP (Thorsten Ottosen) use an
> > editor that doesn't have copy-and-paste?

> I guess you don't use templates either since we can just use
> copy-and-paste. Are you a Java programmer? :-)

His point is obviously overstated, but copy and paste (or editor
shortcuts/abreviations) do mean that it is not significantly more work
to write the current syntax than what is being proposed.

The real problem with copy and paste is program maintenance.  If we
could be 100% sure of getting the templated class right the first time,
and never having to modify it, there would be a bit less argument for
templates as well.  (Only a bit less, because there are still the issues
of using templated components provided by a third party, automatic
instantiation, etc.)

The question thus becomes one of maintenance.  What is the probability
of the template declarations changing.  And how does any new syntax
weigh against the additional local redundancy -- it is certainly easier
to read a program when the class/template of the function is immediately
visible in the header of the function.

> > I don't want to say that this proposal doesn't have merit. Perhaps
> > less typing will also mean fewer errors (although I think most of
> > those errors would have been caught in the first compile anyway).

> Perhaps? No, it definitely will. A smaller code base is easier to
> maintain.

That depends on the measures taken to make the code base smaller.  When
I first approached C, just for the fun of it, I rewrote the last 15
lines of a function in one statement, with something like five levels of
nested ?:, etc.  The result was a smaller code base, but nobody in his
right mind would find it easier to maintain.

More realistically, Java obtains a smaller code base by not separating
class definitions and implementations.  C++ allows this (with the caveat
that all of the functions will be inline); experience has show that it
is something to avoid, and most coding guidelines I've seen forbid it.
Breaking a large function up into several smaller ones also increases
the number of lines of code.

> >But it does seem to me that language changes that serve *only* to
> >make the source code smaller, are not the right direction.

> hm...Stroustrup explained that the RAII thing delayed the language at
> least a year because it could remove copy-and-paste into the
> language. I guess we could say templates merely makes the source
> smaller too.

Templates do far more than that.  If not, there would be no interest in
them.

> > For an example of taking "short code" too far, look at the language
> > APL. (There were other problems with that language too, such as the
> > need for either a special font for the program source or else
> > cryptic codes to represent "missing" characters, and also a language
> > definition that practically guaranteed the program must be
> > interpreted instead of compiled. But it certainly didn't help that
> > major routines were often written as one line of several hundred
> > characters without spaces or comments, for the sake of efficiency!)

> I don't see your point here? What are you trying to say?

Just that smaller code isn't, per se, better.

If the code is smaller because you've used a simpler, clearer algorithm,
it is better.

If the code is smaller because you've ignored all of the error
conditions, it simply isn't correct.

And if the code is smaller because you've used complicated expressions
to compress it to a maximum, then it certainly isn't better.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

"llewelly" <llewelly.@@xmission.dot.com> wrote in message
news:86iswnv1sc.fsf@Zorthluthik.foo...
> nesotto@cs.auc.dk ("THORSTEN OTTOSEN") writes:
> [snip]
> > hm...Stroustrup explained that the RAII thing delayed the language at
least
> > a year
> > because it could remove copy-and-paste into the language.
> [snip]
>
> What do you mean by this comment? (I'm not advocating or attacking the
>     template region extension suggestion; I'm just confused by this
>     sentence. )

ok...as the other threads advocate; shorter code *might* not be more
maintainable, but it often is. However, what we're
discussing here has to do with automation of trivial tasks, and that's what
RAII does. If you don't have RAII, you do
copy and paste and try-catch-finally stuff as seen in Java; clearly not a
good thing. Returning to Stroustrup's comments,
I believe he said something like "the number of errors (in a program)
increase at least linear with the size of the program".
So my point is that even trivial boiler-plate code can introduce errors.

regards

Thorsten


---
[ 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                       ]

"Joshua Lehrer" <usenet_cpp@lehrerfamily.com> wrote in message
news:31c49f0d.0301182039.4d870b93@posting.google.com...
> [...]
> why not allow all classes to be reopened?  Think about it.  Your
> header file only needs to define the public interface, which
> includes public methods, and the object size (i.e. the data members).
> Then, in the source module, you could reopen the class and add
> private methods.
> [...]

It seems to me that this adds more compiler complexity than the
original proposal, with negligible benefit.  Right now, if a compiler
sees a class being defined twice, it can simply issue a diagnostic.
With the namespace proposal, that strategy is still valid.  By
allowing the definition of the class to be extended in a second
declaration, you make the language considerably more complicated.
The "class namespace" only has to place the definitions in the
right scope, which is a much simpler task.

Dave



---
[ 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                       ]

cpdaniel@nospam.mvps.org ("Carl Daniel") wrote in message news:<F0sV9.102$ma3.75@newssvr16.news.prodigy.com>...
> I think the point was to re-open the class, in a way that allows only
> definitions of class members that have been declared but not defined.  This
> would save quite a bit of typing in template classes with out-of-line
> function definitions.

why not allow all classes to be reopened?  Think about it.  Your
header file only needs to define the public interface, which includes
public methods, and the object size (i.e. the data members).  Then, in
the source module, you could reopen the class and add private methods.
 Assuming you already had a vtable, in the reopening of the class you
could add overrides to any exiting virtual functions.  Why does the
fact that you override a private virtual method need to be in your
public header?  Why does the existence of a non-virtual private method
need to be in your public header?

As long as you don't change the object size, and don't remove anything
from the public interface (you could add public methods, but most of
the world wouldn't know about them), you could be ok.

joshua lehrer
factset research systems

---
[ 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                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301161145.71ebc1bb@posting.google.com...
[snip]
> Is that really an issue today? Does the OP (Thorsten Ottosen) use an
> editor that doesn't have copy-and-paste?
I guess you don't use templates either since we can just use copy-and-paste.
Are you a
Java programmer? :-)

> I don't want to say that this proposal doesn't have merit. Perhaps less
> typing will also mean fewer errors (although I think most of those
> errors would have been caught in the first compile anyway).
Perhaps? No, it definitely will. A smaller code base is easier to maintain.

>But it does
> seem to me that language changes that serve *only* to make the source
> code smaller, are not the right direction.
hm...Stroustrup explained that the RAII thing delayed the language at least
a year
because it could remove copy-and-paste into the language. I guess we could
say
templates merely makes the source smaller too.

>
> For an example of taking "short code" too far, look at the language
> APL. (There were other problems with that language too, such as the
> need for either a special font for the program source or else cryptic
> codes to represent "missing" characters, and also a language definition
> that practically guaranteed the program must be interpreted instead of
> compiled. But it certainly didn't help that major routines were often
> written as one line of several hundred characters without spaces or
> comments, for the sake of efficiency!)

I don't see your point here? What are you trying to say?

regards

Thorsten


---
[ 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                       ]

""Hillel Y. Sims"" <usenet@phatbasset.com> wrote in message
news:npJV9.227722$FT6.36429858@news4.srv.hcvlny.cv.net...
> "James Kanze" <kanze@gabi-soft.de> wrote in message
> news:d6651fb6.0301160145.721ffec7@posting.google.com...
> >
> >     implement class Foo
> >     {
> >         int f() const
> >         {
> >             //  ...
> >         }
> >
> >         void g( int i )
> >         {
> >             //  ...
> >         }
> >     }
> >
>
> Now we're talking! But you have committed the cardinal sin of inventing a
> new keyword :-(
>
> (Hmm, how about "export"...)

How about:

class Foo::
{
    int f() const
    {
         //...
    }
};
?
Seems quite intuitive to me, a class Foo scoped block. No new keyword needed.

/Magnus Lidbom

PS: Just to be clear: I really like the idea. I dislike unnecessary
duplication of code, as well as unnecessary manual typing. Getting rid of them
for implementing classes would be very nice.(especially template classes.)











---
[ 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                       ]

> ????? This syntax is already allowed! (except that you must remove the
> <T,T2> up there). Am I missing the point?

I think the point was to re-open the class, in a way that allows only
definitions of class members that have been declared but not defined.  This
would save quite a bit of typing in template classes with out-of-line
function definitions.

-cd

---
[ 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                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message
news:<b03ef0$i5n$1@sunsite.dk>...

> Am I the only one who thinks templates are too irritating to define
> out of the class? Consider

> template< typename T, typename T2 >
> class Foo
> {
> public:
>      typedef ... some_type;
>      some_type bar() const;
> };

> template< typename T, typename T2 >
> inline typename Foo<T,T2>::some_type Foo<T,T2>::bar() const
> {
> ...
> }

> And we have repeat the stuff for every d*** function. Shouldn't it be
> possible to allow something similar to this:

> template< typename T, typename T2 > class Foo<T,T2>
> {
>     inline some_type bar() const
>     {
>      ...
>      }

>     // more functions
>
> }

> ?

Why limit it to templates:

    class Foo
    {
        int f() const ;
        void g( int ) ;
        //  ...
    } ;

and elsewhere:

    implement class Foo
    {
        int f() const
        {
            //  ...
        }

        void g( int i )
        {
            //  ...
        }
    }

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

""Carl Daniel"" <cpdaniel@nospam.mvps.org> wrote in message
news:F0sV9.102$ma3.75@newssvr16.news.prodigy.com...
> > ????? This syntax is already allowed! (except that you must remove the
> > <T,T2> up there). Am I missing the point?
>
> I think the point was to re-open the class, in a way that allows only
> definitions of class members that have been declared but not defined.
This
> would save quite a bit of typing in template classes with out-of-line
> function definitions.

Exactly. I think class interfaces are important to give code overview. But
the template definitions are just too
irritating to define outside the class which means almost all template
libraries are written "inline".

regards

Thorsten


---
[ 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                       ]

And while we're at it, I would actually like such a reopening to happen to
normal classes to. The benefit
is not as big as with templates, but it could be really handy.

regards

Thorten


---
[ 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                       ]

nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote in message news:<b03ef0$i5n$1@sunsite.dk>...
> Aloha,
>
> Am I the only one who thinks templates are too irritating to define out of
> the class?

I'd be very surprised if you are :-)

> Consider
>
> template< typename T, typename T2 >
> class Foo
> {
> public:
>      typedef ... some_type;
>      some_type bar() const;
> };
>
>
> template< typename T, typename T2 >
> inline typename Foo<T,T2>::some_type Foo<T,T2>::bar() const
> {
> ...
> }

It gets even worse: Consider

template<typename T1, template <typename T2> class T3>
class Foo {

 template<typename T4, typename T5, typename T6>
 void
 bar(T4 arg1, T5 arg2, T6 arg3);

};

leading to repeated

template<typename T1, template <typename T2> class T3>
template<typename T4, typename T5, typename T6>
void
Foo::bar(T4 arg1, T5 arg2, T6 arg3){

  //stuff

}

>
> And we have repeat the stuff for every d*** function. Shouldn't it be
> possible to allow something similar to this:
>
> template< typename T, typename T2 > class Foo<T,T2>
> {
>     inline some_type bar() const
>     {
>      ...
>      }
>
>     // more functions
>
> }
>
> ?

This looks to much like a class definition, IMHO. It would be something
akin to reopening a class, but without really doing it.

I'd prefer to be able to create a scope were the template parameters are valid:

Your example:

template< typename T, typename T2 > {

  inline
  some_type
  Foo::bar() const {

     //stuff
  }
}

My example:

template<typename T1, template <typename T2> class T3> {

   template<typename T4, typename T5, typename T6>
   void
   Foo::bar(T4 arg1, T5 arg2, T6 arg3){

   //stuff
   }
}

or even

template<typename T1, template <typename T2> class T3>
template<typename T4, typename T5, typename T6> {

   void
   Foo::bar(T4 arg1, T5 arg2, T6 arg3){

   //stuff
   }
}

<IRONY>
Given that keyword overloading is one of the primary reuse mechanisms
in C++, we might want to make that:

template<typename T1, template <typename T2> class T3> namespace {

   template<typename T4, typename T5, typename T6>
   void
   Foo::bar(T4 arg1, T5 arg2, T6 arg3){

   //stuff
   }
}

or with nesting even:

template<typename T1, template <typename T2> class T3> namespace {

   template<typename T4, typename T5, typename T6> namespace {
       void
       Foo::bar(T4 arg1, T5 arg2, T6 arg3){

       //stuff
       }
   }
}

Hah, language design is fun.

</IRONY>

OTOH, with templated typedef it may become possible to write
something like:

typedef template Foo< typename T, typename T2 > tFoo;

  inline
  some_type
  tFoo::bar() const {

     //stuff
  }

rsp.

typedef template Foo<typename T1, template <typename T2> class T3> tFoo;

template<typename T4, typename T5, typename T6>
void
tFoo::bar(T4 arg1, T5 arg2, T6 arg3){

  //stuff
}

which isn't really that bad anymore.

>
> regards
>
> Thorsten
>

Regards,

Uwe

> ---
> [ 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                       ]

cpdaniel@nospam.mvps.org ("Carl Daniel") wrote
> > ????? This syntax is already allowed! (except that you must
> > remove the <T,T2> up there). Am I missing the point?

I must admit that I missed the point too, until you explained it.

> I think the point was to re-open the class, in a way that allows only
> definitions of class members that have been declared but not defined.  This
> would save quite a bit of typing in template classes with out-of-line
> function definitions.

Is that really an issue today? Does the OP (Thorsten Ottosen) use an
editor that doesn't have copy-and-paste?

I don't want to say that this proposal doesn't have merit. Perhaps less
typing will also mean fewer errors (although I think most of those
errors would have been caught in the first compile anyway). But it does
seem to me that language changes that serve *only* to make the source
code smaller, are not the right direction.

For an example of taking "short code" too far, look at the language
APL. (There were other problems with that language too, such as the
need for either a special font for the program source or else cryptic
codes to represent "missing" characters, and also a language definition
that practically guaranteed the program must be interpreted instead of
compiled. But it certainly didn't help that major routines were often
written as one line of several hundred characters without spaces or
comments, for the sake of efficiency!)

---
[ 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                       ]

Aloha,

Am I the only one who thinks templates are too irritating to define out of
the class? Consider

template< typename T, typename T2 >
class Foo
{
public:
     typedef ... some_type;
     some_type bar() const;
};


template< typename T, typename T2 >
inline typename Foo<T,T2>::some_type Foo<T,T2>::bar() const
{
...
}

And we have repeat the stuff for every d*** function. Shouldn't it be
possible to allow something similar to this:

template< typename T, typename T2 > class Foo<T,T2>
{
    inline some_type bar() const
    {
     ...
     }

    // more functions

}

?

regards

Thorsten


---
[ 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                       ]