Python is an object oriented langage (OOL). The Python main 
implementation is written in pure and "old" C90. Is it for historical 
reasons?

C is not an OOL and C++ strongly is. I wonder if it wouldn't be more 
suitable to implement an OOL with another one.

Has it ever been planned to rewrite in C++ the historical implementation 
(of course in an object oriented design) ?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCBC54DE11F667B92ED5A4193
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8/1/10 4:08 PM, candide wrote:
> Python is an object oriented langage (OOL). The Python main
> implementation is written in pure and "old" C90. Is it for historical
> reasons?

Portability if nothing else has been a strong reason to keep the Python
implementation to standard C. Its not as bad as it used to be, but
there's still quite a few differences between various C++ compilers.
Even with the officially supported platforms shrinking of late, and talk
of including some C++ in an isolated part of the CPython implementation
(the UnladenSwallow JIT is C++, IIRC), rewriting the whole thing in C++
seems like a major waste of time.

If you went and used the OO-features of C++, but then you run into a
problem: Python's OO design is strikingly different from C++'s. There's
no enforced encapsulation (on purpose), just as one example.

That's not saying you -couldn't- match Python's OO design on top of C++,
after all-- they've done it in Java, which has a hardcore interpretation
of OOP. But what does that get you over the current status quo? C's
leaner and meaner then C++.

> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
> suitable to implement an OOL with another one.

Wny would this be more suitable? The Python idea of Object Orientedness
doesn't line up with the C++ own *on purpose*, so why adopt one idea and
design of OOP to implement a different one?

> Has it ever been planned to rewrite in C++ the historical implementatio=
n
> (of course in an object oriented design) ?

Have you actually looked at the "historical implementation"? It's
actually quite object oriented. You don't have to have an object
oriented language to use OO design.

--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enigCBC54DE11F667B92ED5A4193
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMVgi4AAoJEKcbwptVWx/lKrUH/2oux+qU64gFQTubao9jOGyq
o9kSr6+392c30VFCtVcBxRh/RZVRrz4FUqAV+a3s+EfMemAdF7e+GVeJ6nFJrPav
tpQcxkKeBGExpAxu7DUUoQWK+f1wyPjB0Ct5xUCaKAFEnha0c2rU+n5xfbRiaXKM
LPvvxXvkf+6F9Q4l5waalniJnA8yZ+yt7OAnOSKPap6HDbggLWNScrInVjaYzag8
CSpCPPCmuzzmYHi5V7HH1SX4Ed5jcB0MEYxw15b8l6OKc3tY4WHQJlhwU4f/A8zN
uwwV7xc7QU5PrZay/g1T03e4hJJuQXUTqQ4bQs8ysXUx7gY5xMSXAW199JFBP8U=
=+o4d
-----END PGP SIGNATURE-----

--------------enigCBC54DE11F667B92ED5A4193--

On 8/1/2010 7:08 PM, candide wrote:
> Python is an object oriented langage (OOL). The Python main
> implementation is written in pure and "old" C90. Is it for historical
> reasons?

Python was first released before C++. C is available on, and hence 
Python runs on, systems that do not have C++ available.

> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
> suitable to implement an OOL with another one.

Python's object system is sufficiently different from that of C++ that I 
doubt the latter could used with much profit.

> Has it ever been planned to rewrite in C++ the historical implementation
> (of course in an object oriented design) ?

Proposed and rejected. Not every C programmer knows or wants to learn C++.

-- 
Terry Jan Reedy

In article <4c55fe82$0$9111$426a34cc@news.free.fr>,
 candide <candide@free.invalid> wrote:

> Python is an object oriented langage (OOL). The Python main 
> implementation is written in pure and "old" C90. Is it for historical 
> reasons?
> 
> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more 
> suitable to implement an OOL with another one.

One thing that comes to mind is that it's much easier to distribute C 
libraries than C++ libraries.

If I compile a main program with one C compiler and you compile a 
dynamically loaded library with another C compiler on the same box, the 
odds are pretty good they'll interoperate without any problems.

Not at all so with C++ compilers.  The linkage is *way* more 
complicated.  Not just how the two compilers do name mangling, but how 
they handle exceptions, RVO, and a zillion other details.  Pretty much 
the only way to make it work is to compile everything with exactly the 
same compiler.  That would make it pretty close to impossible for people 
to take a Python core distribution and add their own extension modules 
to it.

Terry Reedy <tjreedy@udel.edu> writes:

> On 8/1/2010 7:08 PM, candide wrote:
>> Python is an object oriented langage (OOL). The Python main
>> implementation is written in pure and "old" C90. Is it for historical
>> reasons?
>
> Python was first released before C++. 

C++ was named C++ in 1983 (development on it started in 1979) and the
first commercial implementation was released in 1985 [1]. Implementation
of Python started in December 1989 [2].

So: no. (I was quite sure on this, since I started to program in C++ in
the late 80's/early 90's IIRC).

[1] 
 http://en.wikipedia.org/wiki/C_plus_plus#History 

[2]
 http://en.wikipedia.org/wiki/Python_%28programming_language%29#History
 http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Roy Smith <roy@panix.com> writes:

> In article <4c55fe82$0$9111$426a34cc@news.free.fr>,
>  candide <candide@free.invalid> wrote:
>
>> Python is an object oriented langage (OOL). The Python main 
>> implementation is written in pure and "old" C90. Is it for historical 
>> reasons?
>> 
>> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more 
>> suitable to implement an OOL with another one.
>
> One thing that comes to mind is that it's much easier to distribute C 
> libraries than C++ libraries.

In the beginning of C++ there were programs that just converted C++ to C
(frontends). At least that is how the C++ compiler Acorn sold worked.
So I don't think your argument was much true back then.

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Am 02.08.2010 01:08, schrieb candide:
> Python is an object oriented langage (OOL). The Python main 
> implementation is written in pure and "old" C90. Is it for historical 
> reasons?

Python is written in C89 to support as many platforms as possible. We
deliberately don't use any new features and almost no compiler specific
extensions to make the interpreter portable. AFAIK the only compiler
specific feature used in Python are computed gotos and they are optional.

> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more 
> suitable to implement an OOL with another one.
> 
> Has it ever been planned to rewrite in C++ the historical implementation 
> (of course in an object oriented design) ?

I like to say that the Python interpreter is written in object oriented
C code. Every Python object evolved around PyObject and PyType structs
that are extended (subclassed) to add additional members. Python won't
gain anything useful from a pure C++ implementation. C++ would only add
a major layer of complexity and scary features.

In your opinion what would Python gain from a C++ implementation?

Christian

On Sun, 1 Aug 2010, John Bokma wrote:

> In the beginning of C++ there were programs that just converted C++ to C
> (frontends). At least that is how the C++ compiler Acorn sold worked.
> So I don't think your argument was much true back then.

Those that I (tried to) used on Amiga were based around the same concept.

It seems, that Comeau C++ compiler (which I never tried) still requires C 
compiler as a backend (and is highly regarded by some).

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

On Aug 1, 6:09=A0pm, John Bokma <j...@castleamber.com> wrote:
> Roy Smith <r...@panix.com> writes:
> > In article <4c55fe82$0$9111$426a3...@news.free.fr>,
> > =A0candide <cand...@free.invalid> wrote:
>
> >> Python is an object oriented langage (OOL). The Python main
> >> implementation is written in pure and "old" C90. Is it for historical
> >> reasons?
>
> >> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
> >> suitable to implement an OOL with another one.
>
> > One thing that comes to mind is that it's much easier to distribute C
> > libraries than C++ libraries.
>
> In the beginning of C++ there were programs that just converted C++ to C
> (frontends). At least that is how the C++ compiler Acorn sold worked.
> So I don't think your argument was much true back then.

No, it was that way back then too.  They might all generate C code but
different C code by different backends wouldn't be able to call each
other natively.

For instnace the function

int foo(int);

might be name-mangled this way in one cfront:

foo$d

and this way in another:

____int_foo__int_i


The virtual table of this class:

class Bar {
    virtual int foo(int);
    virtual int bar(int);
};

might be generated like this in one cfront:

struct Bar$$Vtable$ {
    int (*Bar$$bar$d)(int);
    int (*Bar$$foo$d)(int);
};

and like this in another:

struct ____class_Foo___vtable_ {
    int (*foo)(int);
    int (*bar)(int);
};


So, just because they both generated C code, it doesn't mean they can
call one another.


Carl Banks

On Mon, 2010-08-02 at 01:08 +0200, candide wrote:
> Python is an object oriented langage (OOL). The Python main 
> implementation is written in pure and "old" C90. Is it for historical 
> reasons?
> 
> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more 
> suitable to implement an OOL with another one.
> 
> Has it ever been planned to rewrite in C++ the historical implementation 
> (of course in an object oriented design) ?

Disclaimer: I am neither a C nor C++ programmer.  In fact I can barely
even program in Python ;-)

I would propose that in fact most programming languages are implemented
in C.  Sun's (Oracle's) Java compiler and runtime are written in ANSI C.
The core of the Gnu Compiler Collection (which includes C++ and
Objective-C compilers) is written in C.  The official Ruby is
implemented in C. The Squeak Smalltalk implementation uses C instead of
C++.  I can't even think of a programming language that is implemented
in C++ (maybe C++ is).

C seems to be a good, portable language for writing interpreters and
compilers.

But I wonder if someone has/has tried to write a programming language in
C++ and what were their experiences.

On Sun, 1 Aug 2010, Albert Hopkins wrote:

> C seems to be a good, portable language for writing interpreters and
> compilers.

And one should not forget about performance. C++ was for a long time 
behind C, and even now some parts (like iostreams) should be avoided in 
fast code.

BTW, C++ can be IMHO a bit tricky in situations when one would like to 
call back from JIT-generated code into parts written in C++... I mean 
things like virtual functions, overloading, code generated from templates, 
accessing private members etc. All those issues are non essential from the 
point of interpreting or JIT, yet they stand in a way. While this could be 
solved (with some headache, I suspect), C is far simpler and function 
calls or manipulating structs are actually trivial...

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

On 08/01/2010 07:09 PM, John Bokma wrote:
>> One thing that comes to mind is that it's much easier to distribute C 
>> libraries than C++ libraries.
> 
> In the beginning of C++ there were programs that just converted C++ to C
> (frontends). At least that is how the C++ compiler Acorn sold worked.
> So I don't think your argument was much true back then.

No, he is still right.  Each C++ implementation did name mangling
differently leading to "C" libraries that had incompatible names and
signatures.  Also each frontend could have generated incompatible
vtables and other C++ structures.  So C code generated by one C++
frontend could not easily call C code generated by another C++ frontend.
 So the same arguments that are made about C++ now were just as valid
back then when C++ was merely a fancy preprocessor.

On Sun, 2010-08-01 at 20:01 -0400, Terry Reedy wrote:
> Not every C programmer knows or wants to learn C++.

I think Terry is the only person that's mentioned this - but I'd like to
give extra support to it - I for one prefer C to C++ (as someone that
writes quite a lot of C extension modules).

And as Stephen mentioned - just because C is not an OO language, doesn't
mean you can't write OO code in it - you just have to pass an instance
of the class method is defined on in as the first parameter (like you do
in Python).


Tim

On 2010-08-02, Christian Heimes <lists@cheimes.de> wrote:

> In your opinion what would Python gain from a C++ implementation?

Greater buzzword-compliance -- an important characteristic highly
prized by Human-Resources poeple and mid-level managers here in the
US.

;)

-- 
Grant

On Mon, Aug 2, 2010 at 10:20 AM, Christian Heimes <lists@cheimes.de> wrote:

>
> In your opinion what would Python gain from a C++ implementation?

The elusive advantages of "OO" in C++ are relatively minor compared to
RIIA which would make reference counting much easier to deal with. But
even that is not a strong enough argument for C++. The little C++ we
have in scipy had causes a lot of headache - C++ portability is still
an issue once you are outside the 4-5 main OS/Compilers combinations,

David

On 08/02/2010 04:42 PM, Grant Edwards wrote:
> On 2010-08-02, Christian Heimes <lists@cheimes.de> wrote:
> 
>> In your opinion what would Python gain from a C++ implementation?
> 
> Greater buzzword-compliance -- an important characteristic highly
> prized by Human-Resources poeple and mid-level managers here in the
> US.
> 
> ;)
> 

C++Python would never beat IronPython on that front

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/01/2010 07:34 PM, Albert Hopkins wrote:
> On Mon, 2010-08-02 at 01:08 +0200, candide wrote:
>> Python is an object oriented langage (OOL). The Python main 
>> implementation is written in pure and "old" C90. Is it for historical 
>> reasons?
>>
>> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more 
>> suitable to implement an OOL with another one.
>>
>> Has it ever been planned to rewrite in C++ the historical implementation 
>> (of course in an object oriented design) ?
> 
> Disclaimer: I am neither a C nor C++ programmer.  In fact I can barely
> even program in Python ;-)
> 
> I would propose that in fact most programming languages are implemented
> in C.  Sun's (Oracle's) Java compiler and runtime are written in ANSI C.
> The core of the Gnu Compiler Collection (which includes C++ and
> Objective-C compilers) is written in C.  The official Ruby is
> implemented in C. The Squeak Smalltalk implementation uses C instead of
> C++.  I can't even think of a programming language that is implemented
> in C++ (maybe C++ is).
> 
> C seems to be a good, portable language for writing interpreters and
> compilers.
> 
> But I wonder if someone has/has tried to write a programming language in
> C++ and what were their experiences.
> 

(Sorry if this is a double post, but apparently my last one didn't go
through.)

I know that LOLCode has a .NET implementation (1), although it's "very
much alpha."  And someone was apparently working on a C++ only
implementation of LOLCode (2), although that was 3 years ago.

LOLCode itself is very much alpha anyway and development seems to be
very slow (or dead.)

Python has a way of extending it's modules with C or C++ (3).

1: http://lolcode.com/implementations/lolcode.net
2: http://forum.lolcode.com/viewtopic.php?id=14
3: http://docs.python.org/release/2.5.2/ext/intro.html

- -- 
People should read more.
https://secure.wikimedia.org/wikipedia/en/wiki/User:MithrandirAgain
"All that is gold does not glitter,
not all those who wander are lost;
the old that is strong does not wither,
deep roots are not reached by the frost.
- From the ashes a fire shall be woken,
a light from the shadows shall spring;
renewed shall be blade that was broken,
the crownless again shall be king."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMVyNqAAoJEKo37V1xH7gTeOUH/2/KYc4busZbATSB09ZUgW+v
BmydxDTZaPQd0B56JWSeUiz0/kZrufdDrVc3XUTNNF2oa8ExW51IgsaZOxn2UJGv
ydplycT1axs5hrzDG72v2Oo7/poPDxSsvpF58dBsb0XSI25I+orHKrTQpwvKz9cf
x6nzahUoygTbaVqZUyxCW2Tc7Rv4T2gpskssD8sIYqaRNofNnPbf3h3NA+q4LMkR
+F2UF3r1RE1jwJhs6RNAvUJBdLrHkA3isRsjQE38l6AioLdeTs2yrRtc+6xUkAig
RxR11qLZl5OOer/Jrmg1My0+ZTYGnIcAfChxPh1YnHuYbp+H7doqLjlKIkoXZms=
=F9Ou
-----END PGP SIGNATURE-----

On 02/08/2010 00:08, candide wrote:
> Python is an object oriented langage (OOL). The Python main
> implementation is written in pure and "old" C90. Is it for historical
> reasons?
>
> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
> suitable to implement an OOL with another one.
>
> Has it ever been planned to rewrite in C++ the historical implementation
> (of course in an object oriented design) ?

I can't understand why any serious programmer mentions C++. As soon as I 
read it, I have to rush either to the kitchen to find a bowl to throw up 
in, or head for the toilet so I can talk to the great white telephone.

Kindest regards.

Mark Lawrence.

On Aug 3, 7:42=A0am, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
> On 02/08/2010 00:08, candide wrote:
<snip>
>
> I can't understand why any serious programmer mentions C++. As soon as I
> read it, I have to rush either to the kitchen to find a bowl to throw up
> in, or head for the toilet so I can talk to the great white telephone.
>
> Kindest regards.
>
> Mark Lawrence.

With you there Mark - IMO C++ is an abortion that should never have
seen the light of day. The idea of experimenting with creating an OO
language by extending C wasn't such a bad idea for a "play thing" (by
Stroustrop) but the fact that it somehow escaped from the Lab and
people picked it up and ran with it on a commercial basis is just
plain wrong!

Personally I liken it to one of those genetically engineered diseases
they play around with in biological warfare labs - and unfortunately
this one escaped! It has probably set the computing industry back
untold years in terms of advancement...

Unfortunately I am forced to use it in my day to day life, but at the
end of every day I go home and use a purgative to get it out of my
system. But there are many deluded youngsters out there who just don't
seem to know any better, but then the signs of the breakdown of
society surround us on a daily basis and I guess C++ is just another
signpost on the way...

Peter

On 08/02/2010 03:42 PM, Mark Lawrence wrote:
> I can't understand why any serious programmer mentions C++. As soon as I 
> read it, I have to rush either to the kitchen to find a bowl to throw up 
> in, or head for the toilet so I can talk to the great white telephone.

Sometimes, C++ is just the right tool for the job, despite all its
warts.  For example, programming GTK apps with GTKmm in C++ is way more
pleasant than using C (but nowhere as pleasant as Python).  C++'s object
semantics (guaranteed destruction, scoping, etc) can sometimes work very
well when you need the speed of a compiled language, but don't want to
be quite as low-level as C.

In this case, C++ is certainly not a better tool for the job than C.
But plenty of serious programmers know how to leverage C++ and do so
quite successfully.  Just because C++ makes you ill in no way proves
that C++ is unfit for certain purposes.

On 2 Aug, 01:08, candide <cand...@free.invalid> wrote:

> Has it ever been planned to rewrite in C++ the historical implementation
> (of course in an object oriented design) ?

OO programming is possible in C.  Just take a look at GNOME and GTK.

Perl is written in C++. That is not enough to make me want to use
it ;)

To be honest, C++ can be a great tool. But very few know how to use it
correctly. C++ textbooks are also written by people who don't
understand the language, and teach bad habits. The typical examples
revealing incompetence are use of new[] instead of std::vector, and
dynamic resourse allocation outside contructors.

C++ compilers used to be bloatware generators; C++ compilers of 2010
are not comparable to those of 1990. C++ is also a PITA for
portability. It is not sufficient for Python to only build with
Microsoft Visual Studio.

Michael Torrie <torriem@gmail.com> writes:
> Sometimes, C++ is just the right tool for the job, despite all its
> warts....  C++'s object semantics (guaranteed destruction, scoping,
> etc) can sometimes work very well when you need the speed of a
> compiled language, but don't want to be quite as low-level as C.
> 
> In this case, C++ is certainly not a better tool for the job than C.

The stuff C++ adds to C is a mix of good and bad, and it's reasonably
possible to use just the good stuff and ignore the bad.  At that point
you've got a pure improvement over C, although a lot of C's shortcomings
can't be papered over and still remain.

Certain folks in the functional-programming community consider OO to be
a 1980's or 1990's approach that didn't work out, and that what it was
really trying to supply was polymorphism.  C++ programs these days
apparently tend to use template-based generics rather than objects and
inheritance for that purpose.  

I've never programmed in Ada but I'm intrigued by these articles:

  http://adahome.com/Ammo/cpp2ada.html 
  http://www.adaic.org/whyada/ada-vs-c/cada_art.html

I have the impression that Ada has an undeservedly bad rap because of
its early implementations and its origins in military bureaucracy.  I'd
certainly consider it as an alternative to C or C++ if I had to write a
big program in a traditional procedural language.

On 2 Aug, 05:04, Tomasz Rola <rto...@ceti.pl> wrote:

> And one should not forget about performance. C++ was for a long time
> behind C, and even now some parts (like iostreams) should be avoided in
> fast code.

For fast I/O one must use platform specific APIs, such as Windows' i/o
completion ports and memory mapping.

iostreams in C++ and stdio in C are ok for less demanding tasks.

On 3 Aug, 00:27, Paul Rubin <no.em...@nospam.invalid> wrote:

> Certain folks in the functional-programming community consider OO to be
> a 1980's or 1990's approach that didn't work out, and that what it was
> really trying to supply was polymorphism. =A0C++ programs these days
> apparently tend to use template-based generics rather than objects and
> inheritance for that purpose. =A0

It avoids virtual function calls at the expense of unreable code and
errors that are nearly impossible to trace. It seems many thinks this
is a good idea because Microsoft did this with ATL and WTL. There are
also those who thinks template metaprogramming is a good idea. But who
uses a C++ compiler to dumb to unroll a for loop? In my experience,
trying to outsmart a modern compiler is almost always a bad idea.

> I have the impression that Ada has an undeservedly bad rap because of
> its early implementations and its origins in military bureaucracy. =A0

It is annyingly verbose, reminds me of Pascal (I hate the looks of
it), and is rumoured to produce slow bloatware. And don't forget
Ariane 5 ;)


> I'd
> certainly consider it as an alternative to C or C++ if I had to write a
> big program in a traditional procedural language.

I still prefer Fortran 95 :-)

In article <f9e652d6-3945-4c18-92f3-b85b994feb0b@k8g2000prh.googlegroups.com>,
Peter  <peter.milliken@gmail.com> wrote:
>On Aug 3, 7:42=A0am, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
>> On 02/08/2010 00:08, candide wrote:
>>
>> I can't understand why any serious programmer mentions C++. As soon as I
>> read it, I have to rush either to the kitchen to find a bowl to throw up
>> in, or head for the toilet so I can talk to the great white telephone.
>
>With you there Mark - IMO C++ is an abortion that should never have
>seen the light of day. The idea of experimenting with creating an OO
>language by extending C wasn't such a bad idea for a "play thing" (by
>Stroustrop) but the fact that it somehow escaped from the Lab and
>people picked it up and ran with it on a commercial basis is just
>plain wrong!

http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..."  --Siobhan

On Mon, 02 Aug 2010 15:54:52 -0700, sturlamolden wrote:

> On 3 Aug, 00:27, Paul Rubin <no.em...@nospam.invalid> wrote:
> 
>> Certain folks in the functional-programming community consider OO to be
>> a 1980's or 1990's approach that didn't work out, and that what it was
>> really trying to supply was polymorphism.  C++ programs these days
>> apparently tend to use template-based generics rather than objects and
>> inheritance for that purpose.
> 
> It avoids virtual function calls at the expense of unreable code and
> errors that are nearly impossible to trace. It seems many thinks this is
> a good idea because Microsoft did this with ATL and WTL. There are also
> those who thinks template metaprogramming is a good idea. But who uses a
> C++ compiler to dumb to unroll a for loop? In my experience, trying to
> outsmart a modern compiler is almost always a bad idea.
> 
>> I have the impression that Ada has an undeservedly bad rap because of
>> its early implementations and its origins in military bureaucracy.
> 
> It is annyingly verbose, reminds me of Pascal (I hate the looks of it),
> and is rumoured to produce slow bloatware. 

> And don't forget Ariane 5 ;)
> 
This had nothing to do with Ada per se and everything to do with 
shortcuts:

- re-use of an Ariane 4 component without changing its parameters
  to match the Ariane 5 flight profile
- not removing Ariane 4-only code intended to handle launch holds
  and not used at all in Ariane 5
- a programming fault that allowed an exception code to be sent
  to another component as if it was valid data.

Inadequate testing allowed all these to be flown without finding the 
errors.

Bottom line: All this would still have happened regardless of the 
programming language used. However, don't just listen to me: read the 
final report on Ariane 501 here: 

http://www.di.unito.it/~damiani/ariane5rep.html


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 3 Aug, 01:14, Martin Gregorie <mar...@address-in-sig.invalid>
wrote:

> Bottom line: All this would still have happened regardless of the
> programming language used.

I am quite sure C and Fortran makes it unlikely for an unhandled
exception to trigger the autodestruct sequence. But it's nice to know
when flying that modern avionics is programmed in a language where
this is possible.

;)

On 03/08/2010 00:03, Aahz wrote:
> In article<f9e652d6-3945-4c18-92f3-b85b994feb0b@k8g2000prh.googlegroups.com>,
> Peter<peter.milliken@gmail.com>  wrote:
>> On Aug 3, 7:42=A0am, Mark Lawrence<breamore...@yahoo.co.uk>  wrote:
>>> On 02/08/2010 00:08, candide wrote:
>>>
>>> I can't understand why any serious programmer mentions C++. As soon as I
>>> read it, I have to rush either to the kitchen to find a bowl to throw up
>>> in, or head for the toilet so I can talk to the great white telephone.
>>
>> With you there Mark - IMO C++ is an abortion that should never have
>> seen the light of day. The idea of experimenting with creating an OO
>> language by extending C wasn't such a bad idea for a "play thing" (by
>> Stroustrop) but the fact that it somehow escaped from the Lab and
>> people picked it up and ran with it on a commercial basis is just
>> plain wrong!
>
> http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

Haven't been able to read this properly as the stomach has been shaking 
too much to control the mouse and/or arrow keys/page up/down etc.  Hum, 
marks out of 10, 1.649072354865927**trillions.  For the cryptographers, 
is this a decent random number?

Kindest regards.

Mark Lawrence

On 03/08/2010 00:14, Martin Gregorie wrote:
> On Mon, 02 Aug 2010 15:54:52 -0700, sturlamolden wrote:
>
>> On 3 Aug, 00:27, Paul Rubin<no.em...@nospam.invalid>  wrote:
>>
>>> Certain folks in the functional-programming community consider OO to be
>>> a 1980's or 1990's approach that didn't work out, and that what it was
>>> really trying to supply was polymorphism.  C++ programs these days
>>> apparently tend to use template-based generics rather than objects and
>>> inheritance for that purpose.
>>
>> It avoids virtual function calls at the expense of unreable code and
>> errors that are nearly impossible to trace. It seems many thinks this is
>> a good idea because Microsoft did this with ATL and WTL. There are also
>> those who thinks template metaprogramming is a good idea. But who uses a
>> C++ compiler to dumb to unroll a for loop? In my experience, trying to
>> outsmart a modern compiler is almost always a bad idea.
>>
>>> I have the impression that Ada has an undeservedly bad rap because of
>>> its early implementations and its origins in military bureaucracy.
>>
>> It is annyingly verbose, reminds me of Pascal (I hate the looks of it),
>> and is rumoured to produce slow bloatware.
>
>> And don't forget Ariane 5 ;)
>>
> This had nothing to do with Ada per se and everything to do with
> shortcuts:
>
> - re-use of an Ariane 4 component without changing its parameters
>    to match the Ariane 5 flight profile
> - not removing Ariane 4-only code intended to handle launch holds
>    and not used at all in Ariane 5
> - a programming fault that allowed an exception code to be sent
>    to another component as if it was valid data.
>
> Inadequate testing allowed all these to be flown without finding the
> errors.
>
> Bottom line: All this would still have happened regardless of the
> programming language used. However, don't just listen to me: read the
> final report on Ariane 501 here:
>
> http://www.di.unito.it/~damiani/ariane5rep.html
>
>
A bug is a bug is a bug?

Except in my code.  Never written a bug in my life.  Cross my heart and 
hope to die.  Of course I'm lying. :)

Kindest regards.

Mark Lawrence.

On 3 Aug, 01:37, Mark Lawrence <breamore...@yahoo.co.uk> wrote:

> A bug is a bug is a bug?

According to Grace Hopper, a bug might be a moth, in which case the
best debugger is a pair of forceps.

Am 03.08.2010 01:03, schrieb Aahz:
> http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

I don't understand why the URL contains the word "joke". Every word is
true. Hell yeah! :)

Christian

On Mon, Aug 2, 2010 at 3:18 PM, sturlamolden <sturlamolden@yahoo.no> wrote:
>
> Perl is written in C++. That is not enough to make me want to use
> it ;)

I realize this was meant to be funny, but it's not true, and detracts
from the point you were trying to make.  Maybe skip the pointless jabs
at Perl and stick to things you know more about.

On Aug 3, 8:27=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
<snip>...
>
> Certain folks in the functional-programming community consider OO to be
> a 1980's or 1990's approach that didn't work out, and that what it was
> really trying to supply was polymorphism. =A0C++ programs these days
> apparently tend to use template-based generics rather than objects and
> inheritance for that purpose. =A0
>
> I've never programmed in Ada but I'm intrigued by these articles:
>
> =A0http://adahome.com/Ammo/cpp2ada.html
> =A0http://www.adaic.org/whyada/ada-vs-c/cada_art.html
>
> I have the impression that Ada has an undeservedly bad rap because of
> its early implementations and its origins in military bureaucracy. =A0I'd
> certainly consider it as an alternative to C or C++ if I had to write a
> big program in a traditional procedural language.

I used to work for defence contractors - Ada (IMO :-)) is the very
best OO language for real-time and embedded systems. It scales
fantastically well to large, multi-platform jobs as well. If I had my
way we would use it where I work now (biomedical field) but that isn't
an option - too many folk are brought up on a steady diet of C/C++ and
therefore don't know any better, plus there is a dearth of Ada
compilers for the CPU's that we use here (all embedded work). I have
used fortran, C, C++, some Java, Ada (and Python :-)), if I had my
choice for the type of programming I do here at work, it would
definitely go to Ada by a country mile.

Having said that though, I won't replace Python with it on my desktop
for the type of stuff I do around the fringes of my job (test scripts
etc) and my personal programming :-)

But for anyone who wants to expand their horizons, learning Ada would
be an excellent choice (although like any learning activity, unless
you have a concrete goal in mind you will probably just waste your
time :-)). It is not an easy language to just pick up and run with
because the strong type-checking FORCES you to think about and design
your program very carefully from the very beginning - something that
many programmers find an abhorrence for :-) But I always used to tell
people - by the time I got a program to compile then I figured 99% of
the bugs were already discovered! Try that with C/C++ or almost any
other language you care to name :-)

Peter

sturlamolden <sturlamolden@yahoo.no> writes:
> It is annyingly verbose, reminds me of Pascal (I hate the looks of
> it), and is rumoured to produce slow bloatware. 

The earliest Ada compilers were terrible, but they are about like C
compilers now, so the output code is ok (see Alioth shootout for
example).  I agree about the verbosity but I don't think that's too big
a problem in the sorts of systems that need to be written in such
languages.

> And don't forget Ariane 5 ;)

I have looked into that a few times and I do wonder whether the language
or release process could have been of any help.  One possibility is
using something like SPARK to ensure the absence of overflow exceptions.
Another is automatic test generation something like

  http://www.stanford.edu/~engler/klee-osdi-2008.pdf 

but that approach was probably unknown at the time.

In article 
<0ed1fb16-87cb-4fb9-85b2-08d876445d5d@q22g2000yqm.googlegroups.com>,
 sturlamolden <sturlamolden@yahoo.no> wrote:

> The typical examples revealing incompetence are use of
> new[] instead of std::vector

To be fair, there were usable C++ compilers before there were usable STL 
implementations.  Thus, it should not be surprising to find older C++ 
code bases eschewing the use of STL.  That's not to say that this trend 
should be propagated in current educational material.

> and dynamic resourse allocation outside contructors.

This one I don't understand.  Yes, I get RAII, but surely there are 
valid reasons to allocate memory outside of constructors.  Containers 
which resize themselves (such as std::vector) are one obvious example.

In article <i37ire$7gd$1@panix5.panix.com>, aahz@pythoncraft.com (Aahz) 
wrote:

> http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

The same story has been floating around for eons, just with the names 
changed.  I saw one where Wirth was ostensibly making fun of the people 
who didn't understand that Pascal was all just a joke.

I'm sure if you go back far enough, you can find a McCarthy / Lisp 
version.  It probably goes something like, "So, anyway, we tried to 
figure out what was the most absurd way to abuse punctuation we could 
imagine.  Somebody suggested that every program would have to end with 
37 close parentheses.  When we finally stopped laughing, we started 
sketching out a grammar on the chalkboard that would let us do that".

On 3 Aug, 02:47, Roy Smith <r...@panix.com> wrote:

> This one I don't understand. =A0Yes, I get RAII, but surely there are
> valid reasons to allocate memory outside of constructors. =A0Containers
> which resize themselves (such as std::vector) are one obvious example.

That is because an exception might skip an arbitrarily placed delete[]
or std::fclose when it rewinds the stack, so to avoid resource leaks
they must be places inside a destructor of an object on the stack
(which will be called).

This is unsafe, anyone who writes this in C++ should be flogged:

void foobar()
{
   std::FILE *fid =3D fopen("whatever");
   // some code here
   std::fclose(fid);
}


This idiom is safer :

struct File {
    std::FILE *fid;
    File(const char *name) {
        // acquire resource in constructor
        fid =3D std::fopen(name);
        if (!fid) throw some_exception;
    }
    ~File() {
        // free resource in destructor
        if(fid) std::flose(fid);
    }
};

void foobar()
{
    File file("whatever");
    // some code here
}

It is for the very same reason we should use std::vector instead of
new[] for arrays. It is why new and delete should only be used inside
constructors/destructors. It also why C++ has references in addition
to pointers.

Which means this is bad in C++, as new and delete is arbitrarily
placed:

void foobar()
{
    File *myfile =3D new File("whatever);
    // some code here
    delete myfile;
}

An object should go on the stack, because if an exception is thrown,
we need the destructor call. Which is why this (as shown above) is
ok:

void foobar()
{
    File file("whatever");
    // some code here
}

This is the kind of gotchas that allows C++ to shoot your leg off.

In comparison C is much more forgiving, because there is no exceptions
(unless you use setjmp/longjmp). This is ok in C, but not in C++:

void foobar()
{
   FILE *fid =3D fopen("whatever");
   // some code here
   fclose(fid);
}

For the same reason we can place malloc and free wherever we like in C
code. But in C++ we must restrict std::malloc and std::free (as well
as new and delete) to constructor and destructor pairs.

This kind of design is mandatory to make safe C++ programs. But it is
not enforced by the compiler. And since the majority of C++
programmers don't obey by these rules, Java and C# tends to produce
far less runtime errors and memory/resource leaks. And C++ textbooks
tends to avoid teaching these important details. I'm inclined to
believe it is because the authors don't understand it themselves.

Objects on the stack are also required for operator overloading in C+
+. A common novice mistake is this:

  std::vector<double> *myvec =3D new std::vector<double>(10);
  myvec[5] =3D 10.0; // why does the compiler complain?????

And then the novice will spend hours contemplating why the stupid
compiler claims the type of myvec[5] is std::vector<double>. There was
recently a post to the Cython mailing list claiming there is a bug in
Cython's auto-generated C++ because of this. But this is how it should
be:

  std::vector<double> myvec(10);
  myvec[5] =3D 10.0; // ok

And now we see why C++ has references, as that is how we can
efficiently reference and object on the stack without getting the
operator overloading problem above.

C++ is good, but most programmers are better off with C. It has fewer
gotchas. And if we need OOP, we have Python...

Sturla

On 3 Aug, 04:03, sturlamolden <sturlamol...@yahoo.no> wrote:

> struct File {
> =A0 =A0 std::FILE *fid;
> =A0 =A0 File(const char *name) {
> =A0 =A0 =A0 =A0 // acquire resource in constructor
> =A0 =A0 =A0 =A0 fid =3D std::fopen(name);
> =A0 =A0 =A0 =A0 if (!fid) throw some_exception;
> =A0 =A0 }
> =A0 =A0 ~File() {
> =A0 =A0 =A0 =A0 // free resource in destructor
> =A0 =A0 =A0 =A0 if(fid) std::flose(fid);
> =A0 =A0 }
>
> };

And since this is comp.lang.python, I'll add in that this sometimes
applies to Python as well. Python, like C++, can have the call stack
rewinded by an exception. If we call some raw OS resource allocation,
e.g. malloc or fopen using ctypes, we have to place a deallocation in
__del__ (and make sure the object is newer put in a reference cycle).
The safer option, however, is to use a C extension object, which is
guaranteed to have the destructor called (that is, __dealloc__ when
using Cython or Pyrex).

If we place raw resource allocation arbitrarily in Python code, it is
just as bad as in C++. But in Python, programmers avoid this trap by
mostly never allocating raw OS resources from within Python code. E.g.
Python's file object is programmed to close itself on garbage
collection, unlike a pointer retured from fopen using ctypes.

Sturla

In article 
<7d95c0d3-718d-4958-9364-263c833f1835@i24g2000yqa.googlegroups.com>,
 sturlamolden <sturlamolden@yahoo.no> wrote:

> On 3 Aug, 02:47, Roy Smith <r...@panix.com> wrote:
> 
> > This one I don't understand. �Yes, I get RAII, but surely there are
> > valid reasons to allocate memory outside of constructors. �Containers
> > which resize themselves (such as std::vector) are one obvious example.
> 
> That is because an exception might skip an arbitrarily placed delete[]
> or std::fclose when it rewinds the stack...

Well, OK, but there's still nothing wrong with allocating memory outside 
of constructors, as long as you make sure the destructor cleans it up.  
Or you have made some other arrangements to make sure it's cleaned up 
(try/catch, auto_pointer, etc).

In article <roy-788377.21035502082010@news.panix.com>,
Roy Smith  <roy@panix.com> wrote:
>In article <i37ire$7gd$1@panix5.panix.com>, aahz@pythoncraft.com (Aahz) 
>wrote:
>>
>> http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html
>
>The same story has been floating around for eons, just with the names 
>changed.  I saw one where Wirth was ostensibly making fun of the people 
>who didn't understand that Pascal was all just a joke.
>
>I'm sure if you go back far enough, you can find a McCarthy / Lisp 
>version.  It probably goes something like, "So, anyway, we tried to 
>figure out what was the most absurd way to abuse punctuation we could 
>imagine.  Somebody suggested that every program would have to end with 
>37 close parentheses.  When we finally stopped laughing, we started 
>sketching out a grammar on the chalkboard that would let us do that".

http://www.netfunny.com/rhf/jokes/90q2/lispcode.html
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

(You knew I was going to post that, right?)

In article <2b473423-0a22-4f4d-943f-31ea2d6020e6@z10g2000yqb.googlegroups.com>,
sturlamolden  <sturlamolden@yahoo.no> wrote:
>
>And since this is comp.lang.python, I'll add in that this sometimes
>applies to Python as well. Python, like C++, can have the call stack
>rewinded by an exception. If we call some raw OS resource allocation,
>e.g. malloc or fopen using ctypes, we have to place a deallocation in
>__del__ (and make sure the object is newer put in a reference cycle).
>The safer option, however, is to use a C extension object, which is
>guaranteed to have the destructor called (that is, __dealloc__ when
>using Cython or Pyrex).

Actually, with Python 2.6 or later, the Pythonic solution is to use
``with``.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..."  --Siobhan

On Mon, 02 Aug 2010 17:17:35 -0700, Peter wrote:

> But I always used to tell
> people - by the time I got a program to compile then I figured 99% of
> the bugs were already discovered! Try that with C/C++ or almost any
> other language you care to name :-)

ML and Haskell are also quite good for this (although I wish they
supported integer subranges). Also, the statelessness of FP eliminates
entire classes of bugs.

On Mon, 02 Aug 2010 15:18:30 -0700, sturlamolden wrote:

>> Has it ever been planned to rewrite in C++ the historical implementation
>> (of course in an object oriented design) ?
> 
> OO programming is possible in C.  Just take a look at GNOME and GTK.

One feature which can't readily be implemented in C is the automatic
clean-up side of the RAII idiom.

On Tue, Aug 3, 2010 at 1:36 AM, Nobody <nobody@nowhere.com> wrote:
> On Mon, 02 Aug 2010 15:18:30 -0700, sturlamolden wrote:
>>> Has it ever been planned to rewrite in C++ the historical implementatio=
n
>>> (of course in an object oriented design) ?
>>
>> OO programming is possible in C. =C2=A0Just take a look at GNOME and GTK=
..
>
> One feature which can't readily be implemented in C is the automatic
> clean-up side of the RAII idiom.

That's not directly related to object-orientation though.

Cheers,
Chris

On Tue, Aug 3, 2010 at 6:36 PM, Nobody <nobody@nowhere.com> wrote:
> One feature which can't readily be implemented in C is the automatic
> clean-up side of the RAII idiom.

C is a Turing-Complete Language is it not ?

If so, therefore is it not true "anything" can be implemented ?
Even the "automated clean-up side of the RAIL idiom" ?

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

On Tue, 03 Aug 2010 18:48:24 +1000, James Mills wrote:

> On Tue, Aug 3, 2010 at 6:36 PM, Nobody <nobody@nowhere.com> wrote:
>> One feature which can't readily be implemented in C is the automatic
>> clean-up side of the RAII idiom.
> 
> C is a Turing-Complete Language is it not ?
> 
> If so, therefore is it not true "anything" can be implemented ? Even the
> "automated clean-up side of the RAIL idiom" ?

True, but Nobody said it can't *readily* be implemented, not that it 
can't be.




-- 
Steven

On Tue, Aug 3, 2010 at 7:04 PM, Steven D'Aprano
<steve-REMOVE-THIS@cybersource.com.au> wrote:
> True, but Nobody said it can't *readily* be implemented, not that it
> can't be.

So he did too :) I read that as "really" :/

--James

-- 
-- James Mills
--
-- "Problems are solved by method"

Carl Banks <pavlovevidence@gmail.com> writes:

> On Aug 1, 6:09 pm, John Bokma <j...@castleamber.com> wrote:
>> Roy Smith <r...@panix.com> writes:
>> > In article <4c55fe82$0$9111$426a3...@news.free.fr>,
>> >  candide <cand...@free.invalid> wrote:
>>
>> >> Python is an object oriented langage (OOL). The Python main
>> >> implementation is written in pure and "old" C90. Is it for historical
>> >> reasons?
>>
>> >> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
>> >> suitable to implement an OOL with another one.
>>
>> > One thing that comes to mind is that it's much easier to distribute C
>> > libraries than C++ libraries.
>>
>> In the beginning of C++ there were programs that just converted C++ to C
>> (frontends). At least that is how the C++ compiler Acorn sold worked.
>> So I don't think your argument was much true back then.
>
> No, it was that way back then too.  They might all generate C code but
> different C code by different backends wouldn't be able to call each
> other natively.

If you convert C++ to C, and compile the C code then that's not
different from compiling the C code itself, correct?

> For instnace the function
>
> int foo(int);
>
> might be name-mangled this way in one cfront:
>
> foo$d
>
> and this way in another:
>
> ____int_foo__int_i

But they call both the C libraries in the same way.

> The virtual table of this class:
>
> class Bar {
>     virtual int foo(int);
>     virtual int bar(int);
> };
>
> might be generated like this in one cfront:
>
> struct Bar$$Vtable$ {
>     int (*Bar$$bar$d)(int);
>     int (*Bar$$foo$d)(int);
> };
>
> and like this in another:
>
> struct ____class_Foo___vtable_ {
>     int (*foo)(int);
>     int (*bar)(int);
> };
>
>
> So, just because they both generated C code, it doesn't mean they can
> call one another.

Why would they need to call each other? The compiled C++ code ends up as
being compiled generated C code.

It has been a while, but I am quite sure that the Acorn C++ front end I
used could dump the actual generated C code. And this generated code
should compile with a normal C compiler on a different platform.

The only exception I can think of is if the front end comes with
libraries you have to link against. But since this should be C as well
(since there is no native C++), I don't see any problem to recreate
those libraries.

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Albert Hopkins <marduk@letterboxes.org> writes:

> But I wonder if someone has/has tried to write a programming language in
> C++ and what were their experiences.

  The Low Level Virtual Machine (LLVM) is a compiler infrastructure,
  written in C++, which is designed for compile-time, link-time,
  run-time, and "idle-time" optimization of programs written in
  arbitrary programming languages. Originally implemented for C/C++, the
  language-independent design (and the success) of LLVM has since
  spawned a wide variety of front ends, including Objective-C, Fortran,
  Ada, Haskell, Java bytecode, Python, Ruby, ActionScript, GLSL, and
  others.

http://en.wikipedia.org/wiki/LLVM

  Unladen Swallow is a branch of Python intended to be fully compatible
  and significantly faster. It uses LLVM's optimization passes and JIT
  compiler.

http://llvm.org/ProjectsWithLLVM/#unladenswallow

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Michael Torrie <torriem@gmail.com> writes:

> On 08/01/2010 07:09 PM, John Bokma wrote:
>>> One thing that comes to mind is that it's much easier to distribute C 
>>> libraries than C++ libraries.
>> 
>> In the beginning of C++ there were programs that just converted C++ to C
>> (frontends). At least that is how the C++ compiler Acorn sold worked.
>> So I don't think your argument was much true back then.
>
> No, he is still right.  Each C++ implementation did name mangling
> differently leading to "C" libraries that had incompatible names and
> signatures.  Also each frontend could have generated incompatible
> vtables and other C++ structures.  So C code generated by one C++
> frontend could not easily call C code generated by another C++ frontend.
>  So the same arguments that are made about C++ now were just as valid
> back then when C++ was merely a fancy preprocessor.

See my other post: I understand that two C++ preprocessors can't call
each others generated code, but if one uses C++ and knows that one can
only use shared C libraries on target systems, and not C++ libraries
that might be present (or more likely not: C++ was new in those days).

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

On Tue, 03 Aug 2010 18:48:24 +1000, James Mills wrote:

>> One feature which can't readily be implemented in C is the automatic
>> clean-up side of the RAII idiom.
> 
> C is a Turing-Complete Language is it not ?
> 
> If so, therefore is it not true "anything" can be implemented ?
> Even the "automated clean-up side of the RAIL idiom" ?

By "automated", I mean the fact that destructors get called automatically
when a local variable goes out of scope, whether by reaching the end of
the block, return, break, continue, or an exception.

In C, the clean-up has to be made explicit, i.e. not "automated".

Nobody <nobody@nowhere.com> writes:
> One feature which can't readily be implemented in C is the automatic
> clean-up side of the RAII idiom.

I once did that by having an explicit stack of finalization records
linked through the call stack.  The "throw" routine would traverse the
links to call the finalizers, until it found the matching "catch" which
contained a longjmp target.  It wasn't as crazy as this makes it sound.

On 2010-08-02, Aahz <aahz@pythoncraft.com> wrote:
> In article <f9e652d6-3945-4c18-92f3-b85b994feb0b@k8g2000prh.googlegroups.com>,
> Peter  <peter.milliken@gmail.com> wrote:
>>On Aug 3, 7:42=A0am, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
>>> On 02/08/2010 00:08, candide wrote:
>>>
>>> I can't understand why any serious programmer mentions C++. As soon
>>> as I read it, I have to rush either to the kitchen to find a bowl to
>>> throw up in, or head for the toilet so I can talk to the great white
>>> telephone.
>>
>>With you there Mark - IMO C++ is an abortion that should never have
>>seen the light of day. The idea of experimenting with creating an OO
>>language by extending C wasn't such a bad idea for a "play thing" (by
>>Stroustrop) but the fact that it somehow escaped from the Lab and
>>people picked it up and ran with it on a commercial basis is just
>>plain wrong!
>
> http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html

It's funny (and sad) because it's so close to being true.

(The effect, I mean, not necissarly the intent.)

There's no computing problem so simple that it can't be solved in a
complex and obtuse manner in C++.

I know that's true of any language, but from what I've seen over the
years, it "more true" in C++.

-- 
Grant Edwards               grant.b.edwards        Yow! Should I get locked
                                  at               in the PRINCICAL'S
                              gmail.com            OFFICE today -- or have
                                                   a VASECTOMY??

On 2010-08-02, Paul Rubin <no.email@nospam.invalid> wrote:
> Michael Torrie <torriem@gmail.com> writes:
>> Sometimes, C++ is just the right tool for the job, despite all its
>> warts....  C++'s object semantics (guaranteed destruction, scoping,
>> etc) can sometimes work very well when you need the speed of a
>> compiled language, but don't want to be quite as low-level as C.
>> 
>> In this case, C++ is certainly not a better tool for the job than C.
>
> The stuff C++ adds to C is a mix of good and bad, and it's reasonably
> possible to use just the good stuff and ignore the bad.

Except nobody does. ;)

> I've never programmed in Ada but I'm intrigued by these articles:
>
>   http://adahome.com/Ammo/cpp2ada.html 
>   http://www.adaic.org/whyada/ada-vs-c/cada_art.html
>
> I have the impression that Ada has an undeservedly bad rap because of
> its early implementations and its origins in military bureaucracy. 
> I'd certainly consider it as an alternative to C or C++ if I had to
> write a big program in a traditional procedural language.

I've always thought Ada was a pretty nice embedded/systems languages,
but some of the initial implementations were indede horrible. The one
I used for a little while ran on VAX/VMS but didn't use the VMS
filesystem, editors, or other utilities.  The Ada enviroment was a
completely closed, walled system.  It kept it's "files" in some sort
of opaque database and they could only be accessed, edited, compiled,
etc. from within the Ada development enviornment (a system with
really, really awful editing and build tools).  There was a way to
import/export files, but it wasn't easy. Still, the Ada-environment
tools were _so_ bad that people exported a file, edited it using some
VMS-based editor and the re-imported it whenever a change needed to be
made.

Apparently the intent was to provide the identically awful
user-torturing-experience regardless of OS.

-- 
Grant Edwards               grant.b.edwards        Yow! I represent a
                                  at               sardine!!
                              gmail.com            

On Aug 3, 2:29=A0am, John Bokma <j...@castleamber.com> wrote:
> Carl Banks <pavlovevide...@gmail.com> writes:
> > On Aug 1, 6:09=A0pm, John Bokma <j...@castleamber.com> wrote:
> >> Roy Smith <r...@panix.com> writes:
> >> > In article <4c55fe82$0$9111$426a3...@news.free.fr>,
> >> > =A0candide <cand...@free.invalid> wrote:
>
> >> >> Python is an object oriented langage (OOL). The Python main
> >> >> implementation is written in pure and "old" C90. Is it for historic=
al
> >> >> reasons?
>
> >> >> C is not an OOL and C++ strongly is. I wonder if it wouldn't be mor=
e
> >> >> suitable to implement an OOL with another one.
>
> >> > One thing that comes to mind is that it's much easier to distribute =
C
> >> > libraries than C++ libraries.
>
> >> In the beginning of C++ there were programs that just converted C++ to=
 C
> >> (frontends). At least that is how the C++ compiler Acorn sold worked.
> >> So I don't think your argument was much true back then.
>
> > No, it was that way back then too. =A0They might all generate C code bu=
t
> > different C code by different backends wouldn't be able to call each
> > other natively.
>
> If you convert C++ to C, and compile the C code then that's not
> different from compiling the C code itself, correct?
>
>
> > For instnace the function
>
> > int foo(int);
>
> > might be name-mangled this way in one cfront:
>
> > foo$d
>
> > and this way in another:
>
> > ____int_foo__int_i
>
> But they call both the C libraries in the same way.

Go look at the original claim, the one that you responded to.  "It's
much easier to distribute C libraries than C++ libraries."

Of course they can both call C libraries.  All modern C++ compilers
can too, not just cfronts.  What almost no C++ compiler or C++ front
can do is call a C++ library that a different C++ compiler or C++
front generated.  (Unless they export function calls with C linkage,
but that's not too helpful since the ostensible benefit of C++ is
function overloading and subclassing and such, which you can't do at
all between different compilers or fronts.)

Hence, "It's much easier to distribute C libraries than C++
libraries."


[snip rest of post that misses the point]


Carl Banks

John Bokma wrote:
> Michael Torrie <torriem@gmail.com> writes:
> 
>> On 08/01/2010 07:09 PM, John Bokma wrote:
>>>> One thing that comes to mind is that it's much easier to distribute C 
>>>> libraries than C++ libraries.
>>> In the beginning of C++ there were programs that just converted C++ to C
>>> (frontends). At least that is how the C++ compiler Acorn sold worked.
>>> So I don't think your argument was much true back then.
>> No, he is still right.  Each C++ implementation did name mangling
>> differently leading to "C" libraries that had incompatible names and
>> signatures.  Also each frontend could have generated incompatible
>> vtables and other C++ structures.  So C code generated by one C++
>> frontend could not easily call C code generated by another C++ frontend.
>>  So the same arguments that are made about C++ now were just as valid
>> back then when C++ was merely a fancy preprocessor.
> 
> See my other post: I understand that two C++ preprocessors can't call
> each others generated code, but if one uses C++ and knows that one can
> only use shared C libraries on target systems, and not C++ libraries
> that might be present (or more likely not: C++ was new in those days).

So if Python were written in C++, and an extension was written in C++, 
how could the two call each other?

~Ethan~

On 8/1/2010 5:36 PM, Roy Smith wrote:
> In article<4c55fe82$0$9111$426a34cc@news.free.fr>,
>   candide<candide@free.invalid>  wrote:
>
>> Python is an object oriented langage (OOL). The Python main
>> implementation is written in pure and "old" C90. Is it for historical
>> reasons?
>>
>> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
>> suitable to implement an OOL with another one.
>
> One thing that comes to mind is that it's much easier to distribute C
> libraries than C++ libraries.
>
> If I compile a main program with one C compiler and you compile a
> dynamically loaded library with another C compiler on the same box, the
> odds are pretty good they'll interoperate without any problems.

    Not for Python.  Extensions have to be built with essentially the
same version of the same C compiler used for building Python.  This
is a major headache.

				John Nagle

Grant Edwards <invalid@invalid.invalid> writes:
> There's no computing problem so simple that it can't be solved in a
> complex and obtuse manner in C++.
>
> I know that's true of any language, but from what I've seen over the
> years, it "more true" in C++.

http://www.willamette.edu/~fruehr/haskell/evolution.html

Carl Banks <pavlovevidence@gmail.com> writes:

> On Aug 3, 2:29 am, John Bokma <j...@castleamber.com> wrote:

[..]

>> But they call both the C libraries in the same way.
>
> Go look at the original claim, the one that you responded to.  "It's
> much easier to distribute C libraries than C++ libraries."

Yup, and if I read it correctly the claim was: and that's why C++ was
not chosen. I doubt it.

> Hence, "It's much easier to distribute C libraries than C++
> libraries."

Yup, but still doesn't exclude C++ from being used to implement a
programming language.

And I would appreciate some respect, especially from someone who's too
lazy to do some editing before posting, thank you.

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Ethan Furman <ethan@stoneleaf.us> writes:

> John Bokma wrote:
>> Michael Torrie <torriem@gmail.com> writes:
>>
>>> On 08/01/2010 07:09 PM, John Bokma wrote:
>>>>> One thing that comes to mind is that it's much easier to
>>>>> distribute C libraries than C++ libraries.
>>>> In the beginning of C++ there were programs that just converted C++ to C
>>>> (frontends). At least that is how the C++ compiler Acorn sold worked.
>>>> So I don't think your argument was much true back then.
>>> No, he is still right.  Each C++ implementation did name mangling
>>> differently leading to "C" libraries that had incompatible names and
>>> signatures.  Also each frontend could have generated incompatible
>>> vtables and other C++ structures.  So C code generated by one C++
>>> frontend could not easily call C code generated by another C++ frontend.
>>>  So the same arguments that are made about C++ now were just as valid
>>> back then when C++ was merely a fancy preprocessor.
>>
>> See my other post: I understand that two C++ preprocessors can't call
>> each others generated code, but if one uses C++ and knows that one can
>> only use shared C libraries on target systems, and not C++ libraries
>> that might be present (or more likely not: C++ was new in those days).
>
> So if Python were written in C++, and an extension was written in C++,
> how could the two call each other?

Via C.

-- 
John Bokma                                                               j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

John Bokma wrote:
> Ethan Furman <ethan@stoneleaf.us> writes:
> 
>> John Bokma wrote:
>>> Michael Torrie <torriem@gmail.com> writes:
>>>
>>>> On 08/01/2010 07:09 PM, John Bokma wrote:
>>>>>> One thing that comes to mind is that it's much easier to
>>>>>> distribute C libraries than C++ libraries.

>>>>> In the beginning of C++ there were programs that just converted C++ to C
>>>>> (frontends). At least that is how the C++ compiler Acorn sold worked.
>>>>> So I don't think your argument was much true back then.

>>>> No, he is still right.  Each C++ implementation did name mangling
>>>> differently leading to "C" libraries that had incompatible names and
>>>> signatures.  Also each frontend could have generated incompatible
>>>> vtables and other C++ structures.  So C code generated by one C++
>>>> frontend could not easily call C code generated by another C++ frontend.
>>>>  So the same arguments that are made about C++ now were just as valid
>>>> back then when C++ was merely a fancy preprocessor.

>>> See my other post: I understand that two C++ preprocessors can't call
>>> each others generated code, but if one uses C++ and knows that one can
>>> only use shared C libraries on target systems, and not C++ libraries
>>> that might be present (or more likely not: C++ was new in those days).

>> So if Python were written in C++, and an extension was written in C++,
>> how could the two call each other?
> 
> Via C.

Huh?  Presumably Python itself is not a library, and the extension may 
not be a library, at some point they will have different name mangling 
schemes... are you suggesting that after going through the effort if 
writing all this in C++ you would then have to write a wrapper in C so 
the two could talk to each other?

~Ethan~

On Aug 3, 3:19=A0pm, John Bokma <j...@castleamber.com> wrote:
> Carl Banks <pavlovevide...@gmail.com> writes:
> > On Aug 3, 2:29=A0am, John Bokma <j...@castleamber.com> wrote:
>
> [..]
>
> >> But they call both the C libraries in the same way.
>
> > Go look at the original claim, the one that you responded to. =A0"It's
> > much easier to distribute C libraries than C++ libraries."
>
> Yup, and if I read it correctly the claim was: and that's why C++ was
> not chosen. I doubt it.

I think it was.  Not necessarily that GvR made a list of reasons to
choose C over C++.  But the fact that C++ has almost no
interoperability between compilers except via regular C linkage is a
major cultural reason why it's avoided for programs that need
extensible APIs like Python, which is why language implementors try to
avoid it.

The availability of C++ fronts that translate to C isn't the slightest
bit relevant to this.


> > Hence, "It's much easier to distribute C libraries than C++
> > libraries."
>
> Yup, but still doesn't exclude C++ from being used to implement a
> programming language.

Well, if you want to write a language that people can write extensions
for using something other than the same C++ compiler you used, then
your only option is to use "C" external linkage which means that
whatever OOP advantages C++ gives you aren't going to be available to
extensions.

This is true even if you use a C++ front instead of a compiler.


Carl Banks

In article <87aap3uyo7.fsf@castleamber.com>,
 John Bokma <john@castleamber.com> wrote:

> > Go look at the original claim, the one that you responded to.  "It's
> > much easier to distribute C libraries than C++ libraries."
> 
> Yup, and if I read it correctly the claim was: and that's why C++ was
> not chosen. I doubt it.

I didn't intend to claim quite that much.  I'm just saying it's a 
consideration.  I was not privy to the original design decisions.

> Has it ever been planned to rewrite in C++ the historical implementation
> (of course in an object oriented design) ?

Around the time Guido coined the term "Python 3000" (i.e. in 2000), he
also said at a few occasions that it would be written in C++. He
subsequently dropped the idea, for the reasons that people have been
discussing.

Regards,
Martin

In message <i3982t$79s$2@reader1.panix.com>, Grant Edwards wrote:

> I've always thought Ada was a pretty nice embedded/systems languages,
> but some of the initial implementations were indede horrible.

Well, there’s GNAT, the GNU Ada implementation. Seems pretty robust and 
complete, while offering backward compatibility with some of those “initial 
implementations”, presumably because people have so much code already 
written for them.

Disclaimer: the most complicated Ada program I’ve ever written is this 
<http://www.codecodex.com/wiki/Concurrent_Quicksort>. Or maybe this 
<http://www.codecodex.com/wiki/Parallel_Sieve_of_Eratosthenes>. :)

On 2010-08-04, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <i3982t$79s$2@reader1.panix.com>, Grant Edwards wrote:
>
>> I've always thought Ada was a pretty nice embedded/systems languages,
>> but some of the initial implementations were indede horrible.
>
> Well, there?s GNAT, the GNU Ada implementation. Seems pretty robust and 
> complete, while offering backward compatibility with some of those ?initial 
> implementations?, presumably because people have so much code already 
> written for them.

Yep, I've installed Gnat a couple times with the intention of playing
around with it, but there's pretty much zero chance I could sell it at
the office in place of C/C++ for embedded stuff, and for desktop stuff
it's just way to easy to get programs done using Python.

I also looked at Modula-3 once, and thought it had some real promise,
but I think it's probably deader than Ada now.

-- 
Grant

Grant Edwards <invalid@invalid.invalid> writes:
> Yep, I've installed Gnat a couple times with the intention of playing
> around with it, but there's pretty much zero chance I could sell it at
> the office in place of C/C++ for embedded stuff, 

I wonder what the issues are.  From everything I've heard, it's a pretty
good compiler.  It does ok against C/C++ in the Alioth shootouts.  I
haven't written anything in it beyond "hello world" but I've looked at
the wikibook about it and that intro piece that I linked earlier.  It's
more verbose than C, so coding in it takes more keystrokes, but it looks
to me like the general coding approach (modulo the extra keystrokes)
should be similar to that of C, Algol, and so on, and the results should
be quite a bit more reliable.  

Mozilla is fed up with C++ and seems to be working on its own language,
called Rust:

   http://lambda-the-ultimate.org/node/4009 

On 2010-08-04, Paul Rubin <no.email@nospam.invalid> wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
>
>> Yep, I've installed Gnat a couple times with the intention of playing
>> around with it, but there's pretty much zero chance I could sell it
>> at the office in place of C/C++ for embedded stuff, 
>
> I wonder what the issues are.

The issue that would prevent its use where I work is the inability to
hire anybody who knows Ada.  You can't hire anybody who knows C++
either, but you can hire lots of people who claim they do.  [I'm not
convinced that there are more than about 6 people on the planet who
know C++ well enough that they should be writing real projects in it.]

That said, the last time I looked the Ada spec was only something like
100 pages long, so a case could be made that it won't take long to
learn.  I don't know how long the C++ language spec is, but I'm
betting it's closer to 1000 than 100.  But I failed when I tried to
get people to use Python, so I doubt I'd have any better luck with
Ada.

> From everything I've heard, it's a pretty good compiler.

I think it's probably a very good compiler.  It's the compiler users
that are the issue.

> It does ok against C/C++ in the Alioth shootouts.  I haven't written
> anything in it beyond "hello world" but I've looked at the wikibook
> about it and that intro piece that I linked earlier.  It's more
> verbose than C,

The verbosity always bugged me a little.  To my eyes all the sugar
gets in the way of seeing the code.  Somebody should invent a language
where indentation defines the blocks.

> so coding in it takes more keystrokes, but it looks to me like the
> general coding approach (modulo the extra keystrokes) should be
> similar to that of C, Algol, and so on, and the results should be
> quite a bit more reliable.  

Indeed.

> Mozilla is fed up with C++ and seems to be working on its own language,
> called Rust:
>
>    http://lambda-the-ultimate.org/node/4009 

Great!  The world needs one more computer language...

-- 
Grant

Grant Edwards <invalid@invalid.invalid> writes:
> The issue that would prevent its use where I work is the inability to
> hire anybody who knows Ada.  ...
> That said, the last time I looked the Ada spec was only something like
> 100 pages long, so a case could be made that it won't take long to
> learn. 

Well, I don't know Ada (I've read about it but not written actual code),
so maybe I shouldn't be the one saying this, but geez, it's another
imperative, procedural language, like Algol or Pascal or even C.  Its
type is much more serious than C's but shouldn't be a problem for anyone
who uses C++ or Java generics.  It also has a real module system unlike
more commonly used languages, but 1) that part seems easy to understand;
and 2) usually that's used for multi-programmer projects, so as long as
there's some reasonable proportion of experienced users on the team, the
inter-module interfaces should be sensible and less experienced users
can just program to existing interfaces and/or get some help from
others.  Ada's module system is much simpler than (say) ML's.

> I don't know how long the C++ language spec is, but I'm
> betting it's closer to 1000 than 100. 

I don't know about an official spec.  Stroustrup's "The C++ programming
language" is about 1000 pp, but it's a textbook, with lots of examples,
exercises, etc.  I read through an earlier (shorter) edition in a couple
of evenings a long time ago and it all made sense.  It has some hairy
aspects like the notorious template metaprogramming, but most users
simply won't get involved with that.  Python has its own obscure and
confusing features if that matters.  I think I'm a reasonably good
Python programmer but I've never written a special metaclass and
wouldn't really know how to.

On 4 Aug, 04:41, Grant Edwards <inva...@invalid.invalid> wrote:

> The issue that would prevent its use where I work is the inability to
> hire anybody who knows Ada. =A0You can't hire anybody who knows C++
> either, but you can hire lots of people who claim they do. =A0

That is very true.

On Aug 3, 7:07=A0pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Mozilla is fed up with C++ and seems to be working on its own language,
> called Rust:
>
> =A0 =A0http://lambda-the-ultimate.org/node/4009

That looks much better than Go.

It's like all the cool features of Go without the annoying polemics.
I'm starting to get the feeling one of these languages is going to hit
a sweet spot and turn C into the next Cobol.


Carl Banks

In article 
<ba47afb4-5798-41da-85d3-bb60cf97c604@c10g2000yqi.googlegroups.com>,
 sturlamolden <sturlamolden@yahoo.no> wrote:

> On 4 Aug, 04:41, Grant Edwards <inva...@invalid.invalid> wrote:
> 
> > The issue that would prevent its use where I work is the inability to
> > hire anybody who knows Ada. �You can't hire anybody who knows C++
> > either, but you can hire lots of people who claim they do. �
> 
> That is very true.

I suspect there are less than 100 people in the world who "know C++" in 
the sense that they know every feature, every detail, every quirk.  
These are the people who sit on the standards committee, write the books 
we all buy, etc.

There are, however, a lot of people who know a large enough subset of 
C++ to be productive and to write effective, safe, quality code within 
those boundaries.  These people know what they don't know and either 
avoid using those features, or know where (and when) to look it up.  I 
put myself in that camp.

The problem is, there are also a very large number of people who put 
"expert C++" on their resumes and know just enough to be dangerous.

The real problem is that it's sometimes difficult to distinguish between 
the members of the latter two groups in an interview.

In message <7xmxt3uo4h.fsf@ruckus.brouhaha.com>, Paul Rubin wrote:

> It's more verbose than C, so coding in it takes more keystrokes, but it
> looks to me like the general coding approach (modulo the extra keystrokes)
> should be similar to that of C, Algol, and so on, and the results should
> be quite a bit more reliable.

I believe the life-support software on the International Space Station is 
written in Ada. Would anybody feel happier if that had been done in C++?

In message <i3ajvt$935$1@reader1.panix.com>, Grant Edwards wrote:

> That said, the last time I looked the Ada spec was only something like
> 100 pages long, so a case could be made that it won't take long to
> learn.  I don't know how long the C++ language spec is, but I'm
> betting it's closer to 1000 than 100.

I have a copy of “The C++ Standard (Incorporating Technical Corrigendum No. 
1)” on my bookshelf. Let’s see ... flip-flip ... the highest page number is 
782. Definitely closer to 1000 than 100.

As for Ada ... I don’t have any printed manual, but

    dpkg-query -L ada-reference-manual | grep -c html/aarm95tc1

counts 353 HTML pages for the annotated reference.

I found it fairly tedious to read the lot. But then, I didn’t even try to do 
that with the C++ spec...

In message <roy-00F9BF.00004104082010@news.panix.com>, Roy Smith wrote:

> There are, however, a lot of people who know a large enough subset of
> C++ to be productive ...

I think there are some language features, knowledge of which has a negative 
impact on productivity. :)

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:
> I believe the life-support software on the International Space Station is 
> written in Ada. Would anybody feel happier if that had been done in C++?

Take a look at the articles on C bug-finding on Dawson Engler's page:

  http://www.stanford.edu/~engler/ 

They are about tools that found 100's of bugs in various large C
programs including Linux and OpenBSD.  Most of those bugs would probably
not have been possible in Ada.  Program bugs are generally either subtle
errors or dumb ones.  Humans always will make dumb errors from time to
time, and C does almost nothing to prevent them (C++ used properly is
somewhat better).  Ada doesn't prevent the subtle ones but appears much
better than C or C++ at preventing the dumb kind.

I'm not sure what the hiring issue is.  I think anyone skilled in C++ or
Java can pick up Ada pretty easily.  It's mostly a subset of C++ with
different surface syntax.

Grant Edwards:

> That said, the last time I looked the Ada spec was only something like
> 100 pages long, so a case could be made that it won't take long to
> learn.  I don't know how long the C++ language spec is, but I'm
> betting it's closer to 1000 than 100.

   The Ada 2012 Language Reference Manual is 860 pages and the Ada 2005
LRM was 790 pages. The annotated versions are even longer
http://www.ada-auth.org/standards/ada12.html

   Neil

In message <pv76o.2574$Yv.111@viwinnwfe01.internal.bigpond.com>, Neil 
Hodgson wrote:

>    The Ada 2012 Language Reference Manual is 860 pages and the Ada 2005
> LRM was 790 pages. The annotated versions are even longer
> http://www.ada-auth.org/standards/ada12.html

Yeah, unfortunately the language was designed by a committee which was 
trying to meet a specification laid down by another committee set up by the 
US military.

It seems apt to describe the resulting design as “bulletproof”, but 
“elegant” or “concise” ... not so much.

In message <pan.2010.08.03.08.35.59.328000@nowhere.com>, Nobody wrote:

> One feature which can't readily be implemented in C is the automatic
> clean-up side of the RAII idiom.

Use do-once blocks
<http://www.geek-central.gen.nz/peeves/programming_discipline.html>.

In message 
<7d95c0d3-718d-4958-9364-263c833f1835@i24g2000yqa.googlegroups.com>, 
sturlamolden wrote:

> This is unsafe, anyone who writes this in C++ should be flogged:

Only if they’re using exceptions. Otherwise, it’s fine.

Carl Banks wrote:
> On Aug 3, 7:07 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>   
>> Mozilla is fed up with C++ and seems to be working on its own language,
>> called Rust:
>>
>>    http://lambda-the-ultimate.org/node/4009
>>     
>
> That looks much better than Go.
>
> It's like all the cool features of Go without the annoying polemics.
> I'm starting to get the feeling one of these languages is going to hit
> a sweet spot and turn C into the next Cobol.
>
>
> Carl Banks
>   
I hope you're right, for our children sanity :)

JM

On 2010-08-04, Paul Rubin <no.email@nospam.invalid> wrote:
> Grant Edwards <invalid@invalid.invalid> writes:

>> The issue that would prevent its use where I work is the inability to
>> hire anybody who knows Ada.  ...
>> That said, the last time I looked the Ada spec was only something like
>> 100 pages long, so a case could be made that it won't take long to
>> learn. 
>
> Well, I don't know Ada (I've read about it but not written actual
> code), so maybe I shouldn't be the one saying this, but geez, it's
> another imperative, procedural language, like Algol or Pascal or even
> C.  Its type is much more serious than C's but shouldn't be a problem
> for anyone who uses C++ or Java generics.

I agree 100%.

> It also has a real module system unlike more commonly used languages,
> but 1) that part seems easy to understand; and 2) usually that's used
> for multi-programmer projects, so as long as there's some reasonable
> proportion of experienced users on the team, the inter-module
> interfaces should be sensible and less experienced users can just
> program to existing interfaces and/or get some help from others.
> Ada's module system is much simpler than (say) ML's.
>
>> I don't know how long the C++ language spec is, but I'm betting it's
>> closer to 1000 than 100. 
>
> I don't know about an official spec.  Stroustrup's "The C++
> programming language" is about 1000 pp, but it's a textbook, with
> lots of examples, exercises, etc.  I read through an earlier
> (shorter) edition in a couple of evenings a long time ago and it all
> made sense.  It has some hairy aspects like the notorious template
> metaprogramming, but most users simply won't get involved with that.
> Python has its own obscure and confusing features if that matters.

I couldn't get anybody to use Python either. :/

The problem has nothing to do with the relative merits of the
languages.  The problem is inertia.

> I think I'm a reasonably good Python programmer but I've never
> written a special metaclass and wouldn't really know how to.

-- 
Grant Edwards               grant.b.edwards        Yow! I would like to
                                  at               urinate in an OVULAR,
                              gmail.com            porcelain pool --

On 2010-08-04, Paul Rubin <no.email@nospam.invalid> wrote:

> I'm not sure what the hiring issue is.  I think anyone skilled in C++
> or Java can pick up Ada pretty easily.  It's mostly a subset of C++
> with different surface syntax.

In my experience, the hiring issue is "we're already behind schedule
and short-handed, we don't have the time or resources to teach people
a new language."

-- 
Grant Edwards               grant.b.edwards        Yow! Did YOU find a
                                  at               DIGITAL WATCH in YOUR box
                              gmail.com            of VELVEETA?

On 2010-08-04, Neil Hodgson <nyamatongwe+thunder@gmail.com> wrote:
> Grant Edwards:
>
>> That said, the last time I looked the Ada spec was only something like
>> 100 pages long, so a case could be made that it won't take long to
>> learn.  I don't know how long the C++ language spec is, but I'm
>> betting it's closer to 1000 than 100.
>
>    The Ada 2012 Language Reference Manual is 860 pages and the Ada 2005
> LRM was 790 pages. The annotated versions are even longer
> http://www.ada-auth.org/standards/ada12.html

Wow.  That's grown a lot over the years.  I used to have a paper copy,
(single-sided), and it was only about 1cm thick.  Ok, I guess that was
probably 20 years ago...

-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if I ought
                                  at               to tell them about my
                              gmail.com            PREVIOUS LIFE as a COMPLETE
                                                   STRANGER?

In message <i3bsjf$kfm$2@reader1.panix.com>, Grant Edwards wrote:

> In my experience, the hiring issue is "we're already behind schedule
> and short-handed, we don't have the time or resources to teach people
> a new language."

Most people seem to need tutorials or handholding of some sort. Look at the 
number of questions in this group which could be answered just by reading 
the reference manual.

In message <i3bseh$kfm$1@reader1.panix.com>, Grant Edwards wrote:

> The problem has nothing to do with the relative merits of the
> languages.  The problem is inertia.

So how was C++ able to get popular in the first place? And how was Java able 
to grab some share from it?

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:
> > The Ada 2012 Language Reference Manual is 860 pages ...
> Yeah, unfortunately the language was designed by a committee ...
> It seems apt to describe the resulting design as “bulletproof”, but 
> “elegant” or “concise” ... not so much.

I'd say the Ada standardizers went to a great deal of trouble to specify
and document stuff that other languages simply leave undefined, leaving
developers relying on implementation-specific behavior that's not part
of the standard.  Ada itself is not necessarily more complicated.

On 2010-08-04, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <i3bseh$kfm$1@reader1.panix.com>, Grant Edwards wrote:
>
>> The problem has nothing to do with the relative merits of the
>> languages.  The problem is inertia.
>
> So how was C++ able to get popular in the first place?

Building on C's popularity helped.

> And how was Java able to grab some share from it?

Good question.  Both IBM and Sun put a lot of effort/money behind
Java.

-- 
Grant

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:
> So how was C++ able to get popular in the first place? And how was
> Java able to grab some share from it?

C++ made improvements over C that were necessary and welcome for
controlling the complexity of large programs, while remaining mostly
upward compatible with C.  Java abandoned C compatibility and added
memory safety and GC.  That got rid of legacy-related pain and improved
program reliability and eased debugging considerably, at some cost in
performance.  Java was also on the OO bandwagon of the 1990's, which
translated into good marketing back then, but is part of the cause of
the massive bureaucracy and bloat in the Java runtime environment.  C++
seems to have made something of a comeback because of this, and Java now
has generics patterned after C++'s.

On Aug 4, 4:04=A0pm, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2010-08-04, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wr=
ote:
>
> > In message <i3bseh$kf...@reader1.panix.com>, Grant Edwards wrote:
>
> >> The problem has nothing to do with the relative merits of the
> >> languages. =A0The problem is inertia.
>
> > So how was C++ able to get popular in the first place?
>
> Building on C's popularity helped.

AT&T + Money + C backward compatibility


> > And how was Java able to grab some share from it?
>
> Good question. =A0Both IBM and Sun put a lot of effort/money behind
> Java.

Sun + IBM + Money + 90s Web trinkets


Carl Banks

(haven't seen a Java applet in ages)

On Aug 4, 4:23=A0pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>=A0Java was also on the OO bandwagon of the 1990's, which
> translated into good marketing back then, but is part of the cause of
> the massive bureaucracy and bloat in the Java runtime environment. =A0C++
> seems to have made something of a comeback because of this, and Java now
> has generics patterned after C++'s.

When I first studied Java, my first impression of the language was
that it had a Prime Directive that, "other than single inheritance and
being kinda like C, don't do anything C++ did".

Not a bad policy, actually.  However, omitting generics was probably
the second worst thing about Java (the worst thing being the awful AWT
design).


Carl Banks

In article <i3cqia$82r$2@lust.ihug.co.nz>,
 Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:

> In message <i3bseh$kfm$1@reader1.panix.com>, Grant Edwards wrote:
> 
> > The problem has nothing to do with the relative merits of the
> > languages.  The problem is inertia.
> 
> So how was C++ able to get popular in the first place? And how was Java able 
> to grab some share from it?

C++, for all its flaws, had one powerful feature which made it very 
popular.  It is a superset of C.  Whatever that may mean from a 
technical standpoint, it made the language feel safe and comfortable and 
low-risk to managers.  From a more technical standpoint, it had the very 
real advantage of being able to include all the C system headers and 
link against C system libraries.

As for Java, that's easy.  You could launch Java applets from inside a 
web browser.  In those days, anything related to the web was a one-way 
express ticket to fame and fortune.

In message <7xocdi56cp.fsf@ruckus.brouhaha.com>, Paul Rubin wrote:

> I'd say the Ada standardizers went to a great deal of trouble to specify
> and document stuff that other languages simply leave undefined, leaving
> developers relying on implementation-specific behavior that's not part
> of the standard.

OK, I have a copy of K&R 2nd Ed on a shelf within reach here. Can you point 
out some behaviour that C programmers might need to rely on, that is not 
specified in that document?

> Ada itself is not necessarily more complicated.

It is. Look at its baroque type structure. Hint: why is

    type A is B;

a syntax error?

In message <roy-6BCFA7.22564104082010@news.panix.com>, Roy Smith wrote:

> C++, for all its flaws, had one powerful feature which made it very
> popular.  It is a superset of C.

Actually, it never was.

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:

> In message <roy-6BCFA7.22564104082010@news.panix.com>, Roy Smith wrote:
>
>> C++, for all its flaws, had one powerful feature which made it very
>> popular.  It is a superset of C.
>
> Actually, it never was.

Wondering off topic a bit - I am reminded of something I once read in
some MS blurb... it described something as an "extended subset" of some
standard or another. (Think about it :))

On 08/05/10 05:33, Lawrence D'Oliveiro wrote:
> OK, I have a copy of K&R 2nd Ed on a shelf within reach here. Can you point
> out some behaviour that C programmers might need to rely on, that is not
> specified in that document?

"need to" is considerably different from "might".  Size of an 
int, assumptions that int=pointer, evaluation order of postfix 
increment/decrement...

http://stackoverflow.com/questions/625333/how-to-limit-the-impact-of-implementation-dependent-language-features-in-c

or http://tinyurl.com/263jayy if mailers between here & there 
break the URL)

Just because facilities (macros, best-practices, etc) have been 
established for some of these things doesn't mean a programmer 
will reach for them if their code happens to work locally without 
them.  Trust me...I've encountered PLENTY of such code in 
production before I left behind (for the most part) the world of C.

-tkc

On 8/2/2010 5:42 PM, Mark Lawrence wrote:
> On 02/08/2010 00:08, candide wrote:
>> Python is an object oriented langage (OOL). The Python main
>> implementation is written in pure and "old" C90. Is it for historical
>> reasons?
>>
>> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
>> suitable to implement an OOL with another one.
>>
>> Has it ever been planned to rewrite in C++ the historical implementation
>> (of course in an object oriented design) ?
>
> I can't understand why any serious programmer mentions C++. As soon as I
> read it, I have to rush either to the kitchen to find a bowl to throw up
> in, or head for the toilet so I can talk to the great white telephone.

It must be because we can not be as phenomenally intelligent as you 
evidently are from your comment.

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:
> OK, I have a copy of K&R 2nd Ed on a shelf within reach here. Can you point 
> out some behaviour that C programmers might need to rely on, that is not 
> specified in that document?

C has all kinds of undefined behavior.  "Might need to rely on" is not
relevant for this kind of issue.  Ada's designers had the goal that that
Ada programs should have NO undefined behavior. 

As a famous example of C's underspecification, the behavior of

   a[i++] = i;

is undefined in C99.  See:

https://www.securecoding.cert.org/confluence/display/seccode/EXP30-C.+Do+not+depend+on+order+of+evaluation+between+sequence+points

On Aug 1, 9:34=A0pm, Albert Hopkins <mar...@letterboxes.org> wrote:
> On Mon, 2010-08-02 at 01:08 +0200, candide wrote:
>
> I would propose that in fact most programming languages are implemented
> in C. =A0Sun's (Oracle's) Java compiler and runtime are written in ANSI C=
..
> The core of the Gnu Compiler Collection (which includes C++ and
> Objective-C compilers) is written in C.

The open-source GCC Ada compiler (GNAT) is written in Ada. The GPL'd
compiler source code is available at http://libre.adacore.com/libre/

Paul Rubin:

> C has all kinds of undefined behavior.  "Might need to rely on" is not
> relevant for this kind of issue.  Ada's designers had the goal that that
> Ada programs should have NO undefined behavior.

   Ada achieves this by describing a long list of implementation defined
behaviour (Annex M).
http://oopweb.com/Ada/Documents/Ada95RM/Volume/m.htm

> As a famous example of C's underspecification, the behavior of
> 
>    a[i++] = i;
> 
> is undefined in C99.

   Ada does not define ordering in all cases either. For example the
order of elaboration of library_items (essentially the order in which
modules are run in the absence of explicit declarations) is defined for
GNAT as

"""
first elaborating bodies as early as possible (i.e. in preference to
specs where there is a choice), and second by evaluating the immediate
with clauses of a unit to determine the probably best choice, and third
by elaborating in alphabetical order of unit names where a choice still
remains
"""

   Other compilers use different orders.

   I just love that "probably".

   Neil

In article <i3e43n$v7c$4@lust.ihug.co.nz>,
 Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:

> In message <roy-6BCFA7.22564104082010@news.panix.com>, Roy Smith wrote:
> 
> > C++, for all its flaws, had one powerful feature which made it very
> > popular.  It is a superset of C.
> 
> Actually, it never was.

Yes, there are a few corner cases where valid C syntax has different 
semantics in C and C++.  But, they are very few.  Calling C++ a superset 
of C is essentially correct.

It is certainly correct from the level of a risk-averse development 
manager deciding if he or she is willing to use C++ for the first time.  
Fear of the unknown is a powerful deterrent.  It's a lot easier to 
accept something like C++ because "it's just a superset of C, and we've 
been using C for years".

I suspect the same effect contributed to Java's success as well.  "Look, 
it's got curly braces and semicolons.  It's just like C!"

On Fri, Aug 6, 2010 at 8:45 AM, Roy Smith <roy@panix.com> wrote:
> In article <i3e43n$v7c$4@lust.ihug.co.nz>,
> =C2=A0Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>
>> In message <roy-6BCFA7.22564104082010@news.panix.com>, Roy Smith wrote:
>>
>> > C++, for all its flaws, had one powerful feature which made it very
>> > popular. =C2=A0It is a superset of C.
>>
>> Actually, it never was.
>
> Yes, there are a few corner cases where valid C syntax has different
> semantics in C and C++. =C2=A0But, they are very few. =C2=A0Calling C++ a=
 superset
> of C is essentially correct.

This is only true if you limit yourself to C89 (as python seems to
do). If  you start using C99 (and lot of people do, if only because
they don't realize it because gcc is quite relax about it), then
almost no non trivial C code is valid C++ in my experience.

David

In article <mailman.1666.1281075732.1673.python-list@python.org>,
 David Cournapeau <cournape@gmail.com> wrote:

> > Yes, there are a few corner cases where valid C syntax has different
> > semantics in C and C++.  But, they are very few.  Calling C++ a superset
> > of C is essentially correct.
> 
> This is only true if you limit yourself to C89 (as python seems to
> do). If  you start using C99 (and lot of people do, if only because
> they don't realize it because gcc is quite relax about it), then
> almost no non trivial C code is valid C++ in my experience.

I'm not following you.  If anything, C99 makes C closer to C++.  Can you 
give me some examples of valid C99 which is not also valid C++?

On Fri, Aug 6, 2010 at 8:39 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.1666.1281075732.1673.python-list@python.org>,
> =C2=A0David Cournapeau <cournape@gmail.com> wrote:
>
>> > Yes, there are a few corner cases where valid C syntax has different
>> > semantics in C and C++. =C2=A0But, they are very few. =C2=A0Calling C+=
+ a superset
>> > of C is essentially correct.
>>
>> This is only true if you limit yourself to C89 (as python seems to
>> do). If =C2=A0you start using C99 (and lot of people do, if only because
>> they don't realize it because gcc is quite relax about it), then
>> almost no non trivial C code is valid C++ in my experience.
>
> I'm not following you. =C2=A0If anything, C99 makes C closer to C++. =C2=
=A0Can you
> give me some examples of valid C99 which is not also valid C++?

variable size array, the meaning of inline, etc... In addition to int
f(void) vs int f(), legality vs illegality of p =3D malloc(n);, type of
enum, keyword incompatibility (new, delete, etc...) which are already
there in C89.

I have yet seen a project where you could build C code with a C++
compiler - the only ones I know are specifically designed that way and
it is painful.

David

In message <mailman.1681.1281102958.1673.python-list@python.org>, David 
Cournapeau wrote:

> I have yet seen a project where you could build C code with a C++
> compiler - the only ones I know are specifically designed that way and
> it is painful.

I seem to recall a FAQ entry, might have been on kernelnewbies.org, asking 
why the Linux kernel wasn’t written in C++. The answer explained that at one 
time there was an experiment to make the kernel compilable with a C++ 
compiler, without actually using any C++ features. The result: they lost 
about 10% in speed. That was enough to put the kernel developers off taking 
the experiment any further.

Lawrence D'Oliveiro wrote:

> at one 
> time there was an experiment to make the kernel compilable with a C++ 
> compiler, without actually using any C++ features. The result: they lost 
> about 10% in speed. That was enough to put the kernel developers off taking 
> the experiment any further.

FWIW, certain parts of the Darwin kernel are written in a
carefully-selected subset of C++. So Apple evidently think
that it makes sense to use some C++ in a Unix kernel under
some circumstances.

-- 
Greg

In article <roy-30C94B.20362001082010@news.panix.com>,
Roy Smith  <roy@panix.com> wrote:
>In article <4c55fe82$0$9111$426a34cc@news.free.fr>,
> candide <candide@free.invalid> wrote:
>
>> Python is an object oriented langage (OOL). The Python main
>> implementation is written in pure and "old" C90. Is it for historical
>> reasons?
>>
>> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more
>> suitable to implement an OOL with another one.
>
>One thing that comes to mind is that it's much easier to distribute C
>libraries than C++ libraries.
>
>If I compile a main program with one C compiler and you compile a
>dynamically loaded library with another C compiler on the same box, the
>odds are pretty good they'll interoperate without any problems.
>
>Not at all so with C++ compilers.  The linkage is *way* more
>complicated.  Not just how the two compilers do name mangling, but how
>they handle exceptions, RVO, and a zillion other details.  Pretty much
>the only way to make it work is to compile everything with exactly the
>same compiler.  That would make it pretty close to impossible for people
>to take a Python core distribution and add their own extension modules
>to it.

We had a similar discussion on comp.lang.forth.
The bottom line is that to implement a programming language
you want to use a simpler programming language, not a more
complicated one. Then there is a secondary requirement,
that language must allow sufficient access to low level features
to allow decent performance.
A third aspect is that Linux/Unices as well as Windows assume
OS interaction in terms of c-libraries. Any intermediary is
inconvenient at least.

Or in one catch phrase:
" To implement a programming language you need a high level
assembler like C."

(We went on whether Forth would be a suitable high level assembler
for Haskell. It would beat C++ -- not C --  for implementing Python,
that much I'm sure.)

Undoubtedly C is the right choice to implement Python.

Groetjes Albert



--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <roy-2FC4E0.19455005082010@news.panix.com>,
Roy Smith  <roy@panix.com> wrote:
>In article <i3e43n$v7c$4@lust.ihug.co.nz>,
> Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>
>> In message <roy-6BCFA7.22564104082010@news.panix.com>, Roy Smith wrote:
>>
>> > C++, for all its flaws, had one powerful feature which made it very
>> > popular.  It is a superset of C.
>>
>> Actually, it never was.
>
>Yes, there are a few corner cases where valid C syntax has different
>semantics in C and C++.  But, they are very few.  Calling C++ a superset
>of C is essentially correct.

One aspect of C++ is that all standard functions of C are called
in the same way. A large part of programs consists of stringing
API calls together. Those require little work to upgrade to
C++. So from a practical point of view this is very much true.

>
>It is certainly correct from the level of a risk-averse development
>manager deciding if he or she is willing to use C++ for the first time.
>Fear of the unknown is a powerful deterrent.  It's a lot easier to
>accept something like C++ because "it's just a superset of C, and we've
>been using C for years".

Even if it is overhyped, the C++ compiler vendors certainly tried
to make it happen.

>
>I suspect the same effect contributed to Java's success as well.  "Look,
>it's got curly braces and semicolons.  It's just like C!"

Of course!

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> We had a similar discussion on comp.lang.forth.

Heh, fancy meeting you here ;-)

> The bottom line is that to implement a programming language
> you want to use a simpler programming language, not a more
> complicated one. 

Nah, gas is written in C, and nobody implements VHDL as logic gates.

> (We went on whether Forth would be a suitable high level assembler
> for Haskell. It would beat C++ -- not C --  for implementing Python,
> that much I'm sure.)

Haskell (or at least certain parts of it) should probably be implemented
in Coq or Agda, which are even higher level than Haskell.

> Undoubtedly C is the right choice to implement Python.

Python has been experimentally implemented in Haskell:

  http://hackage.haskell.org/package/berp-0.0.2

but the most interesting implementation (not yet ready for production,
but a serious ongoing project partly funded by the EU) is written in
Python itself:

   http://codespeak.net/pypy/

In message <8c4g22F5ljU1@mid.individual.net>, Gregory Ewing wrote:

> FWIW, certain parts of the Darwin kernel are written in a
> carefully-selected subset of C++. So Apple evidently think
> that it makes sense to use some C++ in a Unix kernel under
> some circumstances.

I wonder if that explains Apple’s well-known multitasking problems. :)

In message <l6segt.nm9@spenarnc.xs4all.nl>, Albert van der Horst wrote:

> The bottom line is that to implement a programming language
> you want to use a simpler programming language, not a more
> complicated one.

That would rule out ever using a language to implement itself.

candide wrote:
> Python is an object oriented langage (OOL). The Python main
> implementation is written in pure and "old" C90. Is it for historical
> reasons?

The fact that Python is OOP doesn't mean that the implementation of it has
to be written using an OOP language.

Other than that, I'm actually surprised that nobody mentioned that Python
actually _is_ written in C++. Yes, it's restricted to a subset thereof that
is compatible to C, but you could also claim that it was written in a
subset of C compatible to C++.

:)

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

On Aug 9, 6:39=A0am, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> candide wrote:
> > Python is an object oriented langage (OOL). The Python main
> > implementation is written in pure and "old" C90. Is it for historical
> > reasons?
>
> The fact that Python is OOP doesn't mean that the implementation of it ha=
s
> to be written using an OOP language.
>
> Other than that, I'm actually surprised that nobody mentioned that Python
> actually _is_ written in C++. Yes, it's restricted to a subset thereof th=
at
> is compatible to C, but you could also claim that it was written in a
> subset of C compatible to C++.
>
> :)

I highly doubt the Python source would build with a C++ compiler.

C++ is "'mostly' 'backwards' compatible" with C insofar as you can
pretty easily write C code that is also legal (and semantically
equivalent) C++.  But if you don't actively try to write code that is
compatible with both languages, chances are the C code will invoke one
of those "'minor' 'backwards' incompatibilies", the most common one
being failure to cast a pointer.


Carl Banks

> I highly doubt the Python source would build with a C++ compiler.
> 
> C++ is "'mostly' 'backwards' compatible" with C insofar as you can
> pretty easily write C code that is also legal (and semantically
> equivalent) C++.  But if you don't actively try to write code that is
> compatible with both languages, chances are the C code will invoke one
> of those "'minor' 'backwards' incompatibilies", the most common one
> being failure to cast a pointer.

Indeed:

g++ -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3
-Wall   -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/parsetok.o
Parser/parsetok.c
Parser/parsetok.c: In function 'node* parsetok(tok_state*, grammar*,
int, perrdetail*, int*)':
Parser/parsetok.c:251: error: invalid conversion from 'void*' to 'char*'
make: *** [Parser/parsetok.o] Error 1

Beside from several invalid conversions Python could most probably be
compiled with a g++ compiler. I once worked on a patch to fix the
conversion issues but Martin argued against it. There isn't really a
point in cluttering the source with type casts.

Christian

Carl Banks wrote:
> I highly doubt the Python source would build with a C++ compiler.

As Christian showed, it doesn't. However, look around the sources a bit.
There are lots of places where e.g. the returnvalue of malloc() (or,
rather, the macro that resolves to something like it) is explicitly
type-cast to the according pointer type. When asked on the developers'
list, it was said that this was intended for compatibility with C++, e.g.
in cases where people want to embed Python into their C++ projects. Of
course, this contradicts Christian's statement that C++ compatibility
wasn't considered useful enough.

*shrug*


Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

In message <mailman.1863.1281378450.1673.python-list@python.org>, Christian 
Heimes wrote:

> There isn't really a point in cluttering the source with type casts.

Makes you wonder why they bothered using a typed language at all.

On Aug 10, 12:06=A0am, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> Carl Banks wrote:
> > I highly doubt the Python source would build with a C++ compiler.
>
> As Christian showed, it doesn't. However, look around the sources a bit.
> There are lots of places where e.g. the returnvalue of malloc() (or,
> rather, the macro that resolves to something like it) is explicitly
> type-cast to the according pointer type. When asked on the developers'
> list, it was said that this was intended for compatibility with C++, e.g.
> in cases where people want to embed Python into their C++ projects. Of
> course, this contradicts Christian's statement that C++ compatibility
> wasn't considered useful enough.

I question why it needs to be compatible with C++ to be able to embed
Python in a C++ project.  How many C++ compilers out there don't come
bundled with a C compiler?


Carl Banks

Am 10.08.2010 09:06, schrieb Ulrich Eckhardt:
> Carl Banks wrote:
>> I highly doubt the Python source would build with a C++ compiler.
> 
> As Christian showed, it doesn't. However, look around the sources a bit.
> There are lots of places where e.g. the returnvalue of malloc() (or,
> rather, the macro that resolves to something like it) is explicitly
> type-cast to the according pointer type. When asked on the developers'
> list, it was said that this was intended for compatibility with C++, e.g.
> in cases where people want to embed Python into their C++ projects. Of
> course, this contradicts Christian's statement that C++ compatibility
> wasn't considered useful enough.

It doesn't contradict at all. In order to embed Python into a C++
application, it is sufficient if the Python header files can be compiled
with a C++ compiler, and linking to the C function works
properly - which is indeed the case.

People integrate Python with C++ quite often, both for embedding it
into C++, and for writing extension modules in C++.

Regards,
Martin

Martin v. Loewis wrote:
> Am 10.08.2010 09:06, schrieb Ulrich Eckhardt:
>> When asked on the developers' list, it was said that this was
>> intended for compatibility with C++, e.g. in cases where people
>> want to embed Python into their C++ projects. Of course, this
>> contradicts Christian's statement that C++ compatibility 
>> wasn't considered useful enough.
> 
> It doesn't contradict at all. In order to embed Python into a C++
> application, it is sufficient if the Python header files can be compiled
> with a C++ compiler, and linking to the C function works
> properly - which is indeed the case.

That's true, maybe I don't remember the exact rationale. Especially if even
someone like you, who is much deeper into Python development, doesn't, I'm
wondering if I'm misremembering something....

Cheers!

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

On 11 Aug, 08:40, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:

> That's true, maybe I don't remember the exact rationale. Especially if even
> someone like you, who is much deeper into Python development, doesn't, I'm
> wondering if I'm misremembering something....

Header (definition) and source (implementation) is not the same. A C++
compiler can use Python's header files and link with Python's C API
correctly. But it cannot compile Python's C source code. A C compiler
is required to compile and build Python.

sturlamolden wrote:
> On 11 Aug, 08:40, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> Header (definition) and source (implementation) is not the same. 

I'm aware of this and that's not the thing I was talking about.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

In article <i3ahdl$ce9$1@reader1.panix.com>,
Grant Edwards  <invalid@invalid.invalid> wrote:
>
>I also looked at Modula-3 once, and thought it had some real promise,
>but I think it's probably deader than Ada now.

That's because you should be using Oberon instead.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells

In article <7xeieevrze.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>
>I'm not sure what the hiring issue is.  I think anyone skilled in C++ or
>Java can pick up Ada pretty easily.  It's mostly a subset of C++ with
>different surface syntax.

Heck, I learned Ada as a sixteen-year-old knowing only BASIC and Pascal.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells

In message
<44d30ac7-931e-4eb0-9aed-f664c872d438@l20g2000yqm.googlegroups.com>, 
sturlamolden wrote:

> A C++ compiler can use Python's header files and link with Python's C API
> correctly. But it cannot compile Python's C source code. A C compiler
> is required to compile and build Python.

Since when do you find a C++ compiler not accompanied by a C one?

On 2010-08-14, Aahz <aahz@pythoncraft.com> wrote:
> Paul Rubin  <no.email@nospam.invalid> wrote:
>>
>>I'm not sure what the hiring issue is.  I think anyone skilled in C++ or
>>Java can pick up Ada pretty easily.  It's mostly a subset of C++ with
>>different surface syntax.
>
> Heck, I learned Ada as a sixteen-year-old knowing only BASIC and Pascal.

Unfortunately, there just aren't that many Aahzes to hire (sixteen
years old or otherwise), and of the non-Aahz progrommers out there
it's shocking how many of them them are apparently incapable of
learning a second language.

Regardless of how easy something is to learn, management always wants
to hire people who don't have to.

-- 
Grant


 

In message <i472rp$i48$1@panix5.panix.com>, Aahz wrote:

> Heck, I learned Ada as a sixteen-year-old knowing only BASIC and Pascal.

Not so surprising, considering Ada was consciously modelled on Pascal.