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.
May 30 '06
109  4400 
Le 30-05-2006, jacob navia <ja***@jacob.remcomp.fr> a écrit*: 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.
With a big difference: most 'programming languages' users
are professionnals, and a (good) professional is ready to
learn if it can increase its productivity.
Well, that is the same stupid war for text editors:
NotePad, Gedit, Vi[m], [X]emacs...
Its takes time to learn how to use Vi/emacs but
once you knows it, you write code more efficiently than
with NotePad.
But, if you want to read the all documentation
of vi before writting your first text, yes, chose NotePad.
Extremey complicated languages like C++ are loosing ground to more
simpler languages.
Sure ?
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.
OK, try this simple test: write a code that read a text line,
without any assumption on its maximal size. Is the C solution
really simplier that the C++ one ?
Marc Boyer
Marc Boyer said: OK, try this simple test: write a code that read a text line,
without any assumption on its maximal size. Is the C solution
really simplier that the C++ one ?
No, not really. My C solution is very simple and very short: just 23 lines,
divided as follows:
Function declarator lines: 1 \
Blank lines: 1 |
Declaration lines: 5 \ sub-total: 16 lines, in what you might
Opening brace lines: 4 / call "furniture" code - stuff that you
Closing brace lines: 4 | don't really need to worry about.
Return statement: 1 /
That leaves seven more lines. Two of those lines comprise calls to an
existing function (of my own devising, which was not written with your task
in mind, but which was very handy anyway). Another is a loop control
statement (no surprise there). The other four lines are a couple of ifs and
a couple of simple assignments.
Anyone C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
My C++ solution, however, is even simpler!
extern "C" {
#include "my_c_solution's_header.h"
};
and linking in <insert library name here>.
--
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:
Anyone C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
You underestimate the depths of Winnie the Pooh!
"Vladimir Oka" <no****@btopenworld.com> wrote: Richard Heathfield wrote:
Anyone C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
You underestimate the depths of Winnie the Pooh!
Especially in the original Latin.
Richard
Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit*: OK, try this simple test: write a code that read a text line,
without any assumption on its maximal size. Is the C solution
really simplier that the C++ one ?
No, not really. My C solution is very simple and very short: just 23 lines,
divided as follows:
Function declarator lines: 1 \
Blank lines: 1 |
Declaration lines: 5 \ sub-total: 16 lines, in what you might
Opening brace lines: 4 / call "furniture" code - stuff that you
Closing brace lines: 4 | don't really need to worry about.
Return statement: 1 /
That leaves seven more lines. Two of those lines comprise calls to an
existing function (of my own devising, which was not written with your task
in mind, but which was very handy anyway).
Which one ?
Another is a loop control
statement (no surprise there). The other four lines are a couple of ifs and
a couple of simple assignments.
Anyone C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
What is your definition of "C programmer" ?
When did you met C beginner last time ?
Or wich version of "Winnie the Pooh" did you have looked ?
My C++ solution, however, is even simpler!
extern "C" {
#include "my_c_solution's_header.h"
};
and linking in <insert library name here>.
So C++ is simpler than C: that is what I wanted to illustrate ;-)
Marc Boyer
Marc Boyer wrote: Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit :
My C++ solution, however, is even simpler!
extern "C" {
#include "my_c_solution's_header.h"
};
and linking in <insert library name here>.
So C++ is simpler than C: that is what I wanted to illustrate ;-)
Standing on the shoulders of giants, yes.
Marc Boyer said: Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit :
[Any] C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
What is your definition of "C programmer" ?
Someone who understands C.
When did you met C beginner last time ?
Have you read this newsgroup recently? My C++ solution, however, is even simpler!
extern "C" {
#include "my_c_solution's_header.h"
};
and linking in <insert library name here>.
So C++ is simpler than C: that is what I wanted to illustrate ;-)
If you say so. But C is simpler than C++, *next* time, because *next* time I
need to use such a function, I can do this:
#include "my_c_solution's_header.h"
and link in the appropriate library, without bothering with all that extern
"C" nonsense. We call it "code re-use", and I recommend it to you.
--
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 <bl*@cs.stanford.edu> 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.
But C++ programmers aren't stupid enough to need comments.
Richard
Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit*: Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit : [Any] C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
What is your definition of "C programmer" ?
Someone who understands C.
All the C99 standard ? When did you met C beginner last time ?
Have you read this newsgroup recently?
I read very quicky... There are everyday too much
messages for me. e My C++ solution, however, is even simpler!
extern "C" {
#include "my_c_solution's_header.h"
};
and linking in <insert library name here>.
So C++ is simpler than C: that is what I wanted to illustrate ;-)
If you say so. But C is simpler than C++, *next* time, because *next* time I
need to use such a function, I can do this:
#include "my_c_solution's_header.h"
and link in the appropriate library, without bothering with all that extern
"C" nonsense. We call it "code re-use", and I recommend it to you.
Did you see my ";-)" ? This was humor, joke, not an argument.
I am not going to argument what first was an example (reading one line)
and second a joke ("extern C" makes C++ better).
I do not arge that C++ is better than C, neither the opposite.
But I desagree with "simpler is better". Turing-like langage would
have been the better solution with such argument. There is a
'good compromise' to find between the complexity of the tool and
the complexity of the problems.
Marc Boyer
Marc Boyer said: Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit : Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit :
[Any] C programmer having trouble understanding the code would probably
have trouble understanding "Winnie the Pooh".
What is your definition of "C programmer" ?
Someone who understands C.
All the C99 standard ?
C90 is still C. Anyone who understands C90 sufficiently well is not likely
to struggle with C99.
When did you met C beginner last time ?
Have you read this newsgroup recently?
I read very quicky...
....and type too quicky too.
I do not arge that C++ is better than C, neither the opposite.
Good, because the answer to the question depends on what one means by
"better".
But I desagree with "simpler is better".
Good, because it depends on what you mean by "simpler".
--
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)
Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit*: Marc Boyer said: Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit : Le 31-05-2006, Richard Heathfield <in*****@invalid.invalid> a écrit :
> [Any] C programmer having trouble understanding the code would probably
> have trouble understanding "Winnie the Pooh".
What is your definition of "C programmer" ?
Someone who understands C.
All the C99 standard ?
C90 is still C. Anyone who understands C90 sufficiently well is not likely
to struggle with C99.
I agree. When did you met C beginner last time ?
Have you read this newsgroup recently?
I read very quicky...
...and type too quicky too.
because I gives you contradiction or because I ask you questions ? I do not arge that C++ is better than C, neither the opposite.
Good, because the answer to the question depends on what one means by
"better".
An is also highly dependent of the context. I guess the same man
is able to find one tool better in a situation and another tool in
another situation. But I desagree with "simpler is better".
Good, because it depends on what you mean by "simpler".
"simpler" <=> "more simple" ?
You wrote you have a "simple" C solution.
And the OP also use word like "simple" and "complex". I was assuming
there was a 'well known' meaning.
Marc Boyer
Marc Boyer said: > When did you met C beginner last time ?
Have you read this newsgroup recently?
I read very quicky...
...and type too quicky too.
because I gives you contradiction or because I ask you questions ?
Neither.
But I desagree with "simpler is better".
Good, because it depends on what you mean by "simpler".
"simpler" <=> "more simple" ?
Yes, but what do you mean by "more simple"?
You wrote you have a "simple" C solution.
I do - but what do /I/ mean by "simple"?
And the OP also use word like "simple" and "complex". I was assuming
there was a 'well known' meaning.
There is a well-established dictionary meaning, but programming has a habit
of placing words under considerable strain. "Simple" is a good example.
We have already seen that we can code a simple task ("read a line") in 90+
lines of C (as someone posted recently elsetopic here in clc), or in 23
lines of C of which only about four actually do very much (as I explained
upthread).
Clearly, C is simpler than C.
We can code the task even more simply in C++, by calling the C solution from
C++.
Clearly, C++ is simpler than C.
We can code the task even more simply in C, because we don't need the extern
nonsense.
Clearly, C is simpler than C++.
Clearly, the meaning of "simple" is not simple.
--
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 <in*****@invalid.invalid> a écrit*: Marc Boyer said:>> When did you met C beginner last time ?
>
> Have you read this newsgroup recently?
I read very quicky...
...and type too quicky too.
because I gives you contradiction or because I ask you questions ?
Neither.
So why ?
[SNIP long discussion on 'simple'] Clearly, the meaning of "simple" is not simple.
OK. In french we say "tout ça pour ça" but I do not know the
correct translation in english. Perhaps could I say "Much Ado About
Nothing".
Marc Boyer
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.
Perhaps for guys who program as a hobby.
But a *professional* has to know things deeply, and use the best tools.
For instance, I deem that any professional programmer (independently of
his job), must know several programming languages (for instance, one or
two assembly languages, C, C++, python, perl and php).
Similarly, if I would not want that physic engineers chose to not learn
physics because it is "too complex".
Yeah, I think that it is necessary to learn several languages... Even
assembly, even if you'll never ever write a single line of assembly...
For the same reason a doctor (even a general practicionner) has to
learn biology and biochemestry, even if he will never really "use"
biochemestry.
Learning assembly is at least useful for debugging (and learning
biochemestry can be useful for understanding diseases).
A professional programmer must be a specialist.
And, for becoming a specialist, several years are required... Learning
C++ features (even deeply, reading the C++03 standard) can be done in a
few weeks.
Of course, once you have finished to read the C++ standard, if you want
to be a professional, you'll have to program things during several
years, in order to really learn programming paradigms.
I deem that a professional C programmer which programs large
applications, should learn C++ paradigms (and paradigms from other
languages too), perhaps by first learning other languages, and then,
come back to C, and write code in C using these paradigms (because C
allows them, even if it is error-prone and painful for the fingers
typing on the keyboard).
Unfortunately, there are not many *professionals* in developers team
nowadays, which explains that most desktop applications s**ks nowadays
(for instance, they use 100 times more memory and CPU than they
should).
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.
First having a simplier refence manual, doesn't mean that the code will
be simplier : If you really want to program correctly with C:
You'll have to dynamically allocate a lot (all) of resources, and check
*all* allocation failures, and handle them properly without *any*
memory leak...
For doing that C++ is much easier to use (thanks to RAII and
exceptions).
Furthermore RAII and exceptions are far easier to handle without bugs
in C++.
If simplier was always better, BCPL or B would be a better language
than C.
Note also that : "Simpler on the paper" doesn't mean "simpler for the
programmer".
For instance, smalltalk has no operator precedences... It is far
simpiler for the implementation, and seems to be simplier in the
reference manual...
But, the reality is that it is a pain for programmers... And that it is
really error prone.
In what sense, malloc/realloc/free is simplier than std::string for
string handling?
SuperKoko a écrit : 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.
First having a simplier refence manual, doesn't mean that the code will
be simplier : If you really want to program correctly with C:
You'll have to dynamically allocate a lot (all) of resources, and check
*all* allocation failures, and handle them properly without *any*
memory leak...
For doing that C++ is much easier to use (thanks to RAII and
exceptions).
Furthermore RAII and exceptions are far easier to handle without bugs
in C++.
Mmmm... that is easy to do in C if you use Boehms Weiser garbage
collector.
Many C compilers offer it, for instance gcc, lcc-win32 and others.
Even C++ people can benefit from it, no kidding! :-)
Richard Bos wrote: "Vladimir Oka" <no****@btopenworld.com> wrote:
Richard Heathfield wrote:
Anyone C programmer having trouble understanding the code would
probably have trouble understanding "Winnie the Pooh".
You underestimate the depths of Winnie the Pooh!
Especially in the original Latin.
I'll be you like the Latin, Mr. "Cow".
Brian
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.
<OT style="all my responses are OT, not just this part">
IMHO the "learning curve" associated with C++ has more to do with
learning the precepts of Object-Oriented Programming than the language
itself. If you have a solid understanding of OOP, then a lot of the
"complexity" of C++ disappears.
</OT>
C has less surprises, less to learn, and uses FAR LESS MEMORY.
C uses far less memory? If you mean a program written in C will compile
to a smaller executable than a comparable program written in C++, then
I can't believe that claim at all. Whether or not you can consistently
get your C compiler to spit out smaller executables than your C++
compiler for a similar piece of source code is more likely because the
C compiler generated better object code than the C++ compiler. Hell, if
I compile a C++ program to run in legacy 16-bit mode on my x86, I'll
bet it'll be smaller than the corresponding C program written to run on
32-bit Windows, by virtue of the fact that sizeof int will likely be 2
bytes smaller in the 16-bit version, *and* the fact that I can compile
the 16-bit version to a flat binary file, whereas the Windows version
will have to be packaged into the Portable Executable (EXE) file
format, which will invariably bloat the resulting program with EXE
headers, relocation tables, etc. My point is that the size of compiled
programs in either C or C++ (or any language) is more dependent upon
a) how well the compiler can generate object code for the given
language, including how well it can optimize the code
b) which machine you're compiling on and/or the target OS. E.g. if a
particular CPU has a single machine instruction equivalent to
printf("hello world\n") (let's assume stdout goes to a terminal on this
platform), then a "hello world" program you compile on that system will
probably be much smaller than it would be processors that don't support
the PRINT HELLO WORLD instruction.
As for "C has less surprises", I have two words: undefined behavior ;-)
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.
Well, I don't usually sit down at my computer, ready to program, and
then wait 15 minutes while I "load" a page-for-page copy of the latest
C Standard into my brain. You learn a language by using it, not by
memorizing it.
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!
Again, I don't think C++ is overly complex. I think it *can* be. That
is, the programmer is the one who controls how complex his code is - it
is fairly easy to obfuscate C++ code, but there are ways to
de-obfuscate it as well (such as the "using [namespace];" directive to
prevent code from being polluted with namespace qualifiers). The core
language isn't really that hard to grasp, especially if you already
have a knowledge of C and, as I mentioned, you understand the basics of
OOP.
Mike S
Richard Heathfield wrote: 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.
No, don't forget this is embedded code, so it gets built for the target
with a C compiler, I just use C++ on the host for development and testing.
I just looked back through the code I first used this approach on (back
in '95) and there were three reasons for doing it:
1) lots of smelly code and resultant bugs caused by abuse of enums.
2) lots of smelly code and bugs caused by inappropriate casts. C++
static_cast is a powerful tool for both highlighting (easy to grep for)
and checking casts.
3) I wanted to use mock objects for the hardware the device drivers were
controlling. This is probably why I still do this for new code, it
enables simple tricks that are hard (if not down right impossible) to do
in C like:
#include <inttypes.h>
#if defined __cplusplus
struct SomeRegister
{
SomeRegister& operator=( uint32_t ) {
//do stuff on setting register
}
operator uint32_t() {
//do stuff on reading register
}
};
#else
typedef uint32_t SomeRegister;
#endif
typedef struct
{
SomeRegister reg;
} Registers;
int main(void)
{
Registers registers;
registers.reg = 42;
uint32_t n = registers.reg;
}
--
Ian Collins.
Juuso Hukkanen posted: Good catch Old Wolf,
What is this... a witch hunt?!
This is absolutely ridiculous! There are people who post to newsgroups
under a pseudonym (Old Wolf for example), and there are people who post
using their full name.
You're trying to weed out someone who has changed psuedonym... that's quite
admirable -- I've a jig-saw puzzle in my cupboard if you'd like to play
with that later.
Both are cracy about using "monkeys":
"monkey" is a well-known choice for an arbitrary word. (It's also the prime
example of a word which ends in "y" but yet doesn't change to "ies" to form
the plural).
and both favor 'k' as variable:
"k" is used throughout the science community significantly to signify a
constant. It's been plastered throughout every Physics book I've ever read.
and Blah classes:
If "Blah" isn't an arbitrary name, I don't know what is.
Amazingly both Jkop and Tomás sign their messages by putting a dash
before their name ( -Jkop / -Tomás )
Oh by Jesus then it simply MUST be me.
Ok, the last one could be purely a culture thing since Reverse DNS
puts them both to to Ireland [City: Dublin]
Last time I checked there were about 1.5 million people in Dublin.
Lift my DNA off one of his posts and then I'll admit it was me. Also, you
get the secret, mystery, sparkly prize!
If that will be all, can we get back to discussing the C programming
language?
-Tomás
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.
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.
Then why are you trying to complicate the language with foolishness
such as operator overloading, garbage collection, references, etc.?
--
"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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Juuso Hukkanen wrote: Good catch Old Wolf,
Considering that Tomás says Jkop is a different person, You may have
find his long lost twin brother Alternatively you may have provided
important clues for his true identity, in case he has suffers from
severe amnesia. In either case this is a pretty fantastic discovery!
Check:
Both are cracy about using "monkeys":
and both favor 'k' as variable:
and Blah classes:
Amazingly both Jkop and Tomás sign their messages by putting a dash
before their name ( -Jkop / -Tomás )
Ok, the last one could be purely a culture thing since Reverse DNS
puts them both to to Ireland [City: Dublin]
that according to IP (83.70.62.165 ) taken from the first message by
Tomás written:
and also according to Jkops last message IP (83.70.59.143)
Also:
The only guy ever to use NU**@NULL.NULL as an address here
(as far as I can tell). He changed it a couple of weeks ago --
coincidence again?
A propensity to write "signed main()" (actually this was how I
first noticed).
Variables called "cheddar" and "chocolate".
Replying to any request for code with something that uses
reinterpret_cast to a reference type, or " *new ", or a ten-page
bizarre_cast<> template that doesn't actually do anything
useful.
And of course his manner of insulting anybody who disagrees
with the last thought that popped into his head: http://groups.google.com/group/comp....b1585e1a5aed4d
The only anomaly is that Tomás hasn't called any variables
"poo" yet (maybe he grew up a bit).
I wonder how long he will continue to deny it (or if anybody
else on this NG cares, which is less likely).
Ian Collins said: Richard Heathfield wrote: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.
No, don't forget this is embedded code, so it gets built for the target
with a C compiler, I just use C++ on the host for development and testing.
Very, very, very bad idea. You test under C++ rules, but execute under C
rules, and the two sets of rules are different. Wouldn't it make more sense
to test under the same rules you will use for execution?
--
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)
Old Wolf said: I wonder how long he will continue to deny it (or if anybody
else on this NG cares, which is less likely).
We don't care one iota. We don't know what you're talking about. We're not
interested. We'll work out for ourselves whether Tomas is someone we get on
with, and we'll do it individually, not as a group.
For my part, Tomas comes across as a reasonably knowledgeable but somewhat
abrasive poster. When he lightens up a bit, he'll be fine. And I don't give
two hoots whether he has, or has not, reinvented himself, if the end
product is someone who can write C code well. A little less intensity would
be a welcome change, though.
--
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:
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.
No, don't forget this is embedded code, so it gets built for the target
with a C compiler, I just use C++ on the host for development and testing.
Very, very, very bad idea. You test under C++ rules, but execute under C
rules, and the two sets of rules are different. Wouldn't it make more sense
to test under the same rules you will use for execution?
No. Don't forget development testing isn't on the same hardware as the
production environment (which has its own comprehensive acceptance tests).
With all the test cases I have tried, the Sun C and C++ compilers
generate the same code given the same source.
If there was a way to do the mock objects I described in C, I might
consider building the C parts of the test harness with the C compiler,
but then I'd loose the extra type checking.
--
Ian Collins.
Ian Collins said: Richard Heathfield wrote:
Very, very, very bad idea. You test under C++ rules, but execute under C
rules, and the two sets of rules are different. Wouldn't it make more
sense to test under the same rules you will use for execution?
No. Don't forget development testing isn't on the same hardware as the
production environment (which has its own comprehensive acceptance tests).
Okay, so you test it again using the live code. Fair enough.
--
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)
"Default User" <de***********@yahoo.com> wrote: Richard Bos wrote:
"Vladimir Oka" <no****@btopenworld.com> wrote:
Richard Heathfield wrote:
>
> Anyone C programmer having trouble understanding the code would
> probably have trouble understanding "Winnie the Pooh".
You underestimate the depths of Winnie the Pooh!
Especially in the original Latin.
I'll be you like the Latin, Mr. "Cow".
Verum: amo.
Richard, off stage left singing "Ursuli verba cano!"
On Thu, 01 Jun 2006 00:21:26 GMT, "Tomás" <No.Email@Address> wrote: Lift my DNA off one of his posts and then I'll admit it was me.
No need to go into needle-type of pointers, you are probably right.
Sorry and have a great day -Tomás.
Juuso
"Keith Thompson" <ks***@mib.org> wrote Malcolm. 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?
It is an analogue device. So instead of having eight on/off transistors to
represent an 8-bit byte, it has a single charge, which it can resolve to 256
levels with acceptable accuracy. There is always the slight danger, however,
of a shift by one place.
The memory is worse that a conventional one, because it is less reliable, so
why use it? Because it is cheaper to produce.
So you see that a shift from 12 to 18 is impossible. However a shift from 12
to 11 is possible, if we use ASCII. However if we don't use ASCII, but some
encoding where digits are contiguous with non-digits, AI or an intelligent
human reader can make the correction. "Buy 1* eggs" is nonsense, but since *
is contigous with 2, and '#' is contiguous with eight, the correct meaning
can be retrieved. Similarly English text with one lettfr wrong is perfectly
readable.
Where the memory falls down is where the computer insists on an exact
representation, for instance a list of random numbers. Obviously you
wouldn't use it for a life support system.
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.)
Of course I have. It is a perfectly sensible, but hypothetical, example of a
technological change forcing abandonment of one of the provisions of the
standard.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
In article <E4********************@bt.com>,
Malcolm <re*******@btinternet.com> wrote: However if we don't use ASCII, but some
encoding where digits are contiguous with non-digits, AI or an intelligent
human reader can make the correction. "Buy 1* eggs" is nonsense, but since *
is contigous with 2, and '#' is contiguous with eight, the correct meaning
can be retrieved.
This is comp.lang.c and the C standards require that the digits
be numerically contiguous. 2 cannot be numerically contiguous with *
because 2 must be numerically contiguous with 1 and 3.
It is an analogue device. So instead of having eight on/off transistors to
represent an 8-bit byte, it has a single charge, which it can resolve to 256
levels with acceptable accuracy. There is always the slight danger, however,
of a shift by one place.
The memory is worse that a conventional one, because it is less reliable, so
why use it? Because it is cheaper to produce.
If it is that much cheaper, use more of it and use ECC or
constellation codes. Hardware corrections for marginal memory is
a developed field: you don't want to risk losing a multimillion dollar
space-probe to the first cosmic ray that comes along.
Besides, "Buy 1* eggs" is not nonsense: * is used to indicate
footnotes, and old-time programmers use * in ways that pun upon
regular expressions. If a programmer sent me "Buy 1* eggs", I would
interpret it as "buy one or more eggs", and "buy exactly 12 eggs"
would not be anywhere near foremost in my mind.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
"Malcolm" <re*******@btinternet.com> writes: "Keith Thompson" <ks***@mib.org> wrote Malcolm. 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?
It is an analogue device. So instead of having eight on/off transistors to
represent an 8-bit byte, it has a single charge, which it can resolve to 256
levels with acceptable accuracy. There is always the slight danger, however,
of a shift by one place.
The memory is worse that a conventional one, because it is less reliable, so
why use it? Because it is cheaper to produce.
So you see that a shift from 12 to 18 is impossible. However a shift from 12
to 11 is possible, if we use ASCII. However if we don't use ASCII, but some
encoding where digits are contiguous with non-digits, AI or an intelligent
human reader can make the correction. "Buy 1* eggs" is nonsense, but since *
is contigous with 2, and '#' is contiguous with eight, the correct meaning
can be retrieved. Similarly English text with one lettfr wrong is perfectly
readable.
Where the memory falls down is where the computer insists on an exact
representation, for instance a list of random numbers. Obviously you
wouldn't use it for a life support system.
If it's as unreliable as you suggest, I wouldn't use it at all.
Mechanisms for automatically correcting memory errors are well known
and commonly implemented in current bit-oriented memory. They don't
depend on assumptions about what the data is really supposed to look
like.
If this hypothetical memory is so cheap, it would be worthwhile to use
a bit more and dedicate some of it to error detection and correction,
to the point where it's as reliable as current bit-oriented memory.
With the kind of error correction you're talking about, your
hypothetical memory wouldn't even be able to store a copy of this
article. The AI would probably "correct" this:
If a word reads "exactky" the AI will correct it to "exactly".
to this:
If a word reads "exactly" the AI will correct it to "exactly".
If it can't reliably store arbitrary data, whether it looks right or
not, it's not really memory.
--
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. ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: In article <E4********************@bt.com>,
Malcolm <re*******@btinternet.com> wrote:However if we don't use ASCII, but some
encoding where digits are contiguous with non-digits, AI or an intelligent
human reader can make the correction. "Buy 1* eggs" is nonsense, but since *
is contigous with 2, and '#' is contiguous with eight, the correct meaning
can be retrieved.
This is comp.lang.c and the C standards require that the digits
be numerically contiguous. 2 cannot be numerically contiguous with *
because 2 must be numerically contiguous with 1 and 3.
That was the point. Malcolm is trying to construct a hypothetical
future system on which a requirement of the current C standard (the
contiguity of the digits) would be an inconvenience.
IMHO there are much better ways to make the same point (e.g, if
trinary storage replaces binary for some reason).
--
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 Tue, 30 May 2006, jacob navia <ja***@jacob.remcomp.fr> wrote: 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.
*the point is to find what to get and what to lose.*
i use from C++ the classes, operator definition and function
overloading. i use malloc-free-realloc like functions in that
environment (never new()). i have problem with C stream and C++ stream
functions so i'm rewriting them too in assembly.
the same for str* sscanf functions
If there are these changes and if i don't use the remain, C++ should
be a very easy language.
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?
it is not a problem,
it is easy: i write a dummy function that has the appearance that i
want; i compile (using C++ compiler) it for assembly and i find the
name. so i can write that function in assembly or in any other
language that allow that name.
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!
i agree but i think that "simple" is to use C++ classes too
for to put in order functions and data. it is possible the compiler
has to use not simple names. the important it is that the programmer
can easy find and use these names (if necessary with use of the
compiler too).
jacob
jacob
RSoIsCaIrLiIoA wrote: On Tue, 30 May 2006, jacob navia <ja***@jacob.remcomp.fr> wrote:
.... snip ... 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.
*the point is to find what to get and what to lose.*
i use from C++ the classes, operator definition and function
overloading. i use malloc-free-realloc like functions in that
environment (never new()). i have problem with C stream and C++ stream
functions so i'm rewriting them too in assembly.
the same for str* sscanf functions
Why? What problems do you have with these routines? They are usually
well tested, standard and optimised.
On 1 Jun 2006 23:00:22 -0700, "santosh" <sa*********@gmail.com> wrote: RSoIsCaIrLiIoA wrote: On Tue, 30 May 2006, jacob navia <ja***@jacob.remcomp.fr> wrote:
... snip ... >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.
*the point is to find what to get and what to lose.*
i use from C++ the classes, operator definition and function
overloading. i use malloc-free-realloc like functions in that
environment (never new()). i have problem with C stream and C++ stream
functions so i'm rewriting them too in assembly.
the same for str* sscanf functions
Why? What problems do you have with these routines? They are usually
well tested, standard and optimised.
functions like sscanf scanf fgets strcpy str* etc sprintf
are well tested for doing buffer overflows and are not easy too
(so for write with them a bulletproof function you have to write for 2
or 3 days and if it is goes wrong the function for input is not
bulletproof too :) )
function like malloc, new() don't find errors of out of bound in
memory arrays
On 2006-06-02, vario <n1@a.ag> wrote: On 1 Jun 2006 23:00:22 -0700, "santosh" <sa*********@gmail.com> wrote:RSoIsCaIrLiIoA wrote: On Tue, 30 May 2006, jacob navia <ja***@jacob.remcomp.fr> wrote:... snip ... >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.
*the point is to find what to get and what to lose.*
i use from C++ the classes, operator definition and function
overloading. i use malloc-free-realloc like functions in that
environment (never new()). i have problem with C stream and C++ stream
functions so i'm rewriting them too in assembly.
the same for str* sscanf functions
Why? What problems do you have with these routines? They are usually
well tested, standard and optimised.
functions like sscanf scanf fgets strcpy str* etc sprintf
are well tested for doing buffer overflows and are not easy too
(so for write with them a bulletproof function you have to write for 2
or 3 days and if it is goes wrong the function for input is not
bulletproof too :) )
Not if you use them properly. And even if you don't know how to do that,
it takes about 5 minutes to grab a textbook (I don't have K&R right now,
so I use C Unleashed) and figure it out. /Not/ two or three days.
function like malloc, new() don't find errors of out of bound in
memory arrays
OTOH, they don't waste time checking for such errors. They assume that
the caller was written by someone who knows how to program, which doesn't
seem like an unreasonable assumption to me.
--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
You can lead a blind man to water but you can't make him chug it.
Andrew Poelstra wrote: On 2006-06-02, vario <n1@a.ag> wrote: On 1 Jun 2006 23:00:22 -0700, "santosh" <sa*********@gmail.com> wrote:
.... snip ...Why? What problems do you have with these routines? They are usually
well tested, standard and optimised.
functions like sscanf scanf fgets strcpy str* etc sprintf
are well tested for doing buffer overflows and are not easy too
(so for write with them a bulletproof function you have to write for 2
or 3 days and if it is goes wrong the function for input is not
bulletproof too :) )
Not if you use them properly. And even if you don't know how to do that,
it takes about 5 minutes to grab a textbook (I don't have K&R right now,
so I use C Unleashed) and figure it out. /Not/ two or three days.
function like malloc, new() don't find errors of out of bound in
memory arrays
OTOH, they don't waste time checking for such errors. They assume that
the caller was written by someone who knows how to program, which doesn't
seem like an unreasonable assumption to me.
Some compilers, like MSVC and lcc-win32 provide an option to turn on
bounds checking. But as you say, it's better to write well thought out
code rather than cross your fingers and rely on external aids.
On 2 Jun 2006 12:34:19 -0700, "santosh" <sa*********@gmail.com> wrote: Andrew Poelstra wrote: On 2006-06-02, vario <n1@a.ag> wrote: > On 1 Jun 2006 23:00:22 -0700, "santosh" <sa*********@gmail.com> wrote:... snip ... >>Why? What problems do you have with these routines? They are usually
>>well tested, standard and optimised.
>
> functions like sscanf scanf fgets strcpy str* etc sprintf
> are well tested for doing buffer overflows and are not easy too
> (so for write with them a bulletproof function you have to write for 2
> or 3 days and if it is goes wrong the function for input is not
> bulletproof too :) )
>
Not if you use them properly. And even if you don't know how to do that,
it takes about 5 minutes to grab a textbook (I don't have K&R right now,
so I use C Unleashed) and figure it out. /Not/ two or three days.
> function like malloc, new() don't find errors of out of bound in
> memory arrays
OTOH, they don't waste time checking for such errors. They assume that
the caller was written by someone who knows how to program, which doesn't
seem like an unreasonable assumption to me.
Some compilers, like MSVC and lcc-win32 provide an option to turn on
bounds checking. But as you say, it's better to write well thought out
code rather than cross your fingers and rely on external aids.
fate un poco quello che vi piace a me piace mettere tutto sottosopra e
ordinare poi
"Keith Thompson" <ks***@mib.org> wrote Where the memory falls down is where the computer insists on an exact
representation, for instance a list of random numbers. Obviously you
wouldn't use it for a life support system.
If it's as unreliable as you suggest, I wouldn't use it at all.
Let's say we are writing a video game.
The game consists largely of raster data for images, audio samples, and 3d
mesh data.
If a pixel slips a place it makes no difference whatsoever, similarly with
an audio sample. An error in 3d normal similarly should make no difference,
whilst a slip in a coordinate will just introduce a tiny visual glitch, if
you are unlucky.
So the memory is perfectly acceptable for these purposes. Say that it slips
one 256th value per day of operation, and 99% of the memory hold this type
of data. On average, the game will malfunction three to four times a year.
That's not good, but a marketing person could well judge that it is
acceptable, if it means that the games can be bigger and faster, or the
console cheaper. You get software crashes much more frequently than that.
Obviously executable instructions would have to be held in conventional
chips. But what about text data? We don't really want to hold text data in
this memory, but at the endo of the day we are talking about an error-rate
in human-readable text that is smaller than a newspaper misprint rate. If it
is cheap and convenient enough, some of that memory might well be used for
text.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
"CBFalconer" <cb********@yahoo.com> 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.
Then why are you trying to complicate the language with foolishness
such as operator overloading, garbage collection, references, etc.?
Garbage collection actually simplifies things. Consider
char **raster(int width, int height)
{
char **answer;
int i;
int ii;
answer = malloc(height * sizeof(char *));
if(!answer)
return 0;
/* don't strictly need this, but for safety */
for(i=0;i<height;i++)
answer[i] =0;
for(i=0;i<height;i++)
{
answer[i] = malloc(width);
if(!answer[i])
{
for(ii=0;ii<i;ii++)
free(answer[ii]);
free(answer);
return 0;
}
}
return answer;
}
char **raster(int width, int height)
{
char **answer;
int i;
answer = gmalloc(height * sizeof(char *));
if(!answer)
return 0;
for(i=0;i<height;i++)
{
answer[i] = gmalloc(width);
if(!answer[i])
return 0;
}
}
With exceptions
char **raster(int width, int height)
{
char **answer;
int i;
answer = xmalloc(height * sizeof(char *));
for(i=0;i<height;i++)
answer[i] = xmalloc(width);
return answer;
}
The snag with exceptions is that people try to complicate things by allowing
user defined excepetions. A subroutine can run out of memory, or it can get
into an illegal state because of some internal error. So we only need two
exceptions, and most programs can ignore them and simply terminate when they
occur.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
In article <2-********************@bt.com>,
Malcolm <re*******@btinternet.com> wrote: "Keith Thompson" <ks***@mib.org> wrote
Where the memory falls down is where the computer insists on an exact
representation, for instance a list of random numbers. Obviously you
wouldn't use it for a life support system.
If it's as unreliable as you suggest, I wouldn't use it at all.
Let's say we are writing a video game.
The game consists largely of raster data for images, audio samples, and 3d
mesh data.
If a pixel slips a place it makes no difference whatsoever, similarly with
an audio sample. An error in 3d normal similarly should make no difference,
whilst a slip in a coordinate will just introduce a tiny visual glitch, if
you are unlucky.
So the memory is perfectly acceptable for these purposes.
Modern image files and audio files contain data -about- the image or
audio. For audio in particular, the control data is not always just
in header fields that could be stored seperately: audio/video
streams contain mixed-in information about field sizes, number
of repeats, which part of the active whole is changing, resolution,
and so on. If you have something go wrong in the control data, then
the effects on the image or audio sample could be quite large.
Indeed, you should consider modern A/V file formats to essentially
be compressed data -- corrupt any part of the data and you can
end up with something -quite- different from that point onward,
Say that it slips
one 256th value per day of operation, and 99% of the memory hold this type
of data. On average, the game will malfunction three to four times a year.
Error rates in modern memory chips are already higher than that --
CMOS turns out to make a pretty good particle detector. (CCD cameras
are essentially just memory chips with a transparent window exposing
the electronics.) But memory chip manufacturers know it, and
build in memory test and correction.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Walter Roberson wrote:
.... snip ...
Error rates in modern memory chips are already higher than that --
CMOS turns out to make a pretty good particle detector. (CCD cameras
are essentially just memory chips with a transparent window exposing
the electronics.) But memory chip manufacturers know it, and
build in memory test and correction.
No they don't. Some memory _systems_ provide ECC for the purpose,
which requires extra memory bits and so-called ECC memory. The
vast majority of PCs sold today omit all this for bean counting
reasons, and take advantage of the ignorance of the unwashed
public, who in turn are failing to insist on ECC memory and
reliability.
Always insist on ECC memory in any new systems you buy.
--
Some informative links:
news:news.announce.newusers http://www.geocities.com/nnqweb/ http://www.catb.org/~esr/faqs/smart-questions.html http://www.caliburn.nl/topposting.html http://www.netmeister.org/news/learn2quote.html
Tomás wrote: 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.
You must be young. Go ahead and insult people's stupidity - There's a
lot around. But remember the persone you are insulting for their
stupidity may someday be your boss. Then who will feel stupid. Don't
say it can't happen, I've seen it happen many times.
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.
I don't think you got the point. I could get a lot more work if I would
learn C# or V.B.. I've got enough work doing C, thank you very much.
It's where I want to be doing what I want.
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.
Ditto.
A computer programming language isn't a gadget, it's a tool. Draw the
distinction.
Yes it is a tool, but it can be either very simple or very complex and
you get the same results, from C or C++, do you not?
I choose simple and efficient.
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.
You must be brilliant because you are so humble about it. But hey, you
are young, and that makes a big difference. When I was 15 I was like
sponge soaking up all knowledge I could get. Now I am closer to 50 and
I am still absorbing knowledge, just not at the pace I did at 15. And
there is ever more knowledge to acquire. After awhile I want to do
something else like play with my kids and have a life. I still have to
bring the paycheck home but I do not have or want to give any more of my
life to learning yet another language of the moment. C does just fine
and I've got nearly twenty years of useful C library routines that has
been ported to multiple platforms. The library has encapsulated most of
the common things that I am asked to do, and they always wonder how I am
so quick to get the work done. Amazing how productive you can be when
you stop reinventing the wheel.
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.
Ah, wait until you are my age. But then again, this is like insulting
someone for stupidity. We've all been stupid at one time or another
about something. Right now you are so ignorant of your own stupidity
that you do not even realize you are being stupid. And some day you
will be the "old guy" and your memory will not be what it once was. But
hopefully by then you will have shed much of your present stupidity.
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
--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========
"CBFalconer" <cb********@yahoo.com> wrote Walter Roberson wrote:
... snip ...
Error rates in modern memory chips are already higher than that --
CMOS turns out to make a pretty good particle detector. (CCD cameras
are essentially just memory chips with a transparent window exposing
the electronics.) But memory chip manufacturers know it, and
build in memory test and correction.
No they don't. Some memory _systems_ provide ECC for the purpose,
which requires extra memory bits and so-called ECC memory. The
vast majority of PCs sold today omit all this for bean counting
reasons, and take advantage of the ignorance of the unwashed
public, who in turn are failing to insist on ECC memory and
reliability.
Always insist on ECC memory in any new systems you buy.
It depends what you are doing with the computer.
If you are programming on it, then I agree.
On the other hand if you use it mainly as a games machine, is a malfunction
every few weeks really too bad, given that the software will probably crash
due to programming errors several times during that period? It depends what
the price premium is, and what your attitude is to money. Bill Gates can
spend an extra hundred dollars without worrying about it. Some poor single
mother scraping togther money for a Christmas present might well feel that
non-ECC is an economy she can make.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
Malcolm said: "CBFalconer" <cb********@yahoo.com> wrote
<snip>
Always insist on ECC memory in any new systems you buy.
It depends what you are doing with the computer.
If you are programming on it, then I agree.
On the other hand if you use it mainly as a games machine, is a
malfunction every few weeks really too bad,
Yes.
given that the software will
probably crash due to programming errors several times during that period?
That's really too bad, too.
It depends what the price premium is, and what your attitude is to money.
Bill Gates can spend an extra hundred dollars without worrying about it.
Some poor single mother scraping togther money for a Christmas present
might well feel that non-ECC is an economy she can make.
Another economy she can make is that of not buying software that crashes her
machine several times every few weeks. It is an economy that everyone
should make, to discourage sloppy programming practices.
--
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)
Malcolm wrote: "CBFalconer" <cb********@yahoo.com> wrote Walter Roberson wrote:
... snip ...
Error rates in modern memory chips are already higher than that --
CMOS turns out to make a pretty good particle detector. (CCD cameras
are essentially just memory chips with a transparent window exposing
the electronics.) But memory chip manufacturers know it, and
build in memory test and correction.
No they don't. Some memory _systems_ provide ECC for the purpose,
which requires extra memory bits and so-called ECC memory. The
vast majority of PCs sold today omit all this for bean counting
reasons, and take advantage of the ignorance of the unwashed
public, who in turn are failing to insist on ECC memory and
reliability.
Always insist on ECC memory in any new systems you buy.
It depends what you are doing with the computer.
If you are programming on it, then I agree.
On the other hand if you use it mainly as a games machine, is a malfunction
every few weeks really too bad, given that the software will probably crash
due to programming errors several times during that period? It depends what
the price premium is, and what your attitude is to money. Bill Gates can
spend an extra hundred dollars without worrying about it. Some poor single
mother scraping togther money for a Christmas present might well feel that
non-ECC is an economy she can make.
That periodic malfunction may not be noticeable, because it has
destroyed some heart software that hasn't been used in the
interim. So ECC is always valuable, and omitting it is a false
economy. For example, what is the cost of reinstalling everything
from CDs, assuming you even have the original CDs, in time and
trouble.
--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.
In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.net> wrote: That periodic malfunction may not be noticeable, because it has
destroyed some heart software that hasn't been used in the
interim. So ECC is always valuable, and omitting it is a false
economy. For example, what is the cost of reinstalling everything
from CDs, assuming you even have the original CDs, in time and
trouble.
The chance of a memory error resulting in the need to reinstall is so
low it is not usually worth the money. I don't think I've seen a case
attributable to it in 15 years, and none for certain before that.
If we'd put ECC memory in all our machines it would have added up
to a huge amount over the years.
It's much more important of course if you are producing data whose
value depends on its absolute reliability.
Incidentally, memory errors were much more common before manufacturers
discovered that much of the radiation came from the (usually ceramic)
chip packaging rather than cosmic rays.
-- Richard
Richard Tobin wrote: CBFalconer <cb********@maineline.net> wrote:
That periodic malfunction may not be noticeable, because it has
destroyed some heart software that hasn't been used in the
interim. So ECC is always valuable, and omitting it is a false
economy. For example, what is the cost of reinstalling everything
from CDs, assuming you even have the original CDs, in time and
trouble.
The chance of a memory error resulting in the need to reinstall is
so low it is not usually worth the money. I don't think I've seen
a case attributable to it in 15 years, and none for certain before
that. If we'd put ECC memory in all our machines it would have
added up to a huge amount over the years.
You don't know, because the non-ECC machine simply ignores the
error. It may (lucky) or may not (unlucky) cause an immediate
crash. Mostly you will be unlucky. The error cause is likely to
be something completely random, such as a cosmic ray.
We were much better off in the early days when all PCs had parity
memory and crashed on any error. More annoyed, but better off.
The head in the sand technique doesn't really work.
--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.
vario <n1@a.ag> wrote: On 2 Jun 2006 12:34:19 -0700, "santosh" <sa*********@gmail.com> wrote:
Andrew Poelstra wrote: On 2006-06-02, vario <n1@a.ag> wrote:
> On 1 Jun 2006 23:00:22 -0700, "santosh" <sa*********@gmail.com> wrote:
... snip ... >>Why? What problems do you have with these routines? They are usually
>>well tested, standard and optimised.
>
> functions like sscanf scanf fgets strcpy str* etc sprintf
> are well tested for doing buffer overflows and are not easy too
> (so for write with them a bulletproof function you have to write for 2
> or 3 days and if it is goes wrong the function for input is not
> bulletproof too :) )
>
Not if you use them properly. And even if you don't know how to do that,
it takes about 5 minutes to grab a textbook (I don't have K&R right now,
so I use C Unleashed) and figure it out. /Not/ two or three days.
> function like malloc, new() don't find errors of out of bound in
> memory arrays
OTOH, they don't waste time checking for such errors. They assume that
the caller was written by someone who knows how to program, which doesn't
seem like an unreasonable assumption to me.
Some compilers, like MSVC and lcc-win32 provide an option to turn on
bounds checking. But as you say, it's better to write well thought out
code rather than cross your fingers and rely on external aids.
fate un poco quello che vi piace a me piace mettere tutto sottosopra e
ordinare poi
Oh ja? Wel, _jouw_ mammie draagt legerkistjes!
Richard
Richard Tobin wrote: Incidentally, memory errors were much more common before manufacturers
discovered that much of the radiation came from the (usually ceramic)
chip packaging rather than cosmic rays.
<amazing true stories>
I remember in the 1970's some chip salesmen trying to discourage
purchase
of Japanese chips, by claiming that their materials had residual
radioactivity
from Hiroshimi and Nagasaki!
In fact Japanese chips were far more reliable, partly because their
"clean rooms"
were much cleaner. A friend was chief scientist at a chip
manufacturer.
When failure rates went up, he appeared on the factory floor and
demanded: "OK, which one of you girls changed her brand of hair spray?"
</amazing true stories>
James Dow Allen 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: 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: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
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...
|
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...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
