Making C better (by borrowing from C++)

[websnarf]

Try declaring an enum with floating point type. Or using a const
int as a case value. I think that C++ should have found something
else to call them (and both C and C++ should have stopped the
overloading of the 'static' keyword, C++ even adds yet another
meaning to it), but typed constants are useful and don't have the
pitfalls of macros.

Ok, I see -- you really want are read-only variables. Fair enough.

Used properly (as in declaring loop variables only when they are
used) it makes it more readable, not less. I've seen a lot of
errors where someone has used a variable (often i or j) for a loop,
it has compiled (it was already declared) but it has done unexpected
things because it wasn't obvious that the variable was already in
use.

Ok, so then that's just it, then isn't it? Using it "properly" as you
say boils down to declarations of variables in the first expression of
a control statement such as for, while, if, or switch. Fine, but
that's a narrower extension than C++'s scheme.

At least my namespace extension remains intact.

 

[jacob navia]

And what happens when you want to port that source code to a platform
that doesn't have a compiler with your extensions?

Most of it compiles in C++.

 

[Randy Howard]

Most of it compiles in C++.

So you assume that all platforms even have a C++ compiler? If so,
then why not just write in C++ to begin with?

 

[Chris Croughton]

Ok, I see -- you really want are read-only variables. Fair enough.

No, I have read-only variables in C, that's what C const does. What I
would like is the C++ "named typed constants", they aren't variables at
all (they may not have any existence in storage in many cases).

Ok, so then that's just it, then isn't it? Using it "properly" as you
say boils down to declarations of variables in the first expression of
a control statement such as for, while, if, or switch. Fine, but
that's a narrower extension than C++'s scheme.

What do you mean by "the first expression"?

Actually, using variable declaration mixed with code can be readble in
other cases as well, but in my opinion the use in a control statement
(and personally I only use them in for loops) is the most useful and the
one which definitely makes the code clearer. The ability to declare
them anywhere, as in C++, can not only make the code les clear but can
muddy the syntax itself (there are cases in C++ where it is ambiguous
whether something is a declaration or a statement).

At least my namespace extension remains intact.

IMO namespaces definitely make things clearer and are a Good Thing(tm).
Possibly the best feature of C++...

Chris C

 

[Keith Thompson]

How would you deal with resizing? old?

I don't know. Since realloc() isn't used all that much, perhaps it
could remain a library function. I'll let you know when I get around
to designing a C-like language from scratch.

(Not sure what you mean by "old?".)

 

[Keith Thompson]

On 12 Feb 2005 19:13:45 -0800, (e-mail address removed)


Used properly (as in declaring loop variables only when they are used)
it makes it more readable, not less. I've seen a lot of errors where
someone has used a variable (often i or j) for a loop, it has compiled
(it was already declared) but it has done unexpected things because it
wasn't obvious that the variable was already in use.

You're talking about a different feature. For loop variables, you can
do the following:

...
for (i = 0; i < N; i ++) { ... }

Independently, you can do:

int i;
/* code that uses i */
int j;
/* code that uses j */

If abused, this can cause confusion, but it does add some flexibility.

Both features are supported in C99 and C++, and not in C90.

 

[infobahn]

I don't know. Since realloc() isn't used all that much,

It isn't? Perhaps I use it more than most, then.

perhaps it
could remain a library function. I'll let you know when I get around
to designing a C-like language from scratch.

(Not sure what you mean by "old?".)

Nothing more sinister than "not exactly new"

 

[Serve Lau]

How would you deal with resizing? old?

renew?

 

[infobahn]

renew?

Much better

 

[Guillaume]

Since C already has malloc() and free(), new and delete wouldn't add

renew?

Come on, "real C++ programmers" don't resize. They just allocate more
objects and delete the old stuff (that is, when they don't forget to).

That leads to bloatware, but new is so "cute" compared to malloc().
lol ;-)

 

[Richard Bos]

Used properly (as in declaring loop variables only when they are used)
it makes it more readable, not less.

Agreed, but that's the only occasion where it does so. C99 would've been
just as useful, and less prone to obfuscation, if they'd allowed
for (int i=0; i<LIMIT; i++) while disallowing sprinkling your
declarations all over the place.

Definitely. Then we could get rid of "static used for
non-external-scope" and leave it for "variable does not change between
invocations of the function".

Provided it doesn't force me to use <namespace>::<identifier> for bloody
everything including library functions and my own local and global
variables.

Richard

 

[Dave Vandervies]

Come on, "real C++ programmers" don't resize. They just allocate more
objects and delete the old stuff (that is, when they don't forget to).

I'm not sure about the "real C++ programmers", but real C++ programmers
use a std::vector when they need something resized.

Which means if you want to replace malloc and free with new and delete,
and still want to be able to resize something, you'd also need to add
something not entirely unlike classes to hide the resizing behind,
and something not entirely unlike templates to let the something-not-
entirely-unlike-classes work for any type you care to use them for, and...

It's at this point that the last holdouts usually start saying things like
"If you want C++, you know where to find it".


dave

 

[jacob navia]

Which means if you want to replace malloc and free with new and delete,
and still want to be able to resize something, you'd also need to add
something not entirely unlike classes to hide the resizing behind,
and something not entirely unlike templates to let the something-not-
entirely-unlike-classes work for any type you care to use them for, and...

Not at all.

I have been able to program a resizable strings package using just
operator overloading in lcc-win32.

This strings are length prefixed structures, that will resize themselves
when new data is appended to them using Strcat, for instance.

They are accessed with the overloaded [ ] operators.

In the version of operator overloading in lcc-win32 you can overload
the [ ] = operator, i.e. you can know when a string is accessed
in read mode or in write mode (assignment to a string element)

int operator [ ]=(String str,int index,int newadata);

Then you just write:
String s;

s[5] = 'a';

A similar package could be developed (and it has been started) for
a general vector facility.

No classes are needed at all. Everything is simpler and more
easier to do.

Unfortunately this has led to many people in both the C and C++
communities to react very emotionally... mostly because it questions
some fundamental assumptions in both languages.

 

[CBFalconer]

.... snip ...

I have been able to program a resizable strings package using just
operator overloading in lcc-win32.
.... snip ...

Then you just write:
String s;

s[5] = 'a';

A similar package could be developed (and it has been started) for
a general vector facility.

No classes are needed at all. Everything is simpler and more
easier to do.

Unfortunately this has led to many people in both the C and C++
communities to react very emotionally... mostly because it questions
some fundamental assumptions in both languages.

Not because it is necessarily a bad idea, but because it is
non-standard, and thus non-portable. Therefore discussion about it
does NOT belong here. You could argue for inclusion in a future
standard in comp.std.c if you wish. And comp.compilers.lcc is also
eminently suitable, so I have crossed it there and set f'ups.

 

[jacob navia]

jacob navia wrote:

... snip ...

I have been able to program a resizable strings package using just
operator overloading in lcc-win32.

... snip ...

Then you just write:
String s;

s[5] = 'a';

A similar package could be developed (and it has been started) for
a general vector facility.

No classes are needed at all. Everything is simpler and more
easier to do.

Unfortunately this has led to many people in both the C and C++
communities to react very emotionally... mostly because it questions
some fundamental assumptions in both languages.

Not because it is necessarily a bad idea, but because it is
non-standard, and thus non-portable. Therefore discussion about it
does NOT belong here. You could argue for inclusion in a future
standard in comp.std.c if you wish. And comp.compilers.lcc is also
eminently suitable, so I have crossed it there and set f'ups.

The thread is labelled:
"Making C better by borrowing from C++".

I do not see how that can be "portable" or "within the C standard"
since the subject matter of the discussion is the improvement of
C.

Mine was one among many other contributions to that thread, but the
only one that deserved this "off topic" answer.

 

[tomstdenis]

So you assume that all platforms even have a C++ compiler? If so,
then why not just write in C++ to begin with?

Shhhh...

Not you're supposed to use his ultra-cool proprietary compiler...It has
ADVANCED technology!

I used to like Navia back when he started lcc-win32 but then he went
all commercial, didn't really improve it [the IDE was still buggy when
I last used it] and started on adding "new features"... Shame cuz
lccwin32 was cool [small, relatively stable and could develop C windows
app quickly].

Oh well, guess I'll stick to the FREE gcc which optimizes a HELL OF A
LOT BETTER and doesn't go on such wild tagents.. ;-)

Tom

 

[CBFalconer]

.... snip ...

The thread is labelled:
"Making C better by borrowing from C++".

I do not see how that can be "portable" or "within the C standard"
since the subject matter of the discussion is the improvement of C.

Mine was one among many other contributions to that thread, but the
only one that deserved this "off topic" answer.

A justified criticism. I apologize. However you have been in the
habit of injecting off-topic themes into c.l.c. BTW, "was
labelled" - I rechristened it to suit the subject drift.

 

[E. Robert Tisdale]

I know that this topic may inflame the "C language Taleban"
but is there any prospect
of some of the neat features of C++ getting incorporated in C?
No I am not talking out the OO stuff.
I am talking about the non-OO stuff
that seems to be handled much more elegantly in C++, as compared to C.
For example, consts, declaring variables just before use,

Already adopted by C99.

new & delete, references, etc.

Implies constructors and destructors (OO stuff).

I am asking this question with a vested interest.
I would really like to use these features in my C programs.

You can make C better by simply using these C++ features
and compiling with a C++ compiler.
This means that you should take care to ensure that
every C program that you write is also a valid C++ program.

The only reason that C exists
is so that C programmers can maintain legacy codes.
C programmers don't want C to evolve or grow.
They aren't enthusiastic about the new features introduced in C99
and compiler developers haven't fully implemented them [yet]
so I don't think that there will be much interest
in adding the C++ features that you have mentioned.

 

[infobahn]

You can make C better by simply using these C++ features
and compiling with a C++ compiler.

Writing C++ programs does nothing to improve or detract from C.
If you compile with a C++ compiler, you are compiling a C++
program, not a C program.

This means that you should take care to ensure that
every C program that you write is also a valid C++ program.

Why bother? If you want C++, you know where to find it.

The only reason that C exists
is so that C programmers can maintain legacy codes.

That's one minor reason. There are plenty of major reasons.

C programmers don't want C to evolve or grow.

You don't think C++ is an evolution of C?

They aren't enthusiastic about the new features introduced in C99

Can't wait. But C99 isn't portable; in fact, it's less portable than
C++.

and compiler developers haven't fully implemented them [yet]
so I don't think that there will be much interest
in adding the C++ features that you have mentioned.

Whoa, something we agree on. Even a stopped clock is right twice a day.

 

[E. Robert Tisdale]

E. Robert Tisdale wrote:

Writing C++ programs does nothing to improve or detract from C.
If you compile with a C++ compiler,
you are compiling a C++ program, not a C program.

Correct! Every C program should also be a valid C++ program.

Why bother? If you want C++, you know where to find it.

I want both.

That's one minor reason. There are plenty of major reasons.

Name ten.

You don't think C++ is an evolution of C?

C++ programmers want C++ to evolve and grow.

Can't wait.

Why are you waiting then?

But C99 isn't portable; in fact,
it's less portable than C++.

Really?
Which of your target platforms doesn't have C99 support
for the features that Masood mentioned?

and compiler developers haven't fully implemented them [yet]
so I don't think that there will be much interest
in adding the C++ features that you have mentioned.

Whoa, something we agree on.

Nonsense!
When have you every complained to a compiler developer
about missing C99 features?