C++ Archeology: Limits of OO paradigm

[dave_mikesell]

The idea came up to my mind, that can be two standarts - industial and
public (if there is community, who needs public one).

Who's going to write compilers for the ostensibly faster-evolving
public standard? The same companies and organizations who still
haven't fully implemented the 2003 standard? Personally, I like the
fact that C++ is stable and changes with the speed of an glacier.

 

[kwikius]

This is even less than draft page -

I like the parts regarding pointers.
IMO it would be useful if you could
identify whether a pointer was a
pointer to a stack or heap item, or
perhaps more important whether the
object will be automatically cleaned
up, or whether it needs to be manually
cleaned up by the programmer.

regards
Andy Little

 

[LR]

There are tons of examples, i will not list here all of them, only one:

- for "public" language does not matter what employer will think about his
workers.

Ok, one is a good start. Who will care then? In some sense, every
programmer has an employer or at least a customer, someone who pays the
bills, even if the customer is the programmer themselves.

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

My answer and its context means, that many of _correct_ improvements were
rejected only due to incompatibility with "industrial" C++ terms and
conditions instead of incompatibility with true ("public") C++ terms and
conditions.

_correct_? I suggest that this can only be subjective. And this
"public" language is going to have some problems. Would any programmer
take the time to learn a language that is going to have such potential
problems with compatibility. "My code doesn't compile with version..."
is going to be the cri de coeur of every programmer who develops
substantial code with this language. I doubt anyone would want to teach
it in a school, because, I think teachers will doubt their ability to
keep up with the changes.

Sorry, but to my mind, this sounds impractical.

Benefit will be, and we will get in fact two languages, closely related,
but developed under different conditions.

Why is that a benefit?

But the first needed - community - who are stumbled (or even stopped) by
current C++ limitations and will be interested with programming under
improved, but non-industrial C++ development conditions.

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"

For the first, it is interesting for me, are there any other C++ users,
who needs improvements, they are required

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

It is pity, try read original posts, but briefly, i (hope not only i) need
a better C++, improved in accordance with detected problems and existed
jobs and existed desing ways.

That is why i need _effective_ and _real_ way to enumerate, to discuss, to
push into language all things that users want, in spite of "industrial"
requirements.

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.

LR

 

[jason.cipriani]

[ C++ doesn't 100% naturally match the precise way my brain thinks about problems and how a language should be, therefore I am going to spend an inordinate amount of time in my relatively short life attempting to make it fit me. Me, me, me! ]

C++ changes and evolves but it doesn't necessarily go in the direction
a single individual wants it to go in -- even if they *really* want it
to go in that direction.

Why are you insistent on using C++ when it clearly doesn't sit well
with the way you want to program? Have you ever looked into another
language? Many other languages have many similar features to the ones
you are suggesting. There is C#, Java, Objective-C, C--, B, D, classic
Pascal, Delphi, etc. to name some high level ones (I don't claim to
know the ins and outs of any of those languages, I was just listing
them off the top of my head). There are thousands of others. There has
to be one here that is better for you:

http://99-bottles-of-beer.net/

It appears that you put a lot of effort into your suggestions,
Grizlyk. I glanced at your page, and the feeling I got is that you
prefer to spend your time developing complex solutions to problems
that are otherwise easily solved by simply getting used to it. In
other words: you are stubborn (which isn't necessarily a bad thing but
you may be spending too much time on the wrong things). I really think
that you should just use C++ for what it is -- a tool, and if the tool
isn't appropriate for the job that you need to do, then use a
different tool.

Sure you can make improvements to a hammer to make it pound nails more
effectively; but at the same time if you need to turn a screw you are
better off using a screwdriver than trying to change the hammer...

Of course, you could just do what I do and pound the screw in with the
hammer, then swear a lot when you smash your thumb. I'm talking about
reality now -- I have no idea how that part of the metaphor applies to
programming, but my thumb is killing me...

Jason

 

[Jeff Schwab]

[ C++ doesn't 100% naturally match the precise way my brain thinks about problems and how a language should be, therefore I am going to spend an inordinate amount of time in my relatively short life attempting to make it fit me. Me, me, me! ]

I really think
that you should just use C++ for what it is -- a tool, and if the tool
isn't appropriate for the job that you need to do, then use a
different tool.

Sure you can make improvements to a hammer to make it pound nails more
effectively; but at the same time if you need to turn a screw you are
better off using a screwdriver than trying to change the hammer...

Of course, you could just do what I do and pound the screw in with the
hammer, then swear a lot when you smash your thumb. I'm talking about
reality now -- I have no idea how that part of the metaphor applies to
programming, but my thumb is killing me...

Makesithardtohitthespacebar.

 

[jason.cipriani]

I like the parts regarding pointers.
IMO it would be useful if you could
identify whether a pointer was a
pointer to a stack or heap item, or
perhaps more important whether the
object will be automatically cleaned
up, or whether it needs to be manually
cleaned up by the programmer.

WRT this specific idea... I don't really like it. I think the cost far
outweighs the benefit. Basically it takes the place of a code comment
but has type checking.

Cost: All the extra syntax and type-checking he described, on the
compiler side.
Benefit: You catch your delete vs. delete[] vs. free() mistake right
away.

I think a far easier solution to this problem would be to implement as
part of the debugging features of existing IDE's or compilers. For
example, the Microsoft Compiler can generate debug info in the heap
that specifies the source file and line number where memory is
allocated, letting you debug leaks and access violations more
effectively later. I imagine it would be more straightforward for
Microsoft (for example) to also add a flag to allocated debug heap
blocks saying how they were allocated, and then verify the appropriate
method was used when the memory is deallocated.

That is the kind of feature that to me seems more appropriate for a
debugger to deal with. A similar situation is this: There is not
requirement on array bounds checking in the C++ language itself, and I
would not want it -- both for performance reasons (which don't apply
here, of course), and because of the extra complexity it adds to the
language standard and compiler implementations. However, checking
array overruns and underruns is definitely in the domain of the
debugger, and many modern compilers can generate code to check for
overruns and underruns. That kind of check is well-suited to
debuggers, rather than building it into the language.

I think that many of Grizlyk's proposed changes fall into similar
categories.

Jason

 

[Jeff Schwab]

I like the parts regarding pointers.
IMO it would be useful if you could
identify whether a pointer was a
pointer to a stack or heap item, or
perhaps more important whether the
object will be automatically cleaned
up, or whether it needs to be manually
cleaned up by the programmer.

WRT this specific idea... I don't really like it. I think the cost far
outweighs the benefit. Basically it takes the place of a code comment
but has type checking.

Cost: All the extra syntax and type-checking he described, on the
compiler side.
Benefit: You catch your delete vs. delete[] vs. free() mistake right
away.

I think a far easier solution to this problem would be to implement as
part of the debugging features of existing IDE's or compilers. For
example, the Microsoft Compiler can generate debug info in the heap
that specifies the source file and line number where memory is
allocated, letting you debug leaks and access violations more
effectively later. I imagine it would be more straightforward for
Microsoft (for example) to also add a flag to allocated debug heap
blocks saying how they were allocated, and then verify the appropriate
method was used when the memory is deallocated.

That is the kind of feature that to me seems more appropriate for a
debugger to deal with. A similar situation is this: There is not
requirement on array bounds checking in the C++ language itself, and I
would not want it -- both for performance reasons (which don't apply
here, of course), and because of the extra complexity it adds to the
language standard and compiler implementations. However, checking
array overruns and underruns is definitely in the domain of the
debugger, and many modern compilers can generate code to check for
overruns and underruns. That kind of check is well-suited to
debuggers, rather than building it into the language.

Disagree. IMHO, it belongs in language libraries. For example,
checking index overruns in operator[] is trivial to do. I like the
std::vector approach of not requiring operator[] to check bounds, but
providing a separate at() method that throws an exception (which to me
always represents an error).

Who "owns" a dynamically allocated object (and should therefore delete
it) is definitely a matter of convention. I think the compiler already
provides sufficient support for enforcing ownership semantics, though,
so no language change is necessary.

I am really not a fan of spending time in the debugger. If I'm in the
debugger, something wasn't coded correctly in the first place.

 

[Thomas J. Gritzan]

I like the parts regarding pointers.
IMO it would be useful if you could
identify whether a pointer was a
pointer to a stack or heap item, or
perhaps more important whether the
object will be automatically cleaned
up, or whether it needs to be manually
cleaned up by the programmer.

That would be a solution to a problem that is more elegantly solved by
using RAII.

Using smart_ptr<int*> instead of int heap* doesn't require a language
change, can deallocate the memory automatically and is far more flexible
than introducing some new keywords that would not cover all possible
pointer types. (We would not only need auto, stack and heap but also
heap_malloc, heap_pagedpool, heap_nonpagedpool, heap_operatornew, etc.)

 

[James Kanze]

* James Kanze:

[...]

Well, scratch "Big" from "Big Firm" (depends what one means by
that) and add "and/or have a solid economy and/or live in area
of meeting or...".

Well, some one does have to pay for the trip. ISO won't do it
for you. But I know a number of people who attend (or attended)
as independents, sometimes while they were still students.

Do Facebook friends count?

<laughing>

Seriously, I don't know what it means exactly. I participate
via AFNOR (the French national body). Since it didn't really
concern me, it didn't pay too much attention to the
announcement.

No such in e.g. Norway.

First, I'm pretty sure that Norway is a member of ISO (and thus,
has a "national body"). Whether that national body has any
active group in the programming languages section or not is
another question. And I have no idea how you would go about
finding out (or creating such a group if it didn't exist---at
one point, one person did create a working group in his national
body, just to participate).

It's not that important, however, because many of the national
bodies don't require nationality nor residence---I'm pretty sure
that BSI would be happy to sponser you, for example, and all
ANSI requires are that you pay the fees (and that you don't work
for a company that is otherwise a member). (The French national
body is also very open in this regard, but all of our
discussions are in French, which might not be your cup of tea.)

For that matter, given your standing and your representation,
I'm sure that the committee would accept your participation
without your being a member of any national body. You wouldn't
get a vote, but in practice, that doesn't mean much anyway; the
committee tries to work by consensus, and non-voters still get
considered when establishing the consensus.

Well, I think I'm doing my share for the community as clc+m
mod and just helping out here in clc++. Also, have
participated in discussion of at least one proposal, and one
DR, but to be honest I didn't involve myself but was just
involved by others... I wasn't aware of that "friends of the
committee", or forgotten it; thanks for the information, will
think.

The "friends of the committee" status is something new (in the
last six months, I think). But as far as the C++ committee is
concerned, it just formalizes what has long been existing
practice.

Note too that comments here and in clc++m will also be read, and
often be picked up by committee members. If you really care
about some idea, that's obviously not something that you should
count on, but just because you don't participate actively
doesn't mean that you've had no influence.

Anyhow, my point is that the amount of influence you have really
depends on you. One can't complain that the committee is in any
way closed.

 

[James Kanze]

Ok, one is a good start. Who will care then? In some sense,
every programmer has an employer or at least a customer,
someone who pays the bills, even if the customer is the
programmer themselves.

I'm not sure. There are people who program in C++ as a hobby.

Still, the major orientation of C++ is professional. A
"feature" is considered good if it improves programmer
productivity, not if it makes programming more fun. (The IOCCC
is lots of fun, but I certainly don't want to see the techniques
used there become part of standard C++.)

IMHO, this is as it should be. At any rate, the stated goals of
ISO (since there was discussion of standardization earlier)
involve standardization as a means of improving productivity.
I don't think that ISO would accept a proposal to standardize
nethack.

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

_correct_? I suggest that this can only be subjective.

Given the overall level of Grizlyk's English, I'm willing to
suppose that correct is a mis-translation of something else.
Otherwise, of course, it would be incredibly presumptuous.
(Never attribute evil intentions to something that can be
explained equally as well by simple ignorance.)

[...]

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

Often, the question is: what is an improvement? C++ is used in
many different environments, and in many cases, what would be an
improvement for one environment would make the language unusable
elsewhere.

 

[James Kanze]

He has:

http://grizlyk1.narod.ru/cpp_new

But nothing there seems really serious. To start with, I'm not
really sure that I understand the proposals correctly. He
really does need to get the English reviewed by someone who
speaks the language---as it is, I'm never sure that I've
understand what he's trying to say. Then, he needs to learn the
language a bit better---some of his proposals are specious, and
seem to be designed to solve problems which don't exist. (The
idea that the new operator should return some sort of RAII
pointer, for example.) Others are subsumed by proposals that
have already been accepted. (One seemed to correspond to
va-args for templates, which is already part of the working
draft.)

 

[James Kanze]

This is even less than draft page - i have just fastly transated some
records of my notebook into english and the page also reflects results of
dialog about "r-value references".

There are too many records in my notebook (several tens) to be instantly
public and after that all of them requires hard pre-discussion.

I have done the test page to see what will be rather to reach any
predefined result.

Maksim A. Polyaninhttp://grizlyk1.narod.ru/cpp_new

OK. It would have been better if you'd have mentionned this on
the page, so we'd have been aware of it. The English needs
reviewing (but you seem to know that). You have to research
each of the proposals more, including going to the standards
site, and reading what has already been done. I just quickly
glanced at two or three of the proposals: one looks very much
like variable args for templates, which has already been adopted
into the next version of the standard. And either you have to
learn the actual details of the language better, or explain
yourself better, because from what I can understand, some of the
problems you site aren't problems---the operator new *is* an
atomic action, for example, which either succeeds or fails, and
if you write something like:
boost::shared_ptr< SomeType > p( new SomeType ) ;
there is no way memory can leak (provided the constructor of
SomeType is correctly written, of course).

 

[jason.cipriani]

But nothing there seems really serious.

Yeah... that's the vibe I get, too. I had wanted to read over some of
his stuff and talk about it a little (because there was a lot of it
and at first it looked interesting), but I only made it a short way
through before canning that idea. I get the impression his thought
process is something like:

1) Encounter a situation in the language that he does not how to deal
with or that frustrates him.

2) Spend a lot of time and energy coming up with complex solutions
(some well thought out, some not) to these "problems" without
bothering to research if a simple solution already exists.

3) Stubbornly refuse a simple solution, upon finding out about it's
existence, because he has already put so much time into his own work.

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++.

... some of his proposals are specious, and
seem to be designed to solve problems which don't exist. (The
idea that the new operator should return some sort of RAII
pointer, for example.) Others are subsumed by proposals that
have already been accepted. (One seemed to correspond to
va-args for templates, which is already part of the working
draft.)

Jason

 

[red floyd]

I don't think that ISO would accept a proposal to standardize
nethack.

I don't know... they've seemed to accept a proposal to standardize
Microsoft Office.

 

[James Kanze]

This is even less than draft page -

[/QUOTE]

I like the parts regarding pointers.
IMO it would be useful if you could
identify whether a pointer was a
pointer to a stack or heap item, or
perhaps more important whether the
object will be automatically cleaned
up, or whether it needs to be manually
cleaned up by the programmer.

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.

Generally speaking, there's a real tension with regards to
pointers. Java solved it by eliminated all object lifetimes
except dynamic---no local objects, no dangling pointers, no real
value semantics... I don't think that this model fits into the
C++ tradition (and I like having real value semantics.
Pascal didn't go that far, but did require that pointers only
point to dynamically allocated objects---in C++ terms, a pointer
could only be initialized with a new expression or another
pointer. That could be considered in C++, but given the amount
of existing code it would break, I don't think it's going to go
over very well. I think, in practice, it would probably not
break very much well written code. In practice, however, there
is a lot of code that works, and that shouldn't be broken, even
if it isn't well written, and in practice, there's also a very
big difference between "not very much" and "none". And in
practice, C compatibility is also an issue, which means
supporting pointers in a lot of places where pure C++ code would
use a reference. If we were going to "improve" pointer safety,
however, I think it's the route I'd go, but if nothing else, the
loss of C compatibility would kill it for me. (Would you really
accept dynamic allocation every time the Posix API uses a
pointer?)

 

[Thomas J. Gritzan]

And either you have to
learn the actual details of the language better, or explain
yourself better, because from what I can understand, some of the
problems you site aren't problems---the operator new *is* an
atomic action, for example, which either succeeds or fails, and
if you write something like:
boost::shared_ptr< SomeType > p( new SomeType ) ;
there is no way memory can leak (provided the constructor of
SomeType is correctly written, of course).

I think he meant something like this:

typedef boost::shared_ptr<SomeTypeA> ptrA;
typedef boost::shared_ptr<SomeTypeB> ptrB;

some_function( ptrA(new SomeTypeA), ptrB(new SomeTypeB) );

The compiler could execute both 'new's, then construct the smart pointers.

 

[LR]

I'm not sure. There are people who program in C++ as a hobby.

I'm not sure that it's relevant that the programming is done as a hobby.

Perhaps we ought to make a different distinction.

On the one hand having a typical code base, where the code is used for
some purpose, where purpose is defined by the author or customer or
employer or whomever.

On the other hand, where the code exists only for itself, so to speak,
and has no other useful purpose, and the loss of it, through for example
not having a compiler available because the language is frequently
'improved', will have no other impact.

The size of the code base might not be relevant here, and we could have
two code bases that are exactly the same, but because of the above
distinction the loss of one isn't bothersome, while the loss of the
other might be to someone.

And yes, there will of course be limits to this distinction.

Still, the major orientation of C++ is professional. A
"feature" is considered good if it improves programmer
productivity, not if it makes programming more fun. (The IOCCC
is lots of fun, but I certainly don't want to see the techniques
used there become part of standard C++.)

Quite right too.

IMHO, this is as it should be. At any rate, the stated goals of
ISO (since there was discussion of standardization earlier)
involve standardization as a means of improving productivity.
I don't think that ISO would accept a proposal to standardize
nethack.

That would be quite an, um, adventure.

Given the overall level of Grizlyk's English, I'm willing to
suppose that correct is a mis-translation of something else.

Yes. I suppose that his use of the phrase "kinder tale" was a give away
for that. It's clear that he doesn't have a grasp of English idiom, and
that does make communication a bit more difficult.

Otherwise, of course, it would be incredibly presumptuous.

It would be, but I think there's enough wiggle room in my use too, to
allow whatever he meant. Even if he meant something like "better" or
"useful".

(Never attribute evil intentions to something that can be
explained equally as well by simple ignorance.)

Depends on the evidence.

[...]

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

Often, the question is: what is an improvement?

Ok, that's probably a better, more correct, more useful, question.

C++ is used in
many different environments, and in many cases, what would be an
improvement for one environment would make the language unusable
elsewhere.

Which would likely be an unacceptable cost, even if you're a hobbyist.


LR

 

[Puppet_Sock]

He has:

http://grizlyk1.narod.ru/cpp_new

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 can re-write new and delete
if you really want them to behave in some other way.
If you don't like doing resource management the
"standard" way then you can certainly do it some
other way, smart pointers, reference counting, etc.
Many of these things are available as free downloads
(or downloads for very small amounts of cash) at such
places as boost.
Socks

 

[James Kanze]

James Kanze wrote:

I don't know... they've seemed to accept a proposal to standardize
Microsoft Office.

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).

 

[James Kanze]

I think he meant something like this:

typedef boost::shared_ptr<SomeTypeA> ptrA;
typedef boost::shared_ptr<SomeTypeB> ptrB;

some_function( ptrA(new SomeTypeA), ptrB(new SomeTypeB) );

The compiler could execute both 'new's, then construct the
smart pointers.

OK. So it's not so much an atomic new expression he wants, as
full ordering for expressions. I'm with him
there---independently of the wisdom of using such expressions
(and in this particular case, I think the use would be
reasonable if it worked), reproduceability is an important
feature for testing.

If this is the case, however, the words he used (atomic new)
were very poorly chosen.