A recent article on CNN described the problem that phone makers
are facing.
( http://www.cnn.com/2006/TECH/biztech....ap/index.html)
Most people are rejecting the new "supercharged"
cell phones because they just do not want to learn the
incredible complex menus and stuff that you need to use them.
The new phones are just too complicated to use.
The same thing is happening with programming languages too.
Extremey complicated languages like C++ are loosing ground to more
simpler languages. People get tired of trying to learn a
monster language where learning the language gets in the way
of the basic needs of the user. You use a language to do something,
and when you have to learn too much stuff or the learning curve
is too steep, a simpler language wins.
This means for C, that C (contrary to what many people think)
has a good opportunity to attract new users. Being a much
simpler language it is the language of choice when you want something
that works without a lot of effort.
This could explain why the download rate of the lcc-win32 compiler
that offers only C stays since several years high. In this month
we have a mean download rate of around 300-400 per day at one of
our sites, probably more at the main downloading site. 109  4390 
jacob navia posted: Extremey complicated languages like C++ are loosing ground to more
simpler languages.
I'd expect such an argument from a Java programmer, or a C# programmer,
but it doesn't make much sense coming from a C programmer. A lot of C
programs can be simplified by injecting some C++ into them. Just look at
"string" and "vector".
I'm a C++ programmer. I know it inside out. I can make it do what I want
it to do. I made the choice to learn more "fancy" features, and it has
paid off.
The reason why C++ has waned in popularity is because way way WAY more
people are trying to program now than a few years ago. Intelligent and
intellectual people are in the minority, and therefore dumbed-down
languages like Java, Visual Basic and C# have seen a growth in
popularity.
Make a distinction between "mickey-mouse programmer" and "real
programmer" and then you'll see a meaningful trend.
I see C++ as a superset of C. Why would I restrict myself to only using C
feaures?
It's very well known that C compilers are far more common than C++
compilers, so it's much easier to find a C compiler for a given platform
than a C++ compiler. If I can't find a decent C++ compiler for a
platform, then I'll write C. Otherwise, I'll write C++.
-Tomás
jacob navia wrote: This means for C, that C (contrary to what many people think)
has a good opportunity to attract new users. Being a much
simpler language it is the language of choice when you want something
that works without a lot of effort.
I never had any doubts that C *is* attracting new users and will
continue to do so.
I go to linuxforums and everytime some newbie asks what programming
language
to start with a lot of people suggest C. Same thing happened on a
non-computer
related message board.
People like C for many reasons one of which is that they enjoy
programming "close
to the metal" even if it's not required by the application. The only
way I see C disappearing
is that a drastic change in computer hardware happens. sp****@gmail.com said: The only way I see C disappearing
is that a drastic change in computer hardware happens.
The C language, being so amenable to portable programming, is well-placed to
meet the challenge of such a change.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
jacob navia <ja***@jacob.remcomp.fr> writes:
[snip] This means for C, that C (contrary to what many people think)
has a good opportunity to attract new users. Being a much
simpler language it is the language of choice when you want something
that works without a lot of effort.
I wouldn't call C "simple". A simple language wouldn't require so
much care and expertise to avoid serious pitfalls such as the many
cases of undefined behavior.
Your "contrary to what many people think" remark seems to be typical
of your peristent misunderstanding of the opinions of most other
people in this newsgroup.
This could explain why the download rate of the lcc-win32 compiler
that offers only C stays since several years high. In this month
we have a mean download rate of around 300-400 per day at one of
our sites, probably more at the main downloading site.
lcc-win32 does not offer "only C". It apparently does support
standard C (I don't know how well), but it also supports some other
language consisting of C with a number of extensions. There might be
some interesting point to make about the popularity of your extended C
language vs. another extended C language called "C++", but this
wouldn't be the place to make that point.
--
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.
Tomás wrote: jacob navia posted:
Extremey complicated languages like C++ are loosing ground to more
simpler languages.
I'd expect such an argument from a Java programmer, or a C# programmer,
but it doesn't make much sense coming from a C programmer. A lot of C
programs can be simplified by injecting some C++ into them. Just look at
"string" and "vector".
I'm a C++ programmer. I know it inside out. I can make it do what I want
it to do. I made the choice to learn more "fancy" features, and it has
paid off.
The reason why C++ has waned in popularity is because way way WAY more
people are trying to program now than a few years ago. Intelligent and
intellectual people are in the minority, and therefore dumbed-down
languages like Java, Visual Basic and C# have seen a growth in
popularity.
Perhaps, though Java may also be successful because it is less a
language than a development and deployment framework. This makes it
possible for a company like mine to support such a wide variety of
platforms.
C++ (or C, for that matter) does not have to preclude easy porting to
new platforms, but it sure is easy for a code base to become less and
less portable over time. Even adding another Unix platform was more
than a modest undertaking, and was actually a "port". Now we make sure
the small amount of JNI and native code we have builds, and the
classfiles that make up the bulk of the world go right to QA. A
developer does a "port" simply by being a tech lead for QA if anything
comes up. It rarely does. So, a "port" is often hours and days now,
instead of weeks or months.
We sort of were bitten by C++ during the transition stage when the
language was still being standardized. All those different compilers
(this was before GCC was available/reasonable on all the platforms we
needed) on all those different platforms was a real pain to maintain.
Condition compilation ruled the day, and it was not fun. To this day I
still have nightmares about all the contortions necessary to get STL
based code to build cleanly on different Unix platforms.
There may be issues between platform VMs of the same version, but this
is pretty rare. By and large maintenance has been much easier with Java.
All these issues are in many senses removed from the language itself.
The large apps I work on now are best treated as a collection of
middleware and frameworks than source code half the time (though we
write plenty of code).
Make a distinction between "mickey-mouse programmer" and "real
programmer" and then you'll see a meaningful trend.
I thought real programmers programmed in hex, on a seven-segment readout
with a keypad?
Tomás wrote: The reason why C++ has waned in popularity is because way way WAY more
people are trying to program now than a few years ago. Intelligent and
intellectual people are in the minority, and therefore dumbed-down
languages like Java, Visual Basic and C# have seen a growth in
popularity.
Make a distinction between "mickey-mouse programmer" and "real
programmer" and then you'll see a meaningful trend.
Look Tomas,
you should restrain from insulting other people just because they refuse
to learn all the complexities of C++.
No. They aren't "mickey-mouse" programmers but real programmers that
want to use a programming language to do a specific JOB. Period.
If you read the article that I quoted in CNN, people do not reject the
"modern" hypercomplex phones just because they are lazy but because they
want to USE a phone for what is intended: communicate by phone with
other people. PERIOD.
C++, because of the very high learning curve, stays in the way of people
doing the JOB they want to do with the language.
C has less surprises, less to learn, and uses FAR LESS MEMORY.
Not only RAM, that nobody cares too much, but HUMAN MEMORY, a far more
precious resource than RAM!
The memory footprint of a language is the amount of data your brain
must load into your neural network to be able to use that language
efficiently.
The memory footprint of C++ is enormous. C++ specifications run down for
pages and pages, and basically, it is impossible for a human mind
to follow the complexities of name resolution without using the
debugger. The C++ name resolution for overloaded operators runs for
several pages of specifications and imply a topological sort of the
class hierarchy. Which human mind can do that without having a machine
(compiler) at hand?
People that reject a language where they can't possibly know what
are they calling, aren't stupid. The contrary is true. They just
follow the KISS principle!
KEEP IT SIMPLE!
jacob
jacob
Keith Thompson a écrit : jacob navia <ja***@jacob.remcomp.fr> writes:
[snip]
This means for C, that C (contrary to what many people think)
has a good opportunity to attract new users. Being a much
simpler language it is the language of choice when you want something
that works without a lot of effort.
I wouldn't call C "simple". A simple language wouldn't require so
much care and expertise to avoid serious pitfalls such as the many
cases of undefined behavior.
*Any* language has its "gotchas"... C's aren't specially difficult
to see with a little bit of care. Granted, it is a language
that is close to the machine, and supposes more care when
programming than Java or C#.
Your "contrary to what many people think" remark seems to be typical
of your peristent misunderstanding of the opinions of most other
people in this newsgroup.
I do not see why you feel that this was directed against people
in this group...
:-)
I was speaking against many people that see C as a dead language
or kind of low level assembler that doesn't even earn the
name "high level language". For instance, just read
Betrand Meyer and ist Object Oriented Software construction book.
This could explain why the download rate of the lcc-win32 compiler
that offers only C stays since several years high. In this month
we have a mean download rate of around 300-400 per day at one of
our sites, probably more at the main downloading site.
lcc-win32 does not offer "only C". It apparently does support
standard C (I don't know how well), but it also supports some other
language consisting of C with a number of extensions. There might be
some interesting point to make about the popularity of your extended C
language vs. another extended C language called "C++", but this
wouldn't be the place to make that point.
Maybe, but most people are attracted by the easy of use. I do
not think people are attracted just by the language extensions. You see,
the compiler is very simple, the IDE also, to make a project you select
a bunch of files in the IDE and that is it.
EASY OF USE. This is a fundamental point that we forget too often when
adding that gazillon options...
I have resisted to make the IDE more complicated. It
has a user interface unchanged since windows 3.1.
Like the language it supports, everything is small, straightforward.
You do not have a XXX "Studio", the IDE is just 800K, complete with
spelling checker, software metrics, and many other options that
"advanced" IDEs do not offer.
Simple but powerful, as the language it supports.
jacob navia wrote: A recent article on CNN described the problem that phone makers
are facing.
(http://www.cnn.com/2006/TECH/biztech....ap/index.html)
Most people are rejecting the new "supercharged"
cell phones because they just do not want to learn the
incredible complex menus and stuff that you need to use them.
The new phones are just too complicated to use.
The same thing is happening with programming languages too.
Extremey complicated languages like C++ are loosing ground to more
simpler languages. People get tired of trying to learn a
monster language where learning the language gets in the way
of the basic needs of the user. You use a language to do something,
and when you have to learn too much stuff or the learning curve
is too steep, a simpler language wins.
If you try to program advanced software in C, you'll see that the
complexity which is not in the C language, will be found in the C code.
At a higher maintainibility cost than if it was programmed in a
language supporting advanced features.
In fact, learning C or C++ depends on what you want to do.
If you want to write device drivers, you'll see that most features of
C++ are not really possible to use. You can still write the program in
C++, but you will write it in a C-style way.
So, if you only want to write device drivers, you don't have to learn
C++. You can learn C only.
But if you want to write applications which require runtime
polymorphism, or benefit from generic containers, or simply need to use
a lot of object-based libraries (such as bignums libraries) or expose a
lot of objects (not necessarily with inheritance), or even simply uses
so much dynamic allocation that RAII + exceptions is absolutely
necessary for a correct program (I mean a program which doesn't crash
even if any constructor fails), then C++ is much safer, and easier to
write.
Try to write OOP with GObject in C, and you'll see that C++ would be
better for that task.
This means for C, that C (contrary to what many people think)
has a good opportunity to attract new users. Being a much
simpler language it is the language of choice when you want something
that works without a lot of effort.
Yes, simplicity attracts people.
As far as people use only simple things, they are happy, and there have
no reason of learning a complex language.
But when they write complex things, they realize that a complex
language in fact helps a lot, and simplifies their program.
wrote jacob navia: The memory footprint of C++ is enormous. C++ specifications run down for
pages and pages, and basically, it is impossible for a human mind
to follow the complexities of name resolution without using the
debugger.
Perhaps your mind.
But my mind knows pretty well the C++ standard.
And, if you read the C99 standard, you'll see that C is not so simple
that it seems to be (even if it is simplier than C++).
For instance, there are common pitfalls, if you think that C is too
close to the machine.
You have to learn the C standard if you want to write portable
software, otherwise you may use casts in a non-portable way... Read the
C standard, and you'll see that there are lots of undefined behaviors
which seems to work perfectly fine on common platforms (x86, PowerPC),
but might fail on weird platforms.
"Richard Heathfield" <in*****@invalid.invalid> wrote sp****@gmail.com said:
The only way I see C disappearing
is that a drastic change in computer hardware happens.
The C language, being so amenable to portable programming, is well-placed
to
meet the challenge of such a change.
The C language is, the C standard isn't.
For instance say I have invented a very cheap analogue memory. It will store
256 levels of resolution with enough accuracy to make it acceptable for
everyday data, but there is just a slight chance of a shift from one level
to another.
But we can get round this with a bit of AI. If a word reads "exactky" the AI
will correct it to "exactly". Or buy "1* eggs" becomes "buy 12 eggs",
because of course I am not stupid enough to use an encoding where digits are
contiguous and "buy 12 eggs" could slip undetectable to "buy 11 eggs".
Oh whoops. there goes the standard.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
"Malcolm" <re*******@btinternet.com> writes: "Richard Heathfield" <in*****@invalid.invalid> wrote sp****@gmail.com said: The only way I see C disappearing
is that a drastic change in computer hardware happens.
The C language, being so amenable to portable programming, is well-placed
to
meet the challenge of such a change.
The C language is, the C standard isn't.
For instance say I have invented a very cheap analogue memory. It will store
256 levels of resolution with enough accuracy to make it acceptable for
everyday data, but there is just a slight chance of a shift from one level
to another.
But we can get round this with a bit of AI. If a word reads "exactky" the AI
will correct it to "exactly". Or buy "1* eggs" becomes "buy 12 eggs",
because of course I am not stupid enough to use an encoding where digits are
contiguous and "buy 12 eggs" could slip undetectable to "buy 11 eggs".
Oh whoops. there goes the standard.
And if I'm storing arbitrary data, perhaps even a stream of random
numbers, there's no way any kind of AI can "guess" that the byte with
a value of 138 is really supposed to be 137. For that matter, eggs
commonly come in packages of 18; how is this AI of yours supposed to
know whether I meant 12 or 18?
I'm sure there are hypothetical architectures that are (a) useful, and
(b) impractical for a conforming C implementation. I don't think
you've come up with such an example. (Trinary arithmetic springs to
mind.)
--
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.
jacob navia wrote: C++, because of the very high learning curve, stays in the way of people
doing the JOB they want to do with the language.
Nonsense. You can start writing C++ simply by compiling your C with a
C++ compiler and then start using extra language features as you need or
require them. I bit of incremental learning never did anyone any harm.
I often develop embedded C with a C++ host compiler, just to take
advantage of the stronger type checking in C++ and C++ unit test
frameworks, another good way to learn new tricks.
--
Ian Collins.
jacob navia posted: Look Tomas,
you should restrain from insulting other people just because they refuse
to learn all the complexities of C++.
I insult people's stupidity, nothing more.
No. They aren't "mickey-mouse" programmers but real programmers that
want to use a programming language to do a specific JOB. Period.
Learning a programming language isn't about "one specific job". If it was,
I'd have learned several hundred programming languages by now.
If you read the article that I quoted in CNN, people do not reject the
"modern" hypercomplex phones just because they are lazy but because they
want to USE a phone for what is intended: communicate by phone with
other people. PERIOD.
I too like simple gadgets.
A computer programming language isn't a gadget, it's a tool. Draw the
distinction.
C++, because of the very high learning curve, stays in the way of people
doing the JOB they want to do with the language.
They're either learning C++ the wrong way, or they're incredibly stupid.
I was writing brilliant C++ programs by the time I was fifteen... surely it
can't be *that* complicated.
C has less surprises, less to learn, and uses FAR LESS MEMORY.
Explain to me how a programming language can use far less more memory?
You'd be correct in thinking that some C++ features introduce overhead
(e.g. virtual functions) -- however, any such overhead is pay as you go.
I can copy-paste your C code and compile it as C++. If my version is any
slower or uses less memory, I'll eat my hat.
Not only RAM, that nobody cares too much, but HUMAN MEMORY, a far more
precious resource than RAM!
You speak English. How many english words are there in your head? Take a
guess. The answer is far more than you imagine.
Computer programming languages aren't about memory games, they're about
being experienced with particular features and functionality.
Not once have I sat and scratched my head and thought "What's a virtual
function again?".
If memory is such a problem for you, start taking fish oils.
The memory footprint of a language is the amount of data your brain
must load into your neural network to be able to use that language
efficiently.
And it is absolutely NOTHING compared to the amount of "data" stored in my
brain for speaking English, Irish, French and German.
Again, your argument is based on the alleged inherent incompetence that
programmers possess.
The memory footprint of C++ is enormous.
For a badger, maybe.
C++ specifications run down for
pages and pages, and basically, it is impossible for a human mind
to follow the complexities of name resolution without using the
debugger.
Oh my God I must be a genius... put me in the Guinness book of records! I
wonder how many more geniuses there are on comp.lang.c++?
The C++ name resolution for overloaded operators runs for
several pages of specifications and imply a topological sort of the
class hierarchy.
That's why you get the hang of it and it becomes second nature. When I'm
speaking English, I don't stop and think "Is it 'you are' or 'you is'?".
When I'm driving, I don't stop and think "Do I press in the clutch, and
them move the gear stick, or... do I move the gear stick and then press in
the clutch?". When I'm reaching to get a cup out of the cupboard, I don't
stop and think "Should I flex my biscep or my tricep?".
Which human mind can do that without having a machine
(compiler) at hand?
Far greater feats have been achieved with the human mind. Ever hear of
those people who go to Vegas and count cards? I claim to be an expert C++
programmer, yet I bow to such advanced mental capabilities.
People that reject a language where they can't possibly know what
are they calling, aren't stupid.
I'll use the word "novice" if you'd prefer.
The contrary is true. They just
follow the KISS principle!
KEEP IT SIMPLE!
Yes, I too am an advocate of "keep it simple". However, I draw the line at
"dumb it down".
-Tomás
Ian Collins <ia******@hotmail.com> writes: jacob navia wrote:
C++, because of the very high learning curve, stays in the way of people
doing the JOB they want to do with the language.
Nonsense. You can start writing C++ simply by compiling your C with a
C++ compiler and then start using extra language features as you need or
require them. I bit of incremental learning never did anyone any harm.
Almost. There are valid C programs that are not valid C++ programs.
There are even a few things that are valid in both C and C++, but with
different semantics (though most of those things are probably best
avoided in either language). And there are constructs that are valid
in both languages, but poor style in either. For example this:
some_type *ptr = (some_type*)malloc(sizeof *ptr);
is legal in both C and C++. In C, the cast should be omitted. In
C++, you should probably use "new" or some STL thingie rather than
malloc.
Starting with a C-like subset of C++ may be a good way to learn C++,
but it's important to remember that C++ is *not* a strict superset of
C.
--
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: Ian Collins <ia******@hotmail.com> writes:
jacob navia wrote:
C++, because of the very high learning curve, stays in the way of people
doing the JOB they want to do with the language.
Nonsense. You can start writing C++ simply by compiling your C with a
C++ compiler and then start using extra language features as you need or
require them. I bit of incremental learning never did anyone any harm.
Almost. There are valid C programs that are not valid C++ programs.
There are even a few things that are valid in both C and C++, but with
different semantics (though most of those things are probably best
avoided in either language). And there are constructs that are valid
in both languages, but poor style in either. For example this:
some_type *ptr = (some_type*)malloc(sizeof *ptr);
is legal in both C and C++. In C, the cast should be omitted. In
C++, you should probably use "new" or some STL thingie rather than
malloc.
True, but the cast doesn't do any harm.
With care, you can use a C++ compiler as a lazy man's lint during code
development.
Starting with a C-like subset of C++ may be a good way to learn C++,
but it's important to remember that C++ is *not* a strict superset of
C.
True, but you can use the true intersection between the two languages
most of the time.
--
Ian Collins.
"Tomás" <No.Email@Address> writes:
[...] I can copy-paste your C code and compile it as C++. If my version is any
slower or uses less memory, I'll eat my hat.
int main(void)
{
int new;
return 0;
}
--
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.
Ian Collins <ia******@hotmail.com> writes: Keith Thompson wrote:
[...] Almost. There are valid C programs that are not valid C++ programs.
There are even a few things that are valid in both C and C++, but with
different semantics (though most of those things are probably best
avoided in either language). And there are constructs that are valid
in both languages, but poor style in either. For example this:
some_type *ptr = (some_type*)malloc(sizeof *ptr);
is legal in both C and C++. In C, the cast should be omitted. In
C++, you should probably use "new" or some STL thingie rather than
malloc.
True, but the cast doesn't do any harm.
Sure it does. It needlessly clutters the code. It tends to encourage
the use of casts in general, which can be very dangerous. It can mask
the failure to include <stdlib.h>. If you change the type of ptr, you
have to change the type in the cast.
With care, you can use a C++ compiler as a lazy man's lint during code
development.
With care, you can use a good C compiler ofr the same purpose.
Or you can use lint. Starting with a C-like subset of C++ may be a good way to learn C++,
but it's important to remember that C++ is *not* a strict superset of
C.
True, but you can use the true intersection between the two languages
most of the time.
True, but I for one don't want to. If I'm going to program in C, I'll
use a C compiler.
--
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 said: "Tomás" <No.Email@Address> writes:
[...] I can copy-paste your C code and compile it as C++. If my version is any
slower or uses less memory, I'll eat my hat.
int main(void)
{
int new;
return 0;
}
This is not (merely) an academic objection. The first C program I ever tried
to port to C++ used new as an object name and delete as a function name.
These were not inserted deliberately into the C code to forestall
translation by a C++ compiler, for I had never heard of C++ at the time I
wrote the code. Changing new was easy enough, but delete was a bit of a
nuisance, since it was called in quite a few places.
Nowadays, I routinely use constructs such as:
foo *foo_create(int bar)
{
foo *new = malloc(sizeof *new);
if(new != NULL)
{
new->bar = bar;
}
return new;
}
specifically to remind me, should I ever try to use a C++ compiler on the
code, that I'm making a big mistake.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
In article <4u********************@bt.com>,
Malcolm <re*******@btinternet.com> wrote: "Richard Heathfield" <in*****@invalid.invalid> wrote sp****@gmail.com said:
The only way I see C disappearing
is that a drastic change in computer hardware happens.
For instance say I have invented a very cheap analogue memory. It will store
256 levels of resolution with enough accuracy to make it acceptable for
everyday data, but there is just a slight chance of a shift from one level
to another.
But we can get round this with a bit of AI.
If it's "very cheap" then it is cheap enough to use some of the
memory as ECC with single bit error correction and double-bit detection.
If the probability of a bit slip is still high enough to warrant
software thought, then just use more of the "very cheap" memory
to extend the correction capabilities, such as by using
"constellation codes".
(note: for such codes, the bit representation stored is usually not
just a superset of the original bits -- not "the original bits together
with some extra bits", but rather "an arithmetic function of the
original bits".)
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
Keith Thompson wrote: Ian Collins <ia******@hotmail.com> writes:
Keith Thompson wrote:
[...]
Almost. There are valid C programs that are not valid C++ programs.
There are even a few things that are valid in both C and C++, but with
different semantics (though most of those things are probably best
avoided in either language). And there are constructs that are valid
in both languages, but poor style in either. For example this:
some_type *ptr = (some_type*)malloc(sizeof *ptr);
is legal in both C and C++. In C, the cast should be omitted. In
C++, you should probably use "new" or some STL thingie rather than
malloc.
True, but the cast doesn't do any harm.
Sure it does. It needlessly clutters the code. It tends to encourage
the use of casts in general, which can be very dangerous. It can mask
the failure to include <stdlib.h>. If you change the type of ptr, you
have to change the type in the cast.
True it does clutter, but if you are using a C++ compiler, it won't mask
missing includes.
I've used a macro for casts that uses static_cast in C++, which is a
good way of exposing "suspect" casts.
With care, you can use a C++ compiler as a lazy man's lint during code
development.
With care, you can use a good C compiler ofr the same purpose.
Or you can use lint.
I tend to use enums as function parameters, lint doesn't flag 'improper'
assignment to an enum, as they are legal in C. Just my style.
Starting with a C-like subset of C++ may be a good way to learn C++,
but it's important to remember that C++ is *not* a strict superset of
C.
True, but you can use the true intersection between the two languages
most of the time.
True, but I for one don't want to. If I'm going to program in C, I'll
use a C compiler.
You don't have to, I'm just saying you can if you choose.
--
Ian Collins.
Keith Thompson posted: "Tomás" <No.Email@Address> writes:
[...] I can copy-paste your C code and compile it as C++. If my version is
any slower or uses less memory, I'll eat my hat.
int main(void)
{
int new;
return 0;
}
Smart. If pedantry is what you're after, then:
If I copy-paste your C code, and then go through it for:
(a) Use of C++ keywords
(b) Inconsistencies between C and C++
And then compile it, I guarantee that the C++ version won't be slower or
require more memory.
-Tomás
Richard Heathfield posted: foo *foo_create(int bar)
{
foo *new = malloc(sizeof *new);
if(new != NULL)
{
new->bar = bar;
}
return new;
}
specifically to remind me, should I ever try to use a C++ compiler on
the code, that I'm making a big mistake.
A facility as simple as "find and replace" solves the keyword problem.
-Tomás
"Tomás" <No.Email@Address> writes: Keith Thompson posted: "Tomás" <No.Email@Address> writes:
[...] I can copy-paste your C code and compile it as C++. If my version is
any slower or uses less memory, I'll eat my hat.
int main(void)
{
int new;
return 0;
}
Smart. If pedantry is what you're after, then:
If I copy-paste your C code, and then go through it for:
(a) Use of C++ keywords
(b) Inconsistencies between C and C++
And then compile it, I guarantee that the C++ version won't be slower or
require more memory.
I agree that it's very likely, but I don't see how you can guarantee
it without a lot more caveats.
If I run the program on a faster computer than you do, mine will
probably be faster than yours. If I use a better compiler than you
do, mine will likely be faster than yours. Many compiler suites that
include C and C++ compilers use different frontends for the two
languages; the C frontend might happen to generate better code than
the C++ frontend.
All else being equal, there's no reason I know of to assume that a
program written in the common subset of C and C++ will be more
efficient when compiled as C than when compiled as C++ (or vice
versa). I'm not confident enough of that to offer to consume any
headgear.
--
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.
Tomás said: Richard Heathfield posted:
foo *foo_create(int bar)
{
foo *new = malloc(sizeof *new);
if(new != NULL)
{
new->bar = bar;
}
return new;
}
specifically to remind me, should I ever try to use a C++ compiler on
the code, that I'm making a big mistake.
A facility as simple as "find and replace" solves the keyword problem.
Yes, but the problem with simple solutions is that they are sometimes too
simple. For example, s/new/newobject/g is a simple fix, but quite likely to
result in tears.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
"SuperKoko" <ta*******@yahoo.fr> writes: Try to write OOP with GObject in C, and you'll see that C++ would be
better for that task.
Well and much better would be using Objective-C...
Yes, simplicity attracts people.
As far as people use only simple things, they are happy, and there have
no reason of learning a complex language.
But when they write complex things, they realize that a complex
language in fact helps a lot, and simplifies their program.
The complex language must not be C++. And one can have a lot of the
"nice stuff" in other language far better packaged.
And, if you read the C99 standard, you'll see that C is not so simple
that it seems to be (even if it is simplier than C++).
That's too true unfortuntatly.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
"Tomas" <No.Email@Address> writes: Richard Heathfield posted:
foo *foo_create(int bar)
{
foo *new = malloc(sizeof *new);
if(new != NULL)
{
new->bar = bar;
}
return new;
}
specifically to remind me, should I ever try to use a C++ compiler on
the code, that I'm making a big mistake.
A facility as simple as "find and replace" solves the keyword problem.
Yes, and at the same time it screws up all the comments that use
"new" as an English word.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Tomás said: If I copy-paste your C code, and then go through it for:
(a) Use of C++ keywords
(b) Inconsistencies between C and C++
And then compile it, I guarantee that the C++ version won't be slower or
require more memory.
But the C++ version may well be a very different program as a result of your
changes, so the comparison will no longer be valid.
But if you want to give it a go, please feel free. In fact, if you like, I
won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe the following rules:
1) the program must remain a valid C program.
2) you may refactor recursive main() - so I
didn't bother to use one.
3) you may rename identifiers, including function
names.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
#define SPACE ' '
int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const char *b[28] = {0};
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
auto i = strlen(protected) -
(sizeof SPACE //* we need a space\
in here somewhere */ sizeof (int
) + strlen(asm) + strlen(using));
if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
{
puts("Error!");
return EXIT_FAILURE;
}
b[0] = asm + 1;
b[1] = b[0] - 1;
b[2] = protected + 8;
b[4] = b[2] - 8;
b[5] = b[4] + 1;
b[6] = b[5] + 1;
b[7] = using + 4;
b[8] = b[5];
b[9] = b[0] - 1;
b[10] = b[0] + 1;
b[11] = b[10];
b[12] = b[2] - 4;
b[13] = b[12] - 3;
b[14] = b[0];
b[16] = b[2];
b[17] = b[16] - 6;
b[19] = b[7] - 1;
b[20] = b[2] - 6;
b[21] = b[20] + 1;
b[23] = b[7] - 4;
b[24] = b[23] + 1;
b[25] = b[2] - 4;
b[27] = b[25] + 1;
printf("%.*s\n",
(int)sizeof title__of__the__program,
title__of__the__program);
while(i < sizeof b / sizeof b[0])
{
if(b[i] != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}
putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');
return 0;
}
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Ben Pfaff wrote: "Tomas" <No.Email@Address> writes:
Richard Heathfield posted:
foo *foo_create(int bar)
{
foo *new = malloc(sizeof *new);
if(new != NULL)
{
new->bar = bar;
}
return new;
}
specifically to remind me, should I ever try to use a C++ compiler on
the code, that I'm making a big mistake.
A facility as simple as "find and replace" solves the keyword problem.
Yes, and at the same time it screws up all the comments that use
"new" as an English word.
Or even worse messages that are output to the user.
Please enter then newobject price:
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro: http://clc-wiki.net/wiki/Intro_to_clc
Richard Heathfield wrote: Tomás said:
If I copy-paste your C code, and then go through it for:
(a) Use of C++ keywords
(b) Inconsistencies between C and C++
And then compile it, I guarantee that the C++ version won't be slower or
require more memory.
But the C++ version may well be a very different program as a result of your
changes, so the comparison will no longer be valid.
But if you want to give it a go, please feel free. In fact, if you like, I
won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe the following rules:
1) the program must remain a valid C program.
2) you may refactor recursive main() - so I
didn't bother to use one.
3) you may rename identifiers, including function
names.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
#define SPACE ' '
int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const char *b[28] = {0};
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
auto i = strlen(protected) -
(sizeof SPACE //* we need a space\
in here somewhere */ sizeof (int
) + strlen(asm) + strlen(using));
if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
{
puts("Error!");
return EXIT_FAILURE;
}
b[0] = asm + 1;
b[1] = b[0] - 1;
b[2] = protected + 8;
b[4] = b[2] - 8;
b[5] = b[4] + 1;
b[6] = b[5] + 1;
b[7] = using + 4;
b[8] = b[5];
b[9] = b[0] - 1;
b[10] = b[0] + 1;
b[11] = b[10];
b[12] = b[2] - 4;
b[13] = b[12] - 3;
b[14] = b[0];
b[16] = b[2];
b[17] = b[16] - 6;
b[19] = b[7] - 1;
b[20] = b[2] - 6;
b[21] = b[20] + 1;
b[23] = b[7] - 4;
b[24] = b[23] + 1;
b[25] = b[2] - 4;
b[27] = b[25] + 1;
printf("%.*s\n",
(int)sizeof title__of__the__program,
title__of__the__program);
while(i < sizeof b / sizeof b[0])
{
if(b[i] != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}
putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');
return 0;
}
c.c: In function ‘main’:
c.c:17: error: type defaults to ‘int’ in declaration of ‘i’
c.c:20: error: expected ‘,’ or ‘;’ before‘)’ token
c.c:64: error: implicit declaration of function ‘toupper’
c.c:69: error: implicit declaration of function ‘tolower’
That's compiling as C, not as C++.
The notion that C++ is "better" than C because it is (almost) a
superset,
is a very bad notion and should be stamped out. (C++ of course is not
an exact superset anyway, but that dead horse is already being beaten
to death again in another subthread.)
Dennis Ritchie's famous comments on adding new keywords to C may shed
some light on why adding features to a language is not an unmixed
blessing: This is an essay on why I do not like X3J11 type qualifiers....
Let me begin by saying that I'm not convinced that even the pre-December
qualifiers (`const' and `volatile') carry their weight; I suspect that what
they add to the cost of learning and using the language is not repaid in
greater expressiveness.
... Nevertheless, I don't argue for the extirpation of qualifiers, if only because
it is too late.
For those who want to read the entire essay, Google search for its most
famous line: Noalias must go. This is non-negotiable.
If supersets are so good, why didn't PL/1 catch on? It was sort of
a superset of Fortran, Cobol and some Algol.
Frankly, I find it much more fun to program in a simple language!
(And a happy programmer is a productive programmer!)
jacob navia wrote: Tomás wrote: The reason why C++ has waned in popularity is because ...
intellectual people are in the minority, and therefore dumbed-down
languages like Java, Visual Basic and C# have seen a growth in
popularity.
Look Tomas,
you should restrain from insulting other people just because they refuse
to learn all the complexities of C++.
No, we should all be grateful that such an awesome genius condescends
to spend time in this newsgroup, of the Language for Dummies. :-)
C has less surprises, less to learn, and uses FAR LESS MEMORY.
... HUMAN MEMORY, a far more precious resource than RAM!
Transparency is what I like! We know exactly what malloc() and free()
do, but may have to study an inheritance maze to guess about
new and delete. Implicit deletes horrify me; I'd probably add
unnecessary
explicit delete's just to call attention!
I have tried to get into the C++ spirit. Once I read a magazine
article about
a general purpose delete routine. If an object contains a pointer to
another object do you delete that object also? To me, this is
obviously
a decision to be made by the programmer on the spot, but the writer
seemed to feel programmers should call his general-purpose routine
that made the decision with a crude heuristic! (IIRC, he deletes it
iff
it isn't null or a self-pointer.)
People that reject a language where they can't possibly know what
are they calling, aren't stupid. The contrary is true. They just
follow the KISS principle!
KEEP IT SIMPLE!
jacob
Glad to hear from someone who agrees with me!
James
Harald van Dijk wrote: Richard Heathfield wrote:
Tomás said:
If I copy-paste your C code, and then go through it for:
(a) Use of C++ keywords
(b) Inconsistencies between C and C++
And then compile it, I guarantee that the C++ version won't be slower or
require more memory.
But the C++ version may well be a very different program as a result of your
changes, so the comparison will no longer be valid.
But if you want to give it a go, please feel free. In fact, if you like, I
won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe the following rules:
1) the program must remain a valid C program.
2) you may refactor recursive main() - so I
didn't bother to use one.
3) you may rename identifiers, including function
names.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
#define SPACE ' '
int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const char *b[28] = {0};
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
auto i = strlen(protected) -
(sizeof SPACE //* we need a space\
in here somewhere */ sizeof (int
) + strlen(asm) + strlen(using));
if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
{
puts("Error!");
return EXIT_FAILURE;
}
b[0] = asm + 1;
b[1] = b[0] - 1;
b[2] = protected + 8;
b[4] = b[2] - 8;
b[5] = b[4] + 1;
b[6] = b[5] + 1;
b[7] = using + 4;
b[8] = b[5];
b[9] = b[0] - 1;
b[10] = b[0] + 1;
b[11] = b[10];
b[12] = b[2] - 4;
b[13] = b[12] - 3;
b[14] = b[0];
b[16] = b[2];
b[17] = b[16] - 6;
b[19] = b[7] - 1;
b[20] = b[2] - 6;
b[21] = b[20] + 1;
b[23] = b[7] - 4;
b[24] = b[23] + 1;
b[25] = b[2] - 4;
b[27] = b[25] + 1;
printf("%.*s\n",
(int)sizeof title__of__the__program,
title__of__the__program);
while(i < sizeof b / sizeof b[0])
{
if(b[i] != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}
putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');
return 0;
}
c.c: In function ‘main’:
c.c:17: error: type defaults to ‘int’ in declaration of ‘i’
c.c:20: error: expected ‘,’ or ‘;’ before ‘)’ token
c.c:64: error: implicit declaration of function ‘toupper’
c.c:69: error: implicit declaration of function ‘tolower’
That's compiling as C, not as C++.
My C compiler gave several screens of errors and warning before giving up.
--
Ian Collins.
Harald van D?k said: Richard Heathfield wrote: Tomás said:
> If I copy-paste your C code, and then go through it for:
>
> (a) Use of C++ keywords
>
> (b) Inconsistencies between C and C++
>
>
> And then compile it, I guarantee that the C++ version won't be slower
> or require more memory.
But the C++ version may well be a very different program as a result of
your changes, so the comparison will no longer be valid.
But if you want to give it a go, please feel free. In fact, if you like,
I won't ask you to make the following C program a faster, tighter C++
program. I will merely ask you to change it sufficiently to make it legal
C++ whilst leaving its essential character untouched, so that comparison
between the C and C++ object file translations will be meaningful. The
program must, of course, remain valid C. To leave its essential character
unchanged, I must ask that you observe the following rules:
1) the program must remain a valid C program.
2) you may refactor recursive main() - so I
didn't bother to use one.
3) you may rename identifiers, including function
names.
4) you may add casts and modify whitespace.
5) you can't change the program in any other way.
6) the output of the program must remain unchanged, of course.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
#define SPACE ' '
int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const char *b[28] = {0};
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
auto i = strlen(protected) -
(sizeof SPACE //* we need a space\
in here somewhere */ sizeof (int
) + strlen(asm) + strlen(using));
if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
{
puts("Error!");
return EXIT_FAILURE;
}
b[0] = asm + 1;
b[1] = b[0] - 1;
b[2] = protected + 8;
b[4] = b[2] - 8;
b[5] = b[4] + 1;
b[6] = b[5] + 1;
b[7] = using + 4;
b[8] = b[5];
b[9] = b[0] - 1;
b[10] = b[0] + 1;
b[11] = b[10];
b[12] = b[2] - 4;
b[13] = b[12] - 3;
b[14] = b[0];
b[16] = b[2];
b[17] = b[16] - 6;
b[19] = b[7] - 1;
b[20] = b[2] - 6;
b[21] = b[20] + 1;
b[23] = b[7] - 4;
b[24] = b[23] + 1;
b[25] = b[2] - 4;
b[27] = b[25] + 1;
printf("%.*s\n",
(int)sizeof title__of__the__program,
title__of__the__program);
while(i < sizeof b / sizeof b[0])
{
if(b[i] != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}
putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');
return 0;
}
c.c: In function ?main?:
c.c:17: error: type defaults to ?int? in declaration of ?i?
That's not an error. It's perfectly legal C90.
c.c:20: error: expected ?,? or ?;? before ?)? token
I forgot a line-splice \ when splitting the line for Usenet. Sorry about
that.
c.c:64: error: implicit declaration of function ?toupper?
c.c:69: error: implicit declaration of function ?tolower?
Those aren't errors (in C90) either. Both of those functions return int, and
neither is variadic.
That's compiling as C, not as C++.
I'll take the hit on the splice, which is trivially fixable. The others are
only errors in C99, which doesn't count.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Ian Collins said: Harald van D?k wrote:
c.c: In function ?main?:
c.c:17: error: type defaults to ?int? in declaration of ?i?
c.c:20: error: expected ?,? or ?;? before ?)? token
c.c:64: error: implicit declaration of function ?toupper?
c.c:69: error: implicit declaration of function ?tolower?
That's compiling as C, not as C++.
My C compiler gave several screens of errors and warning before giving up.
Try it again, fixing the trivial error on line 20 (for which I apologise).
Any errors you get then will be either because you have managed to dig up a
C99 compiler from somewhere (and I don't claim that the program is valid
C99), or because your compiler is simply issuing diagnostics for the sake
of it. Modulo the linesplice accident, the program is, as far as I'm aware,
a legal C90 program.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield said: I'll take the hit on the splice, which is trivially fixable. The others
are only errors in C99, which doesn't count.
I've changed my mind. I really should read my own code before posting!
There is no line splicing error on line 20. *All* the reported errors would
appear to be irrelevant to a C90 compiler.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Ian Collins said:
Harald van D?k wrote:
c.c: In function ?main?:
c.c:17: error: type defaults to ?int? in declaration of ?i?
c.c:20: error: expected ?,? or ?;? before ?)? token
c.c:64: error: implicit declaration of function ?toupper?
c.c:69: error: implicit declaration of function ?tolower?
That's compiling as C, not as C++.
My C compiler gave several screens of errors and warning before giving up.
Try it again, fixing the trivial error on line 20 (for which I apologise).
Any errors you get then will be either because you have managed to dig up a
C99 compiler from somewhere (and I don't claim that the program is valid
C99),
You claimed the program was valid C. Silly me for assuming you would
refer to an older standard without stating so.
That aside, though, your rules are obviously intentionally
unreasonable, as it is entirely possible to modify your program to make
it valid C++ without modifying either its "essential character" or its
output.
or because your compiler is simply issuing diagnostics for the sake
of it. Modulo the linesplice accident, the program is, as far as I'm aware,
a legal C90 program.
Richard Heathfield wrote: I'll take the hit on the splice, which is trivially fixable. The others are
only errors in C99, which doesn't count.
Hang on a minute, you're posting code that won't compile as C99 and
asking the audience to convert it to C++? Given your original rules, it
can't be morphed to C99, let alone C++.
I'm sure I could turn my C99 compiler back to C90, but why bother?
Maybe if you can explain the usefulness to mankind of the code, I might
give it a go....
--
Ian Collins.
Harald van D?k said: You claimed the program was valid C.
It is.
Silly me for assuming you would refer to an older standard without stating
so.
It is certainly silly to assume that everyone has started using C99 even
though almost nobody has a conforming C99 compiler.
That aside, though, your rules are obviously intentionally
unreasonable, as it is entirely possible to modify your program to make
it valid C++ without modifying either its "essential character" or its
output.
Go on then.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Ian Collins said:
Harald van D?k wrote:
c.c: In function ?main?:
c.c:17: error: type defaults to ?int? in declaration of ?i?
c.c:20: error: expected ?,? or ?;? before ?)? token
c.c:64: error: implicit declaration of function ?toupper?
c.c:69: error: implicit declaration of function ?tolower?
That's compiling as C, not as C++.
My C compiler gave several screens of errors and warning before giving up.
Try it again, fixing the trivial error on line 20 (for which I apologise).
Any errors you get then will be either because you have managed to dig up a
C99 compiler from somewhere (and I don't claim that the program is valid
C99), or because your compiler is simply issuing diagnostics for the sake
of it. Modulo the linesplice accident, the program is, as far as I'm aware,
a legal C90 program.
One good reason for passing C though a C++ compiler:
"/tmp/x.c", line 16: Error: Cannot use const char[82] to initialize
char[81].
--
Ian Collins.
Ian Collins said: Richard Heathfield wrote: I'll take the hit on the splice, which is trivially fixable.
(Withdrawn. That was a misreading of my own code.)
The others
are only errors in C99, which doesn't count.
Hang on a minute, you're posting code that won't compile as C99 and
asking the audience to convert it to C++? Given your original rules, it
can't be morphed to C99, let alone C++.
The claim I was addressing, which was originally made by Tomas, is that "I
can copy-paste your C code and compile it as C++". Are you claiming that
C90 code is not C code unless it is also C99 code?
I'm sure I could turn my C99 compiler back to C90, but why bother?
Which C99 compiler are you using? If the answer is "gcc", why bother to
claim that you have a C99 compiler? (gcc is /not/ a conforming C99
compiler.)
Maybe if you can explain the usefulness to mankind of the code, I might
give it a go....
Like much code posted here, its usefulness to mankind is that it illustrates
a point about the language. In this case, the point is that the claim "I
can copy-paste your C code and compile it as C++" is demonstrably false.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Ian Collins said: Richard Heathfield wrote: Ian Collins said:
My C compiler gave several screens of errors and warning before giving
up.
Try it again, fixing the trivial error on line 20
Don't bother - it isn't an error.
One good reason for passing C though a C++ compiler:
"/tmp/x.c", line 16: Error: Cannot use const char[82] to initialize
char[81].
Oh yes you can. Not in C++, true - but this is comp.lang.c, not
comp.lang.c++, and the code I posted is C, not C++.
Read the code more carefully. I think you jumped to a false conclusion.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Harald van D?k said:
You claimed the program was valid C.
It is.
Silly me for assuming you would refer to an older standard without stating
so.
It is certainly silly to assume that everyone has started using C99 even
though almost nobody has a conforming C99 compiler.
I didn't assume that, nor did I claim to. That aside, though, your rules are obviously intentionally
unreasonable, as it is entirely possible to modify your program to make
it valid C++ without modifying either its "essential character" or its
output.
Go on then.
Your original program:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define a(b) #b
#define SPACE ' '
int main(void)
{
const char *asm = a(asm);
const char *protected = a(protected);
const char *using = a(using);
const char *b[28] = {0};
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
auto i = strlen(protected) -
(sizeof SPACE //* we need a space\
in here somewhere */ sizeof (int
) + strlen(asm) + strlen(using));
if(strcmp(asm, "asm") != 0 || strcmp(protected, "protected") != 0 ||
strcmp(using, "using") != 0)
{
puts("Error!");
return EXIT_FAILURE;
}
b[0] = asm + 1;
b[1] = b[0] - 1;
b[2] = protected + 8;
b[4] = b[2] - 8;
b[5] = b[4] + 1;
b[6] = b[5] + 1;
b[7] = using + 4;
b[8] = b[5];
b[9] = b[0] - 1;
b[10] = b[0] + 1;
b[11] = b[10];
b[12] = b[2] - 4;
b[13] = b[12] - 3;
b[14] = b[0];
b[16] = b[2];
b[17] = b[16] - 6;
b[19] = b[7] - 1;
b[20] = b[2] - 6;
b[21] = b[20] + 1;
b[23] = b[7] - 4;
b[24] = b[23] + 1;
b[25] = b[2] - 4;
b[27] = b[25] + 1;
printf("%.*s\n",
(int)sizeof title__of__the__program,
title__of__the__program);
while(i < sizeof b / sizeof b[0])
{
if(b[i] != NULL)
{
if(i == sizeof(char) / sizeof SPACE ||
i == sizeof b / sizeof b[0] - 1)
{
putchar(toupper((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
else
{
putchar(tolower((unsigned char)
b[i][sizeof(char)/sizeof SPACE]));
}
}
else
{
putchar(SPACE);
}
i += strlen(protected) - (strlen(asm) + strlen(using));
}
putchar('.' * sizeof SPACE / sizeof(int));
putchar('\n');
return 0;
}
The changes I made (line numbers refer to the original code, not the
modified code):
Add #include <ctype.h> before line 4.
Change ' ' to ((int) ' ') on line 6.
Add before line 8:
#define asm renamed_asm
#define protected renamed_protected
#define using renamed_using
Change title__of__the__program to title on lines 14, 54 and 55.
Change on lines 14 and 15:
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n"
to
{ 'C', ' ', 't', ...
.... '.', '\n', '\n', '\n', '\n', '\n' }
Change auto to auto int on line 17.
Change // to / / on line 18.
Please tell me if any part of this, according to you, changes the
essential character, or makes it invalid C90, or if this isn't enough
to make it valid C++.
Richard Heathfield wrote: Ian Collins said:
Richard Heathfield wrote:
The others
are only errors in C99, which doesn't count.
Hang on a minute, you're posting code that won't compile as C99 and
asking the audience to convert it to C++? Given your original rules, it
can't be morphed to C99, let alone C++.
The claim I was addressing, which was originally made by Tomas, is that "I
can copy-paste your C code and compile it as C++". Are you claiming that
C90 code is not C code unless it is also C99 code?
No, but I still find it amusing that the example can't be compiled as
(current) standard C. There must be some humour in that somewhere.I'm sure I could turn my C99 compiler back to C90, but why bother?
Which C99 compiler are you using? If the answer is "gcc", why bother to
claim that you have a C99 compiler? (gcc is /not/ a conforming C99
compiler.)
Never use it. I use Sun Studio, which is approaching C99 conformance.
The Solaris headers have also migrated to C99.Maybe if you can explain the usefulness to mankind of the code, I might
give it a go....
Like much code posted here, its usefulness to mankind is that it illustrates
a point about the language. In this case, the point is that the claim "I
can copy-paste your C code and compile it as C++" is demonstrably false.
Neither of the compliers I have will compile it, gcc or Studio. Studio
barfs over asm.
--
Ian Collins.
Harald van D?k said:
<snip> Please tell me if any part of this, according to you, changes the
essential character, or makes it invalid C90, or if this isn't enough
to make it valid C++.
I'm impressed. You did a lot better than the last person to try. But you had
to hack the code around some - including one very tedious change to get
around the string literal problem.
You will, of course, recognise that the code was a highly compressed, and
thus artificial, illustration of portability problems between C and C++.
Unfortunately, in normal production code the problems are rather more
thinly spread out, and harder to spot. It is certainly true that some
people will simply mv foo.c foo.cpp, and then trust in God and their
compiler. I cannot help but see the risks in such an approach.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Ian Collins said: Richard Heathfield wrote: Which C99 compiler are you using? If the answer is "gcc", why bother to
claim that you have a C99 compiler? (gcc is /not/ a conforming C99
compiler.)
Never use it. I use Sun Studio, which is approaching C99 conformance.
Okay, fine - just as long as you realise that most people /don't/ have a C99
compiler.
The Solaris headers have also migrated to C99.Maybe if you can explain the usefulness to mankind of the code, I might
give it a go....
Like much code posted here, its usefulness to mankind is that it
illustrates a point about the language. In this case, the point is that
the claim "I can copy-paste your C code and compile it as C++" is
demonstrably false.
Neither of the compliers I have will compile it, gcc or Studio. Studio
barfs over asm.
gcc compiles it just fine here, using:
-W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align -Wpointer-arith
-Wbad-function-cast -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Winline -Wundef -Wnested-externs -Wcast-qual
-Wshadow -Wconversion -Wwrite-strings -Wno-conversion -ffloat-store -O2
If Studio barfs over asm, it's not a conforming C implementation, C90 /or/
C99. asm is a perfectly normal C identifier in user namespace.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Ian Collins said:
Richard Heathfield wrote:
Ian Collins said:
My C compiler gave several screens of errors and warning before giving
up.
Try it again, fixing the trivial error on line 20
Don't bother - it isn't an error.
One good reason for passing C though a C++ compiler:
"/tmp/x.c", line 16: Error: Cannot use const char[82] to initialize
char[81].
Oh yes you can. Not in C++, true - but this is comp.lang.c, not
comp.lang.c++, and the code I posted is C, not C++.
Read the code more carefully. I think you jumped to a false conclusion.
OK, it may be legal C, but it ain't pretty.
#include <stdio.h>
int main(void)
{
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
printf( "%s\n", title__of__the__program );
return 0;
}
I'd rather have the compiler barf.
--
Ian Collins.
Ian Collins said: Richard Heathfield wrote:
Read the code more carefully. I think you jumped to a false conclusion.
OK, it may be legal C, but it ain't pretty.
#include <stdio.h>
int main(void)
{
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
printf( "%s\n", title__of__the__program );
But my code very definitely did not do that. If you want to introduce
arbitrary errors into your copy of the code, that's up to you, but the
error was not present in /my/ code.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Ian Collins said:
Richard Heathfield wrote:
Read the code more carefully. I think you jumped to a false conclusion.
OK, it may be legal C, but it ain't pretty.
#include <stdio.h>
int main(void)
{
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
printf( "%s\n", title__of__the__program );
But my code very definitely did not do that. If you want to introduce
arbitrary errors into your copy of the code, that's up to you, but the
error was not present in /my/ code.
It might not be in your code, but the very fact that the code is legal C
makes me cringe and carry on checking my C code with my C++ compiler.
--
Ian Collins.
Ian Collins said: Richard Heathfield wrote: Ian Collins said:
#include <stdio.h>
int main(void)
{
char title__of__the__program[81] =
"C to C++ Translation\nONLY extra casts and renaming"
" of variables are allowed.\n\n\n\n\n";
printf( "%s\n", title__of__the__program );
But my code very definitely did not do that. If you want to introduce
arbitrary errors into your copy of the code, that's up to you, but the
error was not present in /my/ code.
It might not be in your code, but the very fact that the code is legal C
makes me cringe
It shouldn't do. The char arr[3] = "123"; way of initialising an array of
characters, without null-terminating it, is a well-known C idiom.
and carry on checking my C code with my C++ compiler.
That approach is likely to bite you one day, if it hasn't silently done so
already.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Stephen C. Waterbury |
last post by:
This seems like it ought to work, according to the
description of reduce(), but it doesn't. Is this
a bug, or am I missing something?
Python 2.3.2 (#1, Oct 20 2003, 01:04:35)
on linux2
Type...
|
by: David Eng |
last post by:
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java...
|
by: JKop |
last post by:
The other day I had to write some code to manipulate a Micrsoft Excel
spreadsheet. I had to write it in Visual Basic, which I haven't used for
about 5 years. Anyway, it slowly started creeping back...
|
by: GTO |
last post by:
I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is...
|
by: Eric Lindsay |
last post by:
Most of the web pages whose source I look at have a very elaborate
structure (even apart from any massive use of Javascript), often with
div in div in div layered up to six deep, lots of classes...
|
by: rohayre |
last post by:
Im a long time java developer and actually have never done anything
with java scripting. I'd like to write a short simple script for
calculating a date in the future based on today's date and a...
|
by: blangela |
last post by:
If you had asked me 5 years ago about the future of C++, I would have
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.
I have been teaching...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
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: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
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: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
