Heinz Kohl <kohl@informatik.uni-stuttgart.de> writes:

> c) the - often implementation dependend - lifetime of
>    temporary objects. Temporaries may be destroyed after
>    evaluation - there are compilers, which are destroying
>    temporaries after getting a pointer value. Up to now,
>    I haven't seen, what's contrary against that.
>    ca) e.g. in divide(complex (x,y),z) the complex value x+iy
>    may be deleted before entering divide.

That's not true.  The lifetime of temporary objects is not
implementation defined, it is standardized.  It's described in section
12.2 of the draft C++ standard.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bryan Althaus <bryan@panix.com> wrote:
> Why are reading comp.std.c++ then?  People with too
> much time on their hands!
Nice to meet a real programmer.
Nice to see a programmer using C++ on his own will.
Only persons fully agreeing with their software
base will be good users.

James Kuyper wrote:
>> Heinz Kohl wrote:
>> [A long (and oddly formatted) rant against the complexity of C/C++]
> I think that anyone who knows C could sympathize with your complaint.
> However, your message would have been far more useful if you had
> done at
> least one of the following (in order of increasing usefulness):
> 1. Recommended one or more alternative languages that could be used
> instead of C/C++, preferably ones that are good at the same types of
> general purpose low level programming that is the mainstay of C/C++.
Oh, there would be many really nice programming languages.
I'd not argue about C++, if I could use them.
I'm bound to C / C++, because I have to use big programming packets
written in C / C++.
If I take into account not only the concept, but also the chance
on the market, (objectoriented) Ada and Eiffel look like the most
promising languages.
> 2. Pointed out specific defects, and explained why they are defects.
a) the memory concept.
   It seems to be unavoidable to make errors because of that -
   you can guess, that an application is written in C++ because
   of its typical sporadic errors.
b) the - sometimes even implementation dependend! - way of
   implicit copying an object. A COPY OF AN OBJECT IS ANOTHER
   OBJECT! Many possible constructions based on objects
   tends to yield a desaster, if there are unexpected copies.
c) the - often implementation dependend - lifetime of
   temporary objects. Temporaries may be destroyed after
   evaluation - there are compilers, which are destroying
   temporaries after getting a pointer value. Up to now,
   I haven't seen, what's contrary against that.
   ca) e.g. in divide(complex (x,y),z) the complex value x+iy
   may be deleted before entering divide.
   cb) return x; .. if x is a local class member, it may be
    destructed before it can be used
    This problem will be corrected after standardisation of
    C++.
d) a concept based on pointers.
e) an thourougly informal description
   (a different interpretation of C++ by different compilers
    will get different interpretations.
    Example: gnu C++ saw a correct C++-program, translated it,
    the output of the program was correct.
    The same program feeded to HP-C++ gave a translation error
    variable not declared, and after some days I resigned
    to port the program (it was a central variable of a
    base class).

> 3. Suggested ways of fixing the defects.
For your own programs:
   Restrict yourself to a pidgin subset of C++ and
   check, if the result of the translation is as
   expected. Test it on as much C++-implementations
   as possible. Dont expect it will run on another
   implementation, even if you tested it on a dozen
   implementations.
   Strictly avoid any sophisticated use of C++.
   Don't think, C++ is able to encapsulate
   features like an object oriented language -
   C++ is and will stay a mock OO language.
General:
a) software packets written by mathematicians tends to make
   an own memory management because it is shown, that the
   standard one is completely unusable (memory splitting,
   very time consuming).
   This is achieved including some sort of garbage collection,
   making the solution machine dependend (it may be
   necessary to write assembler routines. Yes, its nice
   for me as an old assembler programmer to write such
   routines for different machines without having
   documentation or having thousend pages written
   may be by some teachers without any knowledge of
   hardware, architecture or assemblers)
b) Don't use classes without constructors and
   destructors, even in cases your C++-book says
   you may it.
   I've seen, experienced users tend to avoid
   keywords like 'private', 'protected' and 'constant',
   which are made to avoid errors, but tend to make
   serious trouble.
   (If that wouldn't be the case, it would be very strange
   to see a compiler like Gnu C++ 2.7.2, which sometimes
   forbids a derivation because of the usage of
   'protected', but is allowing it with 'private'!)
c) praying, that the standard will have fixed the
   main problems (but don't really expect it. The
   proposal has some thousand pages, and is formulated
   completely informal. And there's a german saying:
   'too much cooks are ruining the meal').
d) use a better OO-language.
e) make a formal description.
   approach: dont standardize things, which are not
   understood.

Bryan Althaus wrote:
> People with too much time on their hands!
Perhaps he's right, and it's wasting time to want
usable software or even to want software which is
fulfilling the base standards of 1970.
Now I don't have time. I am struggling
because of excellent software - no time even to think
about conceptual problems - I must find and
correct errors.
Don't disturb me.
I've forgotten the existence of ..
comp.std.c++ .. what the hell do you mean with
that silly text?
I'm happy, and all is pretty.

( kohl@informatik.uni-stuttgart.de )
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[I'm not sure whether this is on-topic here.  I've cross-posted to
comp.lang.c++.moderated and set followups there.]

Heinz Kohl <kohl@informatik.uni-stuttgart.de> wrote:
>a) the memory concept.
>   It seems to be unavoidable to make errors because of that -

No.  It can be tedious, but errors are far from unavoidable... there are many
code coverage and memory-checking tools that catch all the usual leaks, double
deletes, past-the-end accesses, null pointer dereferences, use-after-deletes,
etc.  This is all pretty automatable and pretty automated.

>   you can guess, that an application is written in C++ because
>   of its typical sporadic errors.

No.  It's true that some runtime problems tend to be typical of certain
programming language designs.  Pointer and memory runtime errors tend to be
more common in languages that support flexible programmer-controlled memory
management, such as C and C++.  "Does not understand" runtime errors tend to
be more common in languages that support dynamic typing, such as Smalltalk.

Both are serious potential errors, and both are the result of trading off
greater programmer control in return for greater programmer discipline. :-)
That's a language design decision, not a language flaw, especially when tools
support is widely available for both.

>b) the - sometimes even implementation dependend! - way of
>   implicit copying an object. A COPY OF AN OBJECT IS ANOTHER
>   OBJECT!  Many possible constructions based on objects
>   tends to yield a desaster, if there are unexpected copies.

I'm not sure I understand your objection.  If you are used to languages with
only pointer semantics, then yes, moving to a language which also has copy
semantics requires learning the difference.  If your program's correctness
(note: not performance) depends on how many times an object is copied, you
likely have a design problem.

>c) the - often implementation dependend - lifetime of
>   temporary objects. Temporaries may be destroyed after
>   evaluation - there are compilers, which are destroying
>   temporaries after getting a pointer value. Up to now,
>   I haven't seen, what's contrary against that.
>   ca) e.g. in divide(complex (x,y),z) the complex value x+iy
>   may be deleted before entering divide.

No.  Temporaries exist until the end of the full expression.

>   cb) return x; .. if x is a local class member, it may be
>    destructed before it can be used

Only if you return a pointer or reference to a local object, which is
obviously evil.  (That's like deliberately sending a message to a Smalltalk
object that you know it cannot understand, or deliberately dereferencing a
null pointer.  It's intentionally bad programming, not bad language design.)

>    This problem will be corrected after standardisation of
>    C++.

I'm really confused... what problem?

>e) an thourougly informal description
>   (a different interpretation of C++ by different compilers
>    will get different interpretations.
>    Example: gnu C++ saw a correct C++-program, translated it,
>    the output of the program was correct.
>    The same program feeded to HP-C++ gave a translation error
>    variable not declared, and after some days I resigned
>    to port the program (it was a central variable of a
>    base class).

Again, please post an example.  Variable declarations are anything but
informal. :-)  If this problem exists, then it sounds like a compiler problem,
but without code there's no way to be sure.

I've snipped the other points... they seem to be taking issues with things
that, as far as I can see, are misunderstandings of the language and not real
issues.


---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp. (http://www.cntc.com)
2695 North Sheridan Way, Suite 150, Mississauga ON Canada   L5K 2N6
Tel 416-805-9088   Fax 905-822-3824

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]