C++ Archeology: Limits of OO paradigm

[James Kanze]

On Feb 22, 5:55 pm, "(e-mail address removed)"

[...]

And the English is a problem. It's not that it's a second
language, that is easy enough to deal with. It's that not only
is it his second language, but he is incredibly verbose.
There's no need to master English but it's probably good to
stick to KISS (heh) when speaking a second language... his use
of English seems very similar to his use of C++.

His English in itself is a problem. At least for me (and I'm
fairly used to dealing with English written by non-native
speakers). Part of the problem may be that he doesn't know how
to express himself clearly in his native language: I suspect
that this is the case, but frankly, his English isn't good
enough for me to be sure.

 

[James Kanze]

Most of the things he talks about there can be implemented in
C++ if you really want them. For example, if you really love
garbage collection you can implement it.

You don't have to. It's available as an option. I use it
systematically in all new applications. (Regretfully, most of
my work at present involves maintaining some really old
applications.)

 

[red floyd]

Actually, I don't think they did. They accepted a proposal
to standardize a common document format. At present, two have
been proposed. Only one will end up standardized (and it will
probably be changed considerably by the committee before it gets
that far).

Actually, one *has* been standardized (ISO 26300 -- ODF).

 

[kwikius]

If I understood his suggestion correctly, he wanted to do this
as part of the type system.  I'd oppose that.  (FWIW: Herb
Sutter proposed it a long time ago, with regards to garbage
collection.)  It would be very awkward to have one pointer type
for on stack objects, and another for dynamically allocated
objects.

Stack objects are owned by the system, while heap objects are owned by
the user. That is a large difference. In no circumstances should you
delete a stack pointer and further you don't know how long it will
live.
OTOH a heap pointer can be managed very well. Nevertheless for example
shared pointer allows you to think you can "manage" a stack pointer,
which is daft as a brush IMO. AFAIK you can even pass these things
about, shared pointers that are dead as a dodo.

regards
Andy Little

 

[James Kanze]

Stack objects are owned by the system, while heap objects are owned by
the user. That is a large difference. In no circumstances should you
delete a stack pointer and further you don't know how long it will
live.

We all understand that, but do you think it reasonable to make
this difference part of the type system. That in:

T obj ;
T* p1 = &obj ;
T* p2 = new T ;

p1 and p2 should have different types, that you can't assign
one to the other, and that there is no common type which would
take both? And if not, what are you suggesting?

 

[kwikius]

We all understand that, but do you think it reasonable to make
this difference part of the type system.  That in:

    T obj ;
    T* p1 = &obj ;
    T* p2 = new T ;

p1 and p2 should have different types, that you can't assign
one to the other, and that there is no common type which would
take both?  And if not, what are you suggesting?

See this thread:

http://tinyurl.com/3debeh

BTW I have now sorted a GUI enabled smart ptr scheme, which solves the
problem by doing some poking about. Its discussed in the last post in
the thread.

I heard std::tr1::shared_ptr/weak_ptr was being upgraded somehow, but
I have no idea if it would now solve the problem

regards
Andy Little

 

[Grizlyk]

LR write:

every programmer has an employer or at least a customer

BTW, this is a cultural difference, not a technical one.

No. Each of programmer must pay taxes. Do we include in C++ ways of taxes
reducing? There are many programmers, who has a car, do we include in C++
regularity of car's tech-services? There is war in some countries, do we
include in C++ protection in the case of war or storm?

This is quite clear - there is domain (in our case the domain is
programming one and is a questions of programming and desing) and there is
environment of programmers - his wifes, childrens, parents, emploiers,
cars. They are different things and must be separated, correct language
intended to programming domain only.

_correct_? I suggest that this can only be subjective.

No. For our case "correctness" is very objective thing and even more - can
be easy tested by experience (or experiments): If there are no suitable
ways to resolve detected problem of domain, the thing is incorrect. Very
easy.

And this "public" language is going to have some problems.
Would any programmer take the time to learn a language

I have written in the thread above, that some people mixing "programming
language" and "desing ways". The time to lern basic (means all regular
stuffs) things of C/pascal/C++ is several weeks. This is experimental
time, many times proved.

We must assume, that programmer wants some desing things (that can be
expressed by his native language) and expects C++ syntax for it. This is
only way to lern and use programming language correctly (this is aslo
experimental thing, many times proved), "text of standard" can not help
you here.

that is going to have such potential problems with compatibility.

I guess you are about user-human's problems? The problems could be only
for people who can not explain thier own actions. Of course, versions must
be strictly separated, for example, by dialects (dialects here are part of
language syntax, rather than other version of "standard").

Why is that a benefit?

I already have answered befor (later in the post you are answering): "what
we can do with perfect language".

All languages have problems. Whatever language you develop will have
problems.

I found this quote here: http://www.research.att.com/~bs/bs_faq.html

"There are only two kinds of languages: the ones people complain about
and the ones nobody uses"

I do not want to discuss outside of terms of detected problems. We can not
hide the problems ( for C++ development some the problems already have been
enumerated by me:
- there are problems with expression by C++ existing desing ideas of
existing jobs;
- there are no _effective_ and _real_ way for _all_ end-users to reflect
their desires to C++;
- there are some contradicted "set of terms of conditions" of C++
development, each of them reflects own group of users and we have only one
(selected by certain condition) group supported now;
- there are ways to change the situation;
) by any quotes. If user require something, at least the user will use it,
why not? I agree, that with current state of C++ desing it is not easy (or
even possible) to take in account opinions of all end-users. And i am
speaking about the fact and ways of changing the state.

Everyone would like the language to improve. The question is, what are
the costs?

I know, there are free C++ compilers. Who pays for it?

You want a new language. That's fine. Go ahead. But I think you'll
find that the "industrial" requirements will always exist. In the mean
time, I think you can always grab hold of some public domain compiler
and modify it for your own ends.

No, i do not want new language if C++ is not closed one, and is not a
registered trade mark of concrete language, that is developed by concrete
registered persons under concrete registered terms and conditions. It is
not easy to guess is C++ open programming system or private language.

If i could do all works (even declarative works) with improved C++ myself,
how do you think, did i write here? I think even Stroustup uses some
community to do C++ development.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Grizlyk]

Who's going to write compilers for the
ostensibly faster-evolving public standard?

This is very correct question. From one side, searching persons, who will
do not-exsited thing is looks like a "cutting from the skin of a still
living bear". But from other side, we can use a kind of "default compiler"
for the improved language.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Grizlyk]

feeling that you prefer to spend your time
you are ... spending too much time

Looks like you even can not follow questions of OP (if you, of course, can
understand what does it mean), but already try direct me how i must spend
my time.

From other side, all of us can see many words on street walls, so why the
owners of the street words can not use the group as a street walls?

In 99,9% persent of cases i just ignore the messages like this, but in the
thread i will answer one time (due to huge size of the message) for all
other similar messages, because there is chance, that their authors will
not be able to guess why.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Grizlyk]

kwikius wrote:

I see some people try to discuss some of the ideas immediately. It is not
wrong, but seems to me, we can not get any useful result of the kind of
discussion without additional rules, yours (not my) ideas can be lost int
the topic.

As for the declared pointers, my opinion is: C++ uses static type
checking, that is why, in order to use all advantages of the type checking
we _must_ use declarations of all, that can be declared. Together with
correctly selected "declared by default" the declarations will not be
annoying thing.

Also inheritance of abstract classes can do static type checking less
strict and much more flexible, but still reliable (you never will get
runtime errors "no method for message"). At least i do not know desing
cases when the inheritance can not be enough to avoid wrong limitations of
static type checking.

The same "undeclared" problems with the "r-value references".

The declared pointers, of course is interesting problem, but it is
ordinary, technical one. Let's assume one of us will find excellent result
here, will he be able to push the result into C++? I am not sure. It is
much better to take attention at problems of C++ development itself.

So, in the new thread "C++ improvements: core and user properties, default
compiler - " i have tried to write about problems of C++ development. If we
can resolve them, we will be able to discuss with success about technical
problems of C++. Of course, you _must_ have interest with C++ development
by your programs.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Grizlyk]

The English needs reviewing

You can do only two real things here:
- try to understand my english;
- wait while i will do improvment of my english;

Otherwise, you looks really like a mail bot always notifing me about
something undelivered.

I just quickly glanced at two or three of the proposals:
one looks very much like variable args for templates

Try to express you opinion in the terms of my proposal. That looks like
this:

//
template<class T, class mtype=heap>
class X
{
public:
T mtype * ptr;

~X(){delete p;}
};

Here "delete" expects heap only, so the code can not be templated.
//

Otherwise, we are speaking about nothing.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[coal]

I have written in the thread above, that some people mixing "programming
language" and "desing ways". The time to lern basic (means all regular
stuffs)

Maksim,

Interesting topic... just a couple of spelling tips that would make
it easier for people to understand what you mean. I think when you
write "desing" you mean design. By "lern" you probably mean learn.

Brian Wood
Ebenezer Enterprises
www.webebenezer.net

 

[coal]

I think even Stroustup uses some
community to do C++ development.

Should be Stroustrup with two r's in his name.


Brian Wood

 

[coal]

LR write:










No. Each of programmer must pay taxes. Do we include in C++ ways of taxes
reducing? There are many programmers, who has a car, do we include in C++
regularity of car's tech-services? There is war in some countries, do we
include in C++ protection in the case of war or storm?

This is quite clear - there is domain (in our case the domain is
programming one and is a questions of programming and desing) and there is
environment of programmers - his wifes, childrens, parents, emploiers,
cars.  They are different things and must be separated, correct language
intended to programming domain only.





No. For our case "correctness" is very objective thing and even more - can
be easy tested by experience (or experiments): If there are no suitable
ways to resolve detected problem of domain, the thing is incorrect. Very
easy.


I have written in the thread above, that some people mixing "programming
language" and "desing ways". The time to lern basic (means all regular
stuffs) things of C/pascal/C++ is several weeks. This is experimental
time, many times proved.

We must assume, that programmer wants some desing things (that can be
expressed by his native language) and expects C++ syntax for it. This is
only way to lern and use programming language correctly (this is aslo
experimental thing, many times proved), "text of standard" can not help
you here.


I guess you are about user-human's problems? The problems could be only
for people who can not explain thier own actions. Of course, versions must
be strictly separated, for example, by dialects (dialects here are part of
language syntax, rather than other version of "standard").





I already have answered befor (later in the post you are answering): "what
we can do with perfect language".




I do not want to discuss outside of terms of detected problems. We can not
hide the problems ( for C++ development some the problems already have been
enumerated by me:
- there are problems with expression by C++ existing desing ideas of
existing jobs;
- there are no _effective_ and _real_ way for _all_ end-users to reflect
their desires to C++;
- there are some contradicted "set of terms of conditions" of C++
development, each of them reflects own group of users and we have only one
(selected by certain condition) group supported now;
- there are ways to change the situation;
) by any quotes. If user require something, at least the user will use it,
why not? I agree, that with current state of C++ desing it is not easy (or
even possible) to take in account opinions of all end-users. And i am
speaking about the fact and ways of changing the state.





I know, there are free C++ compilers. Who pays for it?





No, i do not want new language if C++ is not closed one, and is not a
registered trade mark of concrete language, that is developed by concrete
registered persons under concrete registered terms and conditions. It is
not easy to guess is C++ open programming system or private language.

I think C++ is more open than Java or C#. I suggest not worrying
too much about what the outcome will be. C++ is a big ship and
it takes quite a bit of effort to alter her course. In other
words, even when you're right about something, you may not see
the results you hope for for quite a while.

 

[James Kanze]

You can do only two real things here:
- try to understand my english;
- wait while i will do improvment of my english;

I try, but it's very difficult sometimes. And very tiring.

 

[LR]

LR write:


No. Each of programmer must pay taxes.

No, not so. James Kanze made the point elsethread that some programmers
only program for a hobby. So it's extremely unlikely that they are
paying taxes related to their programming.

Do we include in C++ ways of taxes
reducing?

We don't. But there was, I was taught long ago, once a law in France
that taxed the axles on carriages resulting in some three wheeled vehicles.

There are many programmers, who has a car, do we include in C++
regularity of car's tech-services? There is war in some countries, do we
include in C++ protection in the case of war or storm?

No, and as I said these are cultural, that is unrelated to the technical
issues that face programmers. I suspect we may be arguing at cross
purposes here.

This is quite clear - there is domain (in our case the domain is
programming one and is a questions of programming and desing) and there is
environment of programmers - his wifes, childrens, parents, emploiers,
cars. They are different things and must be separated, correct language
intended to programming domain only.

Correct, as I said, the attitude of the employer is cultural. Not
technical.

No. For our case "correctness" is very objective thing and even more - can
be easy tested by experience (or experiments): If there are no suitable
ways to resolve detected problem of domain, the thing is incorrect. Very
easy.

I see. Please define the word "suitable" in a suitably objective way so
that the above will be correct.

I have written in the thread above, that some people mixing "programming
language" and "desing ways". The time to lern basic (means all regular
stuffs) things of C/pascal/C++ is several weeks. This is experimental
time, many times proved.

We must assume, that programmer wants some desing things (that can be
expressed by his native language) and expects C++ syntax for it. This is
only way to lern and use programming language correctly (this is aslo
experimental thing, many times proved),

Please provide an example of what you mean here.

"text of standard" can not help
you here.

No? Then how about a usage manual? Will there be some document or
other source the programmer could turn to in order to find out what the
code is intended to mean?

I guess you are about user-human's problems? The problems could be only
for people who can not explain thier own actions.

IME this is very common with code. The people who write it are often
either unavailable or disinterested and will not explain it. Sometimes
they have simply forgotten, after a few weeks, months or years of not
seeing the code, what they wanted to do. Sometimes the programmer, who
is not always an expert in the problem domain, never understood what the
code did. For these reasons, I think that code has to stand on it's own
and should be as readable as possible. And this implies that a standard
can be useful.

Of course, versions must
be strictly separated, for example, by dialects (dialects here are part of
language syntax, rather than other version of "standard").

But I think these ideas map well to each other, one lacking only some
official imprimatur.

I already have answered befor (later in the post you are answering): "what
we can do with perfect language".


I do not want to discuss outside of terms of detected problems. We can not
hide the problems ( for C++ development some the problems already have been
enumerated by me:

- there are problems with expression by C++ existing desing ideas of
existing jobs;

I'm sorry, but I don't understand what this means. Can you find a
different way to express that please? or provide examples.

- there are no _effective_ and _real_ way for _all_ end-users to reflect
their desires to C++;

I'm not sure what you mean by this in practice, but it sounds like an
impossible dream. You can satisfy some of the people all of the time
and all of the people some of the time, but you can't satisfy all of the
people all of the time.

Perhaps you intend that each programmer should have their own perfect
language? Less than useful in the real world, where programs are
written to express ideas to other _people_.

- there are some contradicted "set of terms of conditions" of C++
development, each of them reflects own group of users and we have only one
(selected by certain condition) group supported now;
Specifics?


- there are ways to change the situation;
) by any quotes. If user require something, at least the user will use it,
why not? I agree, that with current state of C++ desing it is not easy (or
even possible) to take in account opinions of all end-users. And i am
speaking about the fact and ways of changing the state.


I know, there are free C++ compilers. Who pays for it?

The people who develop them. Anyone who makes some donation or
otherwise provides remuneration to the people who develop them. In a
more limited sense anyone who takes the time to submit a report or
request to the authors with the intent of improving the compiler.

No, i do not want new language if C++ is not closed one, and is not a
registered trade mark of concrete language, that is developed by concrete
registered persons under concrete registered terms and conditions. It is
not easy to guess is C++ open programming system or private language.

Frankly I don't see the difficulty. Someone elsethread, I think it was
James Kanze, provided information about the standardization process and
how you can become involved.

If i could do all works (even declarative works) with improved C++ myself,
how do you think, did i write here? I think even Stroustup uses some
community to do C++ development.

Honestly, I don't understand why, if you feel this way, you don't simply
start writing proposals. Or start by at least presenting your ideas
here. They are likely to receive a vigorous review and I for one will
probably learn something.

For example, there has already been elsethread some discussion of
pointer types as relates to stack and heap.

LR

 

[jason.cipriani]

[snip]
... Or start by at least presenting your ideas
here. They are likely to receive a vigorous review and I for one will
probably learn something.

For example, there has already been elsethread some discussion of
pointer types as relates to stack and heap.

What I don't understand is why that's the only part of this thread
Grizlyk *didn't* participate in. I think trying to point out ways to
improve his proposals is a lost cause... I'm not sure he actually
wants to talk about the substance of them at all.

 

[Krice]

Otherwise, we are speaking about nothing.

That's what you are doing. C++ is a programming language,
you make programs with it. If you don't like it, use Java
or some other language. You are an extreme example of a person
who just wants to find problems in the language (like there
was nothing else to do). The power of C++ is in the flexibility,
but it's also a source of programming errors. Any good programmers
know that and instead of whining they produce programs the best
way they can, using good programming practices.

So what's the point? Oh, wait, there is no point!
Get a girlfriend and stop whining. Be a man!

 

[James Kanze]

That's what you are doing. C++ is a programming language,
you make programs with it. If you don't like it, use Java
or some other language.

That sounds like the sort of thing he's complaining about. C++
isn't perfect---no programming language is---and this fact is
recognized by the people who know and use C++, from Stroustrup
on down. There's always a willingness to listen to ways to
improve the language. However:

-- They must be clearly and precisely expressed in English that
is at least understandable. If we don't understand what is
really be proposed, we can't judge it.

-- They must take into account, at least to some degree, the
large body of experience already present. There's no point
in proposing things that have already been considered in the
past, and found wanting.

-- They should be based on concrete experience, preferrably
with a proof of concept implementation. C++ is a pragmatic
language, and the committee tends not to consider mere
speculation that such and such a change would improve
things. They want to know exactly how, and what the costs
are. They also want to be sure that it can be implemented.
A proof of concept implementation, with concrete experience
using the modification, is obviously the best (but not the
only) way to handle this.

-- Finally, the proponent should be prepared for open
discussion. C++ is used in many different environments, for
different purposes, and it's users have different criteria
for judging what it an improvement, and what isn't.

Grizlyk's proposals fail to meet the first criterion. My
impression is that they also fail, at least partially, to meet
the others, but to be fair, I can't understand them enough to be
sure.

 

[Thomas J. Gritzan]

I read about the 'movable concept' proposed by Grizlyk and my impression is
this:

The movable concept proposal wants to introduce a new type modifier
'moveable' just like 'const'.
A variable declared as moveable will be assigned and initialized by a move
(destructive read):

> class Z;
> Z a;
> moveable Z b;
>
> //here "move assignment" will be used,
> //because "b" declared as "moveable"
> b = a;
>
> //here "copy assignment" will be used,
> //because "a" declared as "copyable".
> a = b;

I think, that this is a bit reversed, and not by accident, since it appears
in this form multiple times on the site. In the 'r-value reference'
proposal, a moveable variable is an object that can be _moved from_ and not
_moved to_.

I guess that Grizlyk also believes the r-value reference works like this
with another syntax.
I don't know why he wants to introduce such a moveable datatype thing,
since it would be a nightmare to use variables that can only be used until
you assign it to another mutable variable or pass it to a function taking
'moveable' parameters.

Another misconception:

> The "r-value reference" proposal requires, that the state of the source
> after "move" remains in a self consistent state (all internal invariants
> are still intact).
>
> The requirement is theoretically correct (can exist), but practically
> useless one, because even auto_ptr wrapper has other behaviour.
>
> Note, it is very important for auto_ptr that its state after "move"
> became incorrect and user must not have access to auto_ptr during
> incorrect state, because else we can not implement desired behaviour
> of auto memory substitution.

The source object after a move must be in a consistent state, because
otherwise, the destructor would do run into undefined behaviour. Setting
the containted pointer to NULL, for example, is what auto_ptr does, and is
not putting the object into incorrect state.

Another statement found in an old thread[1] in this newsgroup:

> Take a look, we no need _any_ explanations for _any_ C++ programmer
> for the following construction:
>
> class type;
> moveable type foo(const moveable type&);
> type& boo(const type&);
> moveable type& voo(const moveable type);
>
> The construction is clear, useful, orthogonal with ordinary declarations
> and
> upgradeable in future.
>
> And we need tons of the detailed explanations for the following
> construction, that even can not do the same:
>
> class type;
> type&& foo(type&&);
>
> The construction is vague, often useless, conflicts with ordinary
> declarations, can not cover all possible cases (has limited abilities)
> and has no way to upgrade.
>
> The "r-value reference" is worse in comparison with "integrated C++
> moveable" concept.

Without explanation I would not understand both. With explanation what it
actually is (the && and the 'moveable'), I could not imagine what it would
be used for. And now I can't see a use for the first.

[1]
http://objectmix.com/c/40738-constrained-forwarding-r-value-reference-2.html