c to c++

[Richard]

That's a different kind of laziness. I program computers because I am
too lazy to do drudge work, but I don't want them programmed by people
who are too lazy to learn.

Richard

That's very sacrificial of you. You will go to heaven for your concern
to protect others from other peoples laziness and ineptitude.

 

[user923005]

On Feb 10, 5:12 am, (e-mail address removed) wrote:
[snip]

I've seen large code bases that were written in "C" and
compiled with C++

Can you give an example for which we can access the C code that was
not designed to operate this way from the start (IOW, if I am writing
C code and I know I am going to have to use a C++ compiler then the
code I write will be written under that assumption and I will be
careful to ensure that it works properly using the C++ compiler).

I have never seen this happen (I have done a large number of
conversions to C++ from C and never saw one that was painless if the
code base was not trivial).

 

[Dik T. Winter]

> I've seen large code bases that were written in "C" and
> compiled with C++

I gave up on C++ (quite some time ago) when I had to implement a program
written in C++ for an SGI, so that it would work on both SGI and Sun. The
SGI variant did not compile on the Sun and when I rewrote parts so that it
would compile (and work) on the Sun, it did no longer compile on the SGI.

The reason was that the compilers complied to different versions of C++,
and a particular construct had to be written differently for the two
compilers. And, don't ask me, it is too long ago to remember exactly.

I never did encounter something similar with C, even when there was not
yet a standard. In my opinion, C++ has too long been a moving standard
with changing syntax on its way.

 

[Ian Collins]

I gave up on C++ (quite some time ago) when I had to implement a program
written in C++ for an SGI, so that it would work on both SGI and Sun. The
SGI variant did not compile on the Sun and when I rewrote parts so that it
would compile (and work) on the Sun, it did no longer compile on the SGI.

That would have been a long time ago.

The reason was that the compilers complied to different versions of C++,
and a particular construct had to be written differently for the two
compilers. And, don't ask me, it is too long ago to remember exactly.

I never did encounter something similar with C, even when there was not
yet a standard.

You're not old enough!

> In my opinion, C++ has too long been a moving standard
> with changing syntax on its way.

C++ was standardised in 1989 and unlike C99, all vendors quickly fell in
line.

The C standardisation process could learn a lot from the C++ one,
standardise existing practice and give developers what they want.

 

[Ian Collins]

Ian Collins said:


Either you mean C or you mean 1998.

A lisp of the fingers...

True for C89, but not for C++, where conforming implementations are
still rare (and that's for the /first/ C++ Standard, never mind the
second one!).

Those that don't conform do so consistently, a de facto non-conformance...

 

[Guest]

(e-mail address removed) said:



That's a logical point of view - and anyone who needs convincing of
this is unlikely to be persuaded by logic.

ah! How foolish of me not to have noticed that!
This comes from being a member of the reality based community
I suppose.

http://en.wikipedia.org/wiki/Reality-based_community

 

[Guest]

The C standardisation process could learn a lot from the C++ one,
standardise existing practice and give developers what they want.

surely you mean that the other way around! At times C++ was
very painful. I have three versions of Stroustrup's book...
I have Plauger's book on the library- before they templatised
it...

I have a large source base that cannot be compiled
with a modern C++ compiler.

Even now Boost has various hacks to make it work with
different compilers.

Does everyone implement export?

 

[user923005]

That would have been a long time ago.



You're not old enough!

I programmed in C before the standard and I'm only 51. Now, I did
have problems *before* the C standard with things like Lattice C and
Manx C and etc. sharing a common code base. Header names were
different, for example. But at least you could make it work with some
fiddling.

 > In my opinion, C++ has too long been a moving standard
 > with changing syntax on its way.

C++ was standardised in 1989 and unlike C99, all vendors quickly fell in
line.

C++ that was written in 1989 will not compile in 1999.
C++ that was written in 1999 will not compile in 2009.

E.g.:
#include <iostream.h>
The strange thing about the C++ standardization process is that
updates invalidate the old code base.

I do understand that namespaces are cool and that the new casts really
do add some functionality, etc. but backwards incompatibility stuff
can be problematic.

C that was written in 1989 will compile in 1999.
C that was written in 1999 will compile in 2009.

That is what Dik is complaining about, I think.

The C standardisation process could learn a lot from the C++ one,
standardise existing practice and give developers what they want.

Isn't that what C did?

P.S.
I do almost all of my coding in C++.

 

[Ian Collins]

C++ that was written in 1989 will not compile in 1999.
C++ that was written in 1999 will not compile in 2009.

It will if you use the compiler it was written for, or tell you modern
compiler to accept old code.

E.g.:
#include <iostream.h>
The strange thing about the C++ standardization process is that
updates invalidate the old code base.

I think that was a good thing, they had the courage to make changes for
the better that would break existing code. C still hasn't got rid of
gets. Admittedly there's a lot more C code around than there was C++
code in 1998. Don't forget standardising had to break some code as
pre-standard compilers were inconsistent. I can't think of anything off
hand in the new standard that breaks code conforming to the current one.

Isn't that what C did?

I didn't see the masses clamouring for _Complex!

 

[user923005]

user923005 wrote: [snip]

Isn't that what C did?

I didn't see the masses clamouring for _Complex!

<OT Aside>
I think C++ is the only way to go for complex math.
I do wish that they had an exponentiation operator like Fortran
though.
</OT Aside>

 

[Guest]

It will if you use the compiler it was written for, or tell you modern
compiler to accept old code.

that option doesn't always appear to be available.
For instance new MS compilers won't compile code that
old MS compilers will.

I think that was a good thing, they had the courage to make changes for
the better that would break existing code.

int func()
{
for (int i = 0; i < last; i++)
proc_a();

for (int i = 0; i < last; i++)
proc_b();
}

 

[Ian Collins]

int func()
{
for (int i = 0; i < last; i++)
proc_a();

for (int i = 0; i < last; i++)
proc_b();
}

?

 

[user923005]

?

Some compilers will accept this and others will reject it (variable i
already declared).

 

[Ian Collins]

Some compilers will accept this and others will reject it (variable i
already declared).

That was a bug (amongst many) in an old Microsoft compiler (which true
to form, they refused to fix), long replaced.

 

[robertwessel2]

That was a bug (amongst many) in an old Microsoft compiler (which true
to form, they refused to fix), long replaced.

Not to defend MS too much, but they've long had a policy, more-or-less
actually adhered to, of not doing language changes within a release.
MS still gets grief for the template support in VC6 (despite being
more than a decade old), which was based on a pre-standard definition
of templates. Moving "standard" template code to VC6 is at best an
interesting exercise. They did fix it in the next release, however,
and people with VC6 style template still got to run VC6 and install
current VC6 patches, without having their code break.

Of course the line between a compiler bug and a language change is
fuzzy at best, but the MS behavior you're describing is actually
consistent with some of what Stroustrup wrote (see at least some
versions of "The Annotated C++ Reference Manual"), in that the scope
of the variable defined inside the "for" extends to the end of the
block *enclosing* the "for." Which allows you to test the value of
that variable after the "for" ends (which is certainly not uncommon in
general). So altering that to be standard compliant would, in fact,
break code. But MS did fix it in later versions of VC (there's still
a compiler option to do it either way).

Nor was MS the only one to make that mistake, nor are they the only
ones with compiler options to adjust the behavior (at the very least
HP comes to mind).

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> That would have been a long time ago.

Not so very long ago, I just checked: 1993.

>
> You're not old enough!

I do not know. I have been programming in C (as my sixth programming
language) since about 1980.

>
> C++ was standardised in 1989 and unlike C99, all vendors quickly fell in
> line.

That is wrong. In 1993 the program I meant was intended to be used with the
SGI C++ compiler and the GNU C++ compiler. But on the Sun we used AT&T's
C++ compiler which was newer than the two others, and the program did not
compile with it.

> The C standardisation process could learn a lot from the C++ one,
> standardise existing practice and give developers what they want.

This is the wrong way around. When successive standards invalidate earlier
programs the process is going the wrong way. Especially with respect to
syntax things should not change. That is, something that is syntactically
correct should remain so in a new version of the standard. Also the addition
of new keywords should be done sparingly and carefully. Luckily the first two
languages I did used had no reserved keywords at all and one of them
(Fortran) still is used and still does not have reserved keywords.

Something else is library functions. Of course the semantics of them should
not change, but they can be removed (with an obvious fade-out period). If
someone needs them it is in general easy for the user to implement them (viz.
'gets').

One of my worst experiences was when we shifted from an Algol-60 implementation
that implemented the full standard to an implementation of a standard written
by amongst others, Knuth, in (I think) about 1975. Not only was there a
change from a language without keywords to a language with keywords, but there
were also severe restrictions on what was possible. Luckily CDC had
committed itself to come with a full Algol 60 compiler and after only a
short time we could use that one.

And I was not even involved in the writing of large programs but of libraries
of routines in numerical mathematics.

 

[Ian Collins]

Not so very long ago, I just checked: 1993.

Which is an age in programming language evolution, and well before the
language was standardised.

That is wrong.

I know, I should have typed 1998.

This is the wrong way around. When successive standards invalidate earlier
programs the process is going the wrong way. Especially with respect to
syntax things should not change. That is, something that is syntactically
correct should remain so in a new version of the standard.

Indeed. But nothing can be syntactically correct when there isn't a
standard to define the syntax!

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> Which is an age in programming language evolution, and well before the
> language was standardised.

Right, but at that time the de facto standard came from AT&T.

>
> Indeed. But nothing can be syntactically correct when there isn't a
> standard to define the syntax!

There was a de facto standard. Just as there was one for C before 1989.
I have seen the C de facto standard change, so much so that I have encountered
plenty compilers that accepted =+ as a substitute for +=. And I have seen
programs fail later because they did not use the "int" keyword in the
declaration. But none of those changes was as significant as the change
the was made in the de facto standards of C++ in 1993. At that time it
was impossible to make the program compile both by the (newer) AT&T compiler
and the (older) SGI compiler. I know, I tried.

 

[CBFalconer]

.... snip ...


Isn't that what C did?

P.S. I do almost all of my coding in C++.

Sympathy.

 

[CBFalconer]

Some compilers will accept this and others will reject it
(variable i already declared).

All C89 compilers should reject it. All C99 compilers should
accept it. None should emit that error message.