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 new & delete, references, consts,
declaring variables just before use etc.
I am asking this question with a vested interest. I would really like
to use these features in my C programs.
Masood
85  3164  ma**********@lycos.com wrote:
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 new & delete,
Pointless without adding constructors and destructors too, which
might be further than the C community wants to go.
references,
An excellent way to confuse people still further wrt pointers.
consts,
Got them.
declaring variables just before use etc.
Got them in C99.
On 12 Feb 2005 05:36:00 -0800, ma**********@lycos.com
<ma**********@lycos.com> wrote: 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 new & delete, references, consts,
declaring variables just before use etc.
Note that quite a few features have already made it back -- void,
declaring variables in the middle of code, single-line comments for
instance.
There is no point to new and delete without constructors and
destructors, and to have those you'd need to introduce classes (and then
you'd have "C with classes", which was how C++ started out.
References are nice in some ways, but are really just syntactic sugar
round pointers, and can be even more confusing (especially when it isn't
obvious that a parameter may change).
Proper named and typed constants would indeed be useful, C's version of
const is a compiler convenience, and I can see those making it into C at
some point, but most of the other features depend on classes.
I can think of other things I'd like more. A typeof operator, for
example, and to have known-width arithmetic types build into the
language instead of via a header file (which isn't guaranteed to even
provide them). I'd really like a portable way of having enum values as
strings so that I could use strtoenum() for input and a printf
descriptor to output an enum as its named values. I'd like those in C++
as well...
I am asking this question with a vested interest. I would really like
to use these features in my C programs.
Why not use C++ instead, if that's what you like? That's what I do, I
use C++ for things where I want high-level features and I use C for
portability (adding C++ features to C won't make them portable, we're
over 5 years after the last C standard came out and I still can't safely
assume that any of the features introduced are portable (there seems to
be possibly one compiler and library which is fully C99 compliant) and
some systems don't even fully implement the standard from 10 years
before that).
Chris C
Chris Croughton wrote:
.... snip ...
References are nice in some ways, but are really just syntactic
sugar round pointers, and can be even more confusing (especially
when it isn't obvious that a parameter may change).
I used to miss them sorely, but eventually got used to the idea
that the caller can tell when it is exposing its internal data to
outside influence without examining the header of the called
function. Of course the cost is that pointers are not under
control, and that proper verification is impossible to all
practical purposes.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson ma**********@lycos.com wrote: 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 new & delete, references, consts,
declaring variables just before use etc.
I am asking this question with a vested interest. I would really like
to use these features in my C programs.
Masood
The lcc-win32 compiler adds some features of C++ like:
o operator overloading
o default arguments to functions
o references
Declaring variables just vefore use is part of the
C99 standard http://www.cs.virginia.edu/~lcc-win32
On 12 Feb 2005 05:36:00 -0800, in comp.lang.c , ma**********@lycos.com
wrote: 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?
Some C++ features made it into C99. Others don't make sense in C, such as
new, delete, reference variables and so forth. For your info consts have
been in C for decades, and declare-before-use is in C99.
I am asking this question with a vested interest. I would really like
to use these features in my C programs.
Then use C++
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
On 12 Feb 2005 05:36:00 -0800, in comp.lang.c , ma**********@lycos.com
wrote: 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?
Some C++ features made it into C99. Others don't make sense in C, such as
new, delete, reference variables and so forth. For your info consts have
been in C for decades, and declare-before-use is in C99.
I am asking this question with a vested interest. I would really like
to use these features in my C programs.
Then use C++
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
In article <11**********************@l41g2000cwc.googlegroups .com>, ma**********@lycos.com wrote: I know that this topic may inflame the "C language Taleban"
Not very clever starting with an insult like that, if you want to be
taken serious?
On Sat, 12 Feb 2005 18:47:44 GMT, CBFalconer
<cb********@yahoo.com> wrote: Chris Croughton wrote:
... snip ...
References are nice in some ways, but are really just syntactic
sugar round pointers, and can be even more confusing (especially
when it isn't obvious that a parameter may change).
I used to miss them sorely, but eventually got used to the idea
that the caller can tell when it is exposing its internal data to
outside influence without examining the header of the called
function. Of course the cost is that pointers are not under
control, and that proper verification is impossible to all
practical purposes.
When I'm writing C++ I use reference parameters, because I like the
cleanness of the call. However I've been bitten by them several times,
so it's a kind of "love-hate" relationship, I can see good reasons both
for using them and for avoiding them. The thing I do like and miss from
C++ (which C99 has now but none of the compilers for which I have to
write portable C code supports) is declaring 'local' loop variables:
for (int i = 0; i < n; ++i)
...
I'm always forgetting that C89 doesn't have that...
Chris C ma**********@lycos.com writes: 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 new & delete, references, consts,
declaring variables just before use etc.
As others have pointed out, some of these things are already in C99.
And I believe that prototypes were first introduced in (pre-standard)
C++ and added to C with the 1989 ANSI standard. I don't think there's
any great resistance to the idea of adding some C++ features to C *if*
they fit into the C language.
On the other hand, if you want C++ features that C doesn't have, the
easiest way to get them is to use C++.
Incidentally, calling people "Taleban" is a really bad way to
influence them.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <11**********************@l41g2000cwc.googlegroups .com>, ma**********@lycos.com says... 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.
What would be the point? There is nothing precluding you from using
C++, without the "OO stuff", to write whatever it is you are interested
in that you can't do the way you want it done in pure C.
I am talking about the non-OO stuff, that seems to be handled much
more elegantly in C++, as compared to C.
C++ is over there --------->
I am asking this question with a vested interest. I would really like
to use these features in my C programs.
Rename your C program file extensions to .cpp, find every occurrence
of code in those programs that uses something in a different way than
it is in C++, then add those features that you like from C++.
The proper place to discuss this is in a newsgroup with "c++" in the
title.
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig
In article <42***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says... The lcc-win32 compiler adds some features of C++ like:
And using those features means you are writing in some other
language that is not C, call it "Navia" perhaps?
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig ma**********@lycos.com wrote: 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 new & delete,
new & delete are really tied to to the semantics of constructor and
destructors in C++. There is little point in adding them to C without
adding the whole "class" paradigm.
[...] references,
Yes, I absolutely agree with this. References allow a receiving
function to better rely on the fact that the variable is supposed to be
backed by valid memory -- specifically it gives a syntactically sound
way of passing "pointers" that have better chances of being good at
compile time (its still possible to pass an array element that's beyond
the array's boundaries -- but at least you know you can't pass a
pointer to the heap that has been freed, or NULL, or just pure
garbage). As it is today, C programmers do this with raw pointers
which increases the potential danger by allowing for semantics that
usually are not intended.
[...] consts,
C has const. I don't quite see how C++'s consts are not redundant with
either #define or enums. You can even make enums locally scoped.
declaring variables just before use etc.
This is in C99, and personally I would rather have seen this *REMOVED*
from C++, than added to C. It makes the job of reading code twice as
hard -- if we wanted that, we might as well be using Perl. If you want
to do "just in time constructors", wrap your code with additional
scope.
I am asking this question with a vested interest. I would really
like to use these features in my C programs.
Personally, I think namespace should be added to that list. The single
shared global namespace situation that exists in C today is nothing
short of haphazard.
--
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
Keith Thompson wrote:
Incidentally, calling people "Taleban" is a really bad way to
influence them.
That kind of depends on what you mean by "influence". we******@gmail.com writes:
[...] new & delete are really tied to to the semantics of constructor and
destructors in C++. There is little point in adding them to C without
adding the whole "class" paradigm.
They're tied to constructors and destructors in C++, but they needn't
be in C. They could be added to the language as built-in versions of
malloc() and free(). For example:
int *ptr = new int;
...
delete ptr;
is valid C++, and has nothing to do with constructors or destructors.
Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
[...]
Personally, I think namespace should be added to that list. The single
shared global namespace situation that exists in C today is nothing
short of haphazard.
Agreed.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
How would you deal with resizing? old? we******@gmail.com wrote: ma**********@lycos.com wrote:
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 new & delete,
new & delete are really tied to to the semantics of constructor and
destructors in C++. There is little point in adding them to C without
adding the whole "class" paradigm.
I agree. there is not a lot to be gained with "new" and "delete"
without going into constructors.
[...] references,
Yes, I absolutely agree with this. References allow a receiving
function to better rely on the fact that the variable is supposed to be
backed by valid memory -- specifically it gives a syntactically sound
way of passing "pointers" that have better chances of being good at
compile time (its still possible to pass an array element that's beyond
the array's boundaries -- but at least you know you can't pass a
pointer to the heap that has been freed, or NULL, or just pure
garbage). As it is today, C programmers do this with raw pointers
which increases the potential danger by allowing for semantics that
usually are not intended.
Again, I agree. The lcc-win32 compiler implements them, and they do
improve program security.
[...] consts,
C has const. I don't quite see how C++'s consts are not redundant with
either #define or enums. You can even make enums locally scoped.
declaring variables just before use etc.
This is in C99, and personally I would rather have seen this *REMOVED*
from C++, than added to C. It makes the job of reading code twice as
hard -- if we wanted that, we might as well be using Perl. If you want
to do "just in time constructors", wrap your code with additional
scope.
I am asking this question with a vested interest. I would really
like to use these features in my C programs.
Use the lcc-win32 C compiler: http://www.cs.virginia.edu/~lcc-win32
Randy Howard wrote: In article <42***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says...
The lcc-win32 compiler adds some features of C++ like:
And using those features means you are writing in some other
language that is not C, call it "Navia" perhaps?
The C99 standard explicitly allows extensions, and those extensions have
been designed keeping compatible with the C99 standard.
There are NO NEW keywords. You can still say:
int operator = 45;
int operator(int g);
etc.
Each implementation of the C standard can extend the language
in the form prescribed by the standard, and *most* of them
do.
Your answer is typical for people that say that C should stay
at the level of assembly language and only C++ should have any
higher level constructs.
Operator overloading is a standard extension that is used in Fortran,
for instance, and in many other languages.
On 12 Feb 2005 19:13:45 -0800, we******@gmail.com
<we******@gmail.com> wrote: C has const. I don't quite see how C++'s consts are not redundant with
either #define or enums. You can even make enums locally scoped.
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. declaring variables just before use etc.
This is in C99, and personally I would rather have seen this *REMOVED*
from C++, than added to C. It makes the job of reading code twice as
hard -- if we wanted that, we might as well be using Perl. If you want
to do "just in time constructors", wrap your code with additional
scope.
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. I am asking this question with a vested interest. I would really
like to use these features in my C programs.
Personally, I think namespace should be added to that list. The single
shared global namespace situation that exists in C today is nothing
short of haphazard.
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". As well as getting rid of prefixes just
in case something else has a similarly names function.
Chris C
In article <42**********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr says... Randy Howard wrote:
In article <42***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says...
The lcc-win32 compiler adds some features of C++ like:
And using those features means you are writing in some other
language that is not C, call it "Navia" perhaps?
The C99 standard explicitly allows extensions, and those extensions have
been designed keeping compatible with the C99 standard.
And what happens when you want to port that source code to a platform
that doesn't have a compiler with your extensions?
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig
Chris Croughton wrote: On 12 Feb 2005 19:13:45 -0800, websnarf wrote: C has const. I don't quite see how C++'s consts are not redundant
with either #define or enums. You can even make enums locally
scoped.
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. declaring variables just before use etc.
This is in C99, and personally I would rather have seen this
*REMOVED* from C++, than added to C. It makes the job of reading
code twice as hard -- if we wanted that, we might as well be using
Perl. If you want to do "just in time constructors", wrap your
code with additional scope.
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. :)
---
Paul Hsieh http://www.pobox.com/~qed/ http://bstring.sf.net/
Randy Howard wrote: 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++.
In article <42***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr says... Randy Howard wrote:
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++.
So you assume that all platforms even have a C++ compiler? If so,
then why not just write in C++ to begin with?
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig
infobahn <in******@btinternet.com> writes: Keith Thompson wrote:
Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On 13 Feb 2005 03:50:04 -0800, we******@gmail.com
<we******@gmail.com> wrote: Chris Croughton wrote: On 12 Feb 2005 19:13:45 -0800, websnarf wrote: > C has const. I don't quite see how C++'s consts are not redundant
> with either #define or enums. You can even make enums locally
> scoped.
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.
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).
> > declaring variables just before use etc.
>
> This is in C99, and personally I would rather have seen this
> *REMOVED* from C++, than added to C. It makes the job of reading
> code twice as hard -- if we wanted that, we might as well be using
> Perl. If you want to do "just in time constructors", wrap your
> code with additional scope.
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.
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
Chris Croughton <ch***@keristor.net> writes: On 12 Feb 2005 19:13:45 -0800, we******@gmail.com
<we******@gmail.com> wrote:
[...] This is in C99, and personally I would rather have seen this *REMOVED*
from C++, than added to C. It makes the job of reading code twice as
hard -- if we wanted that, we might as well be using Perl. If you want
to do "just in time constructors", wrap your code with additional
scope.
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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
infobahn <in******@btinternet.com> writes: Keith Thompson wrote:
Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
How would you deal with resizing? old?
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" :-)
"infobahn" <in******@btinternet.com> wrote in message
news:42***************@btinternet.com... Keith Thompson wrote:
Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
How would you deal with resizing? old?
renew? :)
Serve Lau wrote:
"infobahn" <in******@btinternet.com> wrote in message
news:42***************@btinternet.com... Keith Thompson wrote:
Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
How would you deal with resizing? old?
renew? :)
Much better :-)
>>>Since C already has malloc() and free(), new and delete wouldn't add much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
How would you deal with resizing? old?
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 ;-)
Chris Croughton <ch***@keristor.net> wrote: On 12 Feb 2005 19:13:45 -0800, we******@gmail.com
<we******@gmail.com> wrote:
declaring variables just before use etc.
This is in C99, and personally I would rather have seen this *REMOVED*
from C++, than added to C. It makes the job of reading code twice as
hard -- if we wanted that, we might as well be using Perl. If you want
to do "just in time constructors", wrap your code with additional
scope.
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. I am asking this question with a vested interest. I would really
like to use these features in my C programs.
Personally, I think namespace should be added to that list. The single
shared global namespace situation that exists in C today is nothing
short of haphazard.
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
In article <42***********************@news.club-internet.fr>,
Guillaume <"grsNOSPAM at NOTTHATmail dot com"> wrote: Since C already has malloc() and free(), new and delete wouldn't add
much value, but if I were designing a C-like language from scratch I'd
probably use new and delete *instead of* malloc() and free().
How would you deal with resizing? old?
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).
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
--
Dave Vandervies dj******@csclub.uwaterloo.ca
It seems to me that a willingness to put up with stupid governments is
also a requirement. Why didn't you guys vote in the other guy instead?
Oh, sorry, you *did*, didn't you? --Richard Heathfield in comp.lang.c
Dave Vandervies wrote: 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.
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.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
CBFalconer wrote: 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.
Randy Howard wrote: In article <42***********************@news.wanadoo.fr>,
ja***@jacob.remcomp.fr says... Randy Howard wrote:
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++.
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
jacob navia wrote:
.... 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.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Masood wrote: 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.
"E. Robert Tisdale" wrote:
Masood wrote:
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.
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.**************@jpl.nasa.gov> writes:
[...] 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.
Wrong. That's not making C better, that's just programming in C++.
There are several newsgroups dedicated to that topic. This is not one
of them.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
infobahn wrote: 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.
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.
I want both.
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.
Name ten.
C programmers don't want C to evolve or grow.
You don't think C++ is an evolution of C?
C++ programmers want C++ to evolve and grow.
They aren't enthusiastic about the new features introduced in C99
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?
(Why did you email this to me as well as posting it?)
In article <42**************@jacob.remcomp.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote: Dave Vandervies wrote: 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);
What is a String?
It obviously needs to encapsulate the length prefix and the actual
string data.
It also needs to be recognizeable to the language as something that you
can overload operators on.
To do anything useful with it in C, as opposed to your not-quite-C,
you'd also need an easy way to convert between a string and your String.
That's starting to look, feel, and smell suspiciously like a class,
even if that's not what you call it.
A similar package could be developed (and it has been started) for
a general vector facility.
And how, exactly, do you propose to do that for every possible type,
including user-defined types, without something that looks, feels, and
smells suspiciously like a template, even if that's not what you call it?
If you want C++, you know where to find it.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Conclusion: each one is faster than the other.
--Chris Torek in comp.lang.c
"E. Robert Tisdale" wrote:
infobahn wrote:
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!
Naturally. Whilst I don't claim to be perfect, I am quite accustomed
to being correct. You should try it.
Every C program should also be a valid C++ program.
By the same reasoning, every C++ program should be a valid Python
program. Is there no beginning to your reasoning ability?
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.
I want both.
Fine. C is here. C++ is over there.
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.
Name ten.
A silly challenge, and I'd be silly to respond. Okay, so I'm silly.
Here are ten reasons that C continues to be important:
1) C's "absence of restrictions and its generality make it more
convenient and effective for many tasks than supposedly more
powerful languages".
2) "C is not tied to any particular hardware or system [...] and
it is easy to write programs that will run without change on
any machine that supports C".
3) "C has proven to be a pleasant, expressive, and versatile
language for a wide variety of programs."
4) "It is easy to learn".
5) It "wears well as one's experience with it grows."
6) "Since C is relatively small, it can be described in a small
space, and learned quickly. A programmer can reasonably expect
to know and indeed regularly use the entire language."
7) "C has proven to be an extremely effective and expressive
language for a wide variety of programming applications."
8) Many programming languages offer support for libraries with
C bindings, so it is possible to provide functionality for
users of all these languages in one fell swoop.
9) On some platforms, C is the *only* available HLL!
10) People think in different ways. Some people think in a way
that matches C++ very well. They will be happiest and most
productive when using C++. Some people think in a way that
matches Perl very well. They will be happiest and most
productive when using Perl. And some people think in a way
that matches C very well. They will be happiest and most
productive when programming in C.
The first seven reasons are in the canonical literature, so you
ought already to have been aware of them. The last reason is
sufficient on its own to justify the existence of *any*
programming language.
C programmers don't want C to evolve or grow.
You don't think C++ is an evolution of C?
C++ programmers want C++ to evolve and grow.
Why did you evade the question?
They aren't enthusiastic about the new features introduced in C99
Can't wait.
Why are you waiting then?
I'm not. I'm getting on with programming in C. When C99 becomes as
portable as C90, I'll switch over. In the meantime, I have better
things to do with my time than wait for something that's probably
never going to happen.
But C99 isn't portable; in fact, it's less portable than C++.
Really?
Yes.
Which of your target platforms
*cough* You /really/ don't understand the concept of portability, do
you?
doesn't have C99 support
for the features that Masood mentioned?
Well, he mentioned new, delete, and references, which are not
supported by C99 at all. As for the other things, they're not
sufficient on their own. As far as I'm aware, all the compilers
I have on the machine I'm currently using to compose this reply
support single-line comments. But if I put a single-line comment
in my code, it is no longer portable to implementations that
strictly enforce C90. So, until C99 in its entirety is widely
available, I shan't be using it.
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!
You mean you disagree with yourself? Somehow, that doesn't surprise me.
When have you every complained to a compiler developer
about missing C99 features?
No use complaining to one compiler developer. One C99 implementation
isn't anywhere near enough to persuade C90 developers to switch.
Dave Vandervies wrote: What is a String?
It obviously needs to encapsulate the length prefix and the actual
string data.
It also needs to be recognizeable to the language as something that you
can overload operators on.
To do anything useful with it in C, as opposed to your not-quite-C,
you'd also need an easy way to convert between a string and your String.
That's starting to look, feel, and smell suspiciously like a class,
even if that's not what you call it.
typedef struct _String {
size_t count;
char *content;
size_t capacity;
} String;
You can use the cast operator to convert a String to a zero
terminated string.
The difference between this and a class is that there is no
inheritance hierarchy.
You can use operator overloading with any user defined
type.
jacob navia <ja***@jacob.remcomp.fr> writes:
[...] typedef struct _String {
size_t count;
char *content;
size_t capacity;
} String;
You can use the cast operator to convert a String to a zero
terminated string.
Do you mean that the cast operator is overloaded to convert from a
String to a char*? Does it just return the value of the "content"
member, or does it do some additional memory management?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote: jacob navia <ja***@jacob.remcomp.fr> writes:
[...]
typedef struct _String {
size_t count;
char *content;
size_t capacity;
} String;
You can use the cast operator to convert a String to a zero
terminated string.
Do you mean that the cast operator is overloaded to convert from a
String to a char*? Does it just return the value of the "content"
member, or does it do some additional memory management?
No, it returns the zero terminated content.
This was a difficult design decision. Since the source is distributed
with the standard distribution of lcc-win32, this decision can be
modified by the user.
The rationale is that it would be difficult to free the allocated
space, and that intuitively, a cast allocating space is not
evident.
The user can modify this string, even if this is not recommended.
The string library provides Strcat, Strcmp, Strstr, etc. Changing
code to use this strings is quite easy.
In article <42**************@jacob.remcomp.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote: Dave Vandervies wrote: What is a String?
It obviously needs to encapsulate the length prefix and the actual
string data.
It also needs to be recognizeable to the language as something that you
can overload operators on.
To do anything useful with it in C, as opposed to your not-quite-C,
you'd also need an easy way to convert between a string and your String.
That's starting to look, feel, and smell suspiciously like a class,
even if that's not what you call it.
typedef struct _String {
size_t count;
char *content;
size_t capacity;
} String;
You can use the cast operator to convert a String to a zero
terminated string.
The difference between this and a class is that there is no
inheritance hierarchy.
You can use operator overloading with any user defined
type.
....and if you put function pointers in the struct, you can build an
inheritance hierarchy into it as well. Which moves it from "looks, feels,
and smells suspiciously like a class" up to "a class by any other name".
If you want C++, you know where to find it.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Unfortunately, this example won't compile or execute. But the problem
statement only asked that the program be written, not that it be correct,
so that's all right. --Eric Sosman in comp.lang.c
Dave Vandervies wrote:
...and if you put function pointers in the struct, you can build an
inheritance hierarchy into it as well. Which moves it from "looks, feels,
and smells suspiciously like a class" up to "a class by any other name".
If you want C++, you know where to find it.
1: You failed to answer to:
"The difference between this and a class is that there isn't
inheritance".
There isn't any constructors/destructors either.
2: You can do object oriented programming in C without any
operator overloading. You can build classes, etc. This has
been reported several times in this group. And so what?
Then C is C++ just because you program OO with it?
On Sun, 13 Feb 2005 10:05:03 +0100, jacob navia wrote: Randy Howard wrote:
In article <42***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says...
The lcc-win32 compiler adds some features of C++ like:
And using those features means you are writing in some other
language that is not C, call it "Navia" perhaps?
The C99 standard explicitly allows extensions, and those extensions have
been designed keeping compatible with the C99 standard.
The standard allows extensions in some areas, yes. However it does not
allow extensions to the language syntax. If the syntax of the code does
not meet that specified in the standard then a diagnostic is required.
There are NO NEW keywords. You can still say:
int operator = 45;
int operator(int g);
etc.
Each implementation of the C standard can extend the language
in the form prescribed by the standard, and *most* of them
do.
But the extensions you described are in violation of the standard. That
isn't necessarily a problem, you just have to accept that when you use
those extensions you are programming in a different language.
Your answer is typical for people that say that C should stay
at the level of assembly language and only C++ should have any
higher level constructs.
Many of the "features" of C++ complement the OO paradigm. If you don't
have that then they are less useful. That is not the same as not useful,
but it becomes lss clear whether the benefits outweigh the costs. For
example function overloading doesn't need OO to be useful. But to
implement it would require some mechanism like name mangling for
resolving external linking, which is likely to make it link
incompatible with existing compiled C code, just like native C++ linkage
is in practice.
Operator overloading is a standard extension that is used in Fortran,
for instance, and in many other languages.
C has operator overloading. User defined operator overloading is another
matter. And if it is so wonderful, why didn't Java adopt it? :-)
Lawrence
Lawrence Kirby wrote: On Sun, 13 Feb 2005 10:05:03 +0100, jacob navia wrote:
Randy Howard wrote:
In article <42***********************@news.wanadoo.fr>,
ja***@jacob.remcomp.frsays...
The lcc-win32 compiler adds some features of C++ like:
And using those features means you are writing in some other
language that is not C, call it "Navia" perhaps?
The C99 standard explicitly allows extensions, and those extensions have
been designed keeping compatible with the C99 standard.
The standard allows extensions in some areas, yes. However it does not
allow extensions to the language syntax. If the syntax of the code does
not meet that specified in the standard then a diagnostic is required.
There are NO NEW keywords. You can still say:
int operator = 45;
int operator(int g);
etc.
Each implementation of the C standard can extend the language
in the form prescribed by the standard, and *most* of them
do.
But the extensions you described are in violation of the standard. That
isn't necessarily a problem, you just have to accept that when you use
those extensions you are programming in a different language.
Any extensions change the syntax of the language:
int __declspec(dllexport) fn(int a);
__declspec(dllexport) can be either a function call or a macro
according to the syntax. It is neither. It is a Microsoft extension
to signal that this function should be in the exported functions
list of a dll.
Is it C?
Yes.
*Any* extension will change the syntax, that is obvious.
Your answer is typical for people that say that C should stay
at the level of assembly language and only C++ should have any
higher level constructs.
Many of the "features" of C++ complement the OO paradigm. If you don't
have that then they are less useful. That is not the same as not useful,
but it becomes lss clear whether the benefits outweigh the costs. For
example function overloading doesn't need OO to be useful. But to
implement it would require some mechanism like name mangling for
resolving external linking, which is likely to make it link
incompatible with existing compiled C code, just like native C++ linkage
is in practice.
The C standard prescribes function overloading:
The function "sqrt" will be actually:
csqrt for complex argument
sqrtl for long double argument
sqrt for double argument
sqrtf for float argument
This functions (called type-generic) are in fact overloaded functions.
I decided to make this feature available to all users instead of
being available only to language implementors.
Operator overloading is a standard extension that is used in Fortran,
for instance, and in many other languages.
C has operator overloading. User defined operator overloading is another
matter. And if it is so wonderful, why didn't Java adopt it? :-)
Java did not implement it, and there are several dozens packages that
try to fill this hole in the language:
Jfront: http://www.gginc.biz/jfront/index.html
Groovy: http://groovy.codehaus.org/index.html
Jpp: http://www.digiserve.com/nshaylor/jpp.html
JUMP: http://www.infa.abo.fi/~mbacklun/jump.htm
etc...
Now even Sun Microsystems is considering adding this feature to Java! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Masood |
last post by:
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...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
