Which language pays most 17457 -- C++ vs. Java?
Ken Lee
In article <1997121219...@sirius.infonex.com>, Mix
<mixm...@remail.obscura.com> writes:
|> The question is, which language will pay top 17457 in the long run? Java is
|> still in its infancy but seems to have a great potential. C++ is a mature
|> albeit cumbersome language and is probably poised to become a legacy
|> language later. The jobs will be there in the long run, although the
|> market will likely never be as good as now. What do you think about it?
Unless you're a compiler expert, knowledge of programming languages
is not going to get your top dollar. Most employers want people
who know how to use programming languages to solve real problems.
For example, someone who knows how to use C++ to write TCP/IP interfaces
(or GUIs or databases or whatever) is probably going to get better offers
than someone who just knows C++.
--
Ken Lee, ken...@rahul.net, http://www.rahul.net/kenton/
Roedy Green
Mix wrote:
>hich language will pay top 17457 in the long run?
Two answers:
1. Philistine. Which language you should study is a RELIGIOUS issue.
2. the law of supply and demand. Java programmers are in shorter supply
now, but then C++ programmers are harder to manufacture.
For the JAVA GLOSSARY and the CMP Utilities: http://oberon.ark.com/~roedy
--
Roedy Green Roedy rhymes with Cody ro...@bix.com ICQ:5144242
Canadian Mind Products contract programming (250) 285-2954
POB 707 Quathiaski Cove Quadra Island BC Canada V0P 1N0
-30-
Robert S. White
In article <1997121219...@sirius.infonex.com>,
mixm...@remail.obscura.com says...
>
>Please accept my apologies for the anonymous way of posting. I will
>graduate from a college very soon with a Computer Science degree under
>my belt and I need a career advice from seasoned professionals.
>
>Unfortunately, my college taught languages that were "scientifically"
>correct but useless practically. FORTRAN is dead and has started to stink
>because of its poor and incomprehensible grammar, and its emphasis on
>poor programming style. It was good for the punch card epoch but not
>for the client-server world.
>
>Eiffel is a good language for people who are just starting to learn
>programming, but is not a good choice for non-novices. ADA has always
>been the DOD's pet language which has never been accepted outside the
>military-industrial complex. Smalltalk hardly deserves a mention.
>
>As a sad result of all that, the jobs for these languages are almost
>nonexistent and the salaries are not that great. I will have to accept
>that I need to forget them in order to make decent money.
>
>That leaves me with the only alternative -- C++ or Java. Both languages
>have been hugely successful DESPITE their design flaws. I am ready to
>accept the necessity to use these languages if that's where the job market
>is headed. Both languages have excellent implementations for both Windows
>and Unix platforms.
>
>The question is, which language will pay top 17457 in the long run? Java is
>still in its infancy but seems to have a great potential. C++ is a mature
>albeit cumbersome language and is probably poised to become a legacy
>language later. The jobs will be there in the long run, although the
>market will likely never be as good as now. What do you think about it?
What I think is that the language "du jour" is not really that
important as is good computer science and software engineering
principals that, _hopefully_ any decent higher education institute
teaches. Where I work at an aerospace/electronics Fortune 100 company,
Fortran is still very much used by "analysts" to solve theoretical
problems that the rest of us "code pounders" translate into embedded
systems code. A clue here, we don't use Java or C++ yet. If you are
working _only_ on Internet commerce or for Microsoft maybe you should
worry a _lot_ about Java or C++. Otherwise you may be surprised. The
employer you really want to work for may use Eiffel, Smalltalk or Ada95
for their important applications. I've heard that Cobal knowledge in
London earns the biggest bucks.
Wow! I trimmed only one newsgroup from this cross-posted monster!
Followups may be able to do better. :-/
_____________________________________________________________________
Robert S. White -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter
Stanley Allen
Mix wrote:
>
> [summary: FORTRAN, Eiffel, Ada and Smalltalk are out of
> the question; Java and C++ are my only career choices]
>
> The question is, which language will pay top 17457 in the long run?
>
Ah, the perilous quandries of graduation! Young men
and women starting out to take their turn in the world,
overwhelmed with solitude, unable to foresee what all
of us can also not forsee: the FUTURE! Like death
to Hamlet it is the "undiscovered country"; its map is
continually accumulating marks and legends, each new
day adding some incremental detail -- but never is
it any more complete than the day before.
Young man (I say magnanimously from the grand age of
thirty-four), your question is fair enough but it's
not answerable in any way. It's also one of the
least interesting questions you could ask to us or
to yourself. Think instead of these questions:
"What was my favorite language(s) to study in my CS classes?"
"What was my favorite course(s) among my CS classes?"
"What was my favorite course(s) outside my major?"
"What do I like to do outside school/work?"
"What do I want to accomplish with my life & time?"
The point is that you're going to waste your life if
all you can think about is the money. Stop brooding
and think of what you're saying: "I don't really *want*
to program in C++ or Java, but I'm stuck with them, so
I will doom myself to a drab career for 10+ years in
order to pick up my fair share of the middle-class
life." If it didn't provoke a chuckle, I might feel
like weeping a bit just thinking about it.
THINK BIG! Choose not to be a pawn in the game -- do
what you *like* to do -- set some real goals for
yourself -- what you want to learn -- what kind of
things you want to be proud of doing as a software
developer -- have some guts -- take on the world and
win, man!
The most depressing thing I can imagine for myself
career-wise is the idea that I will have to hunker
down one day and bow down to that paycheck doing
some ms-windows database interface. I'll sell
vacuum cleaners first.
When I got out of school, my favorite language was Ada
and my favorite work was real-time software and network
programming. Want to take a guess what I've been doing
for the last 10 years? You got it. And it's never been
military-related, though that was an option. Also I've
never been near the bottom of the totem pole on the pay
scale. I expect keep at it for the next 10 years or so.
Don't get me wrong: there were a few things I was into
back then that I knew would be harder to parlay into a
career, like AI. But the point is that I didn't (and
you don't) have to settle for some lowest common
denominator. Assuming you are a reasonably sharp
person, you probably have some real interests within the
field of computers. And some of these real interests
will overlap with real jobs. Find a good match and make
it work for you.
--
Stanley Allen
mailto:sal...@ghg.net
Roedy Green
Why would the programmers be paid substantially more for using a particular
computer language?
1. is it so frustratingly boring that almost no one wants to use it?
2. it is so frustratingly difficult almost no one can use it?
3. the language is well tuned for solving the problems of wealthy companies.
4. because you can't learn the language from off-the-shelf books and with a
home computer or at a college. You need to learn from $1000 a day courses.
5. Nobody's ever heard of the language.
6. There's a shortage of people who know the language relative to the
demand for it.
Roy Smith
In article <34958D...@gsg.eds.com>, nos...@gsg.eds.com wrote:
> The complexity of the syntax involves a lot more than the number of
> keywords.
Can anybody explain to me why this thread is appearing in nyc.food?
Granted, a lot of code probably gets written in coffee shops and diners,
but that hardly makes programing language syntax complexity an appropriate
topic for nyc.food!
steve
Craig A. Johnston wrote:
> COBOL. COBOL pays the most. Get to it, son.
BUT, as to C v. JAVA? JAVA is HYPE! It is NOT available(read runnable) on
every platform, and C IS, for the most part. ALSO, C should compile faster,
and has more support. Many companies(according to the latest computer
magazines) are finding JAVA inadequate, and slow.
For client side processing on the internet, JAVA can't be beat. There is NO
contender. M/S ASP requires more downloads, and just isn't as widely
supported). In every other way, C beats JAVA!
C may pay more, but JAVA IS widely use by internet sites, and commands a
premium.
> --
> Craig A. Johnston <> UNIX/TCP-IP/LAN consulting and custom programming
> c...@autarch.com <> in C/perl/shell. Qmail spoken here.
Yves CONSTANTINIDIS
:-) Maybe our anonymous HACKER is an expert in SPAGHETTI CODE !
Yves
Craig A. Johnston
COBOL. COBOL pays the most. Get to it, son.
--
steve
Gary Howland wrote:
> Craig A. Johnston wrote:
> >
> > COBOL. COBOL pays the most. Get to it, son.
>
> This is not strictly true - MUMPS pays even more than COBOL.
> However, there are more COBOL positions available (but it makes
> no difference, since you'll never find an unemployed MUMPS or COBOL
> programmer).
MUMPS? Better get VAXinated for that one! Sorry, couldn't resist. Old
joke, I know! 8-)
>
>
> Gary
> --
> "I kicked the perl habit, and so can you. Ask and I'll show you how."
>
> pub 1024/C001D00D 1996/01/22 Gary Howland <ga...@hotlava.com>
> Key fingerprint = 0C FB 60 61 4D 3B 24 7D 1C 89 1D BE 1F EE 09 06
Klaus-Georg Adams
ta...@metronet.com (Tad McClellan) writes:
>
> Mark Framness (fram...@EMIRATES.NET.AE) wrote:
> : In message <34958D...@gsg.eds.com> - "Shmuel (Seymour J.) Metz"
> : <nos...@gsg.eds.com>Mon, 15 Dec 1997 12:03:34 -0800 writes:
> : #>
>
> : #>> C provides the needed primitives to do anything you need.
> : #>
> : #>You got this wrong; C does not have the needed primitives to handle
> : #>sets, do string matching, do record-oriented I/O, etc., except in the
> : #>trivial sense that anything can be simultated on anything else.
>
> : What do you mean sets? As in the mathematical sense? String matching? Huh?
> : what do strcmp, strstr etc do?
> ^^^^^^ ^^^^^^
>
> Those are not *primitives* (ie. built-in to the language).
>
> Those are library calls (ie. add-ons to the language).
>
> You won't find 'strcmp' in a C compiler's grammar.
Which is of course completely irrelevant. They are part of the
language definition (as in ANSI Standard).
-- kga
-------------------------------------------------------------------------
Klaus-Georg Adams Email: Klaus-Ge...@chemie.uni-karlsruhe.de
Institut f. Anorg. Chemie II Tel: 0721 608 3485
Uni Karlsruhe
-------------------------------------------------------------------------
Alicia Carla Longstreet
Osvaldo Pinali Doederlein wrote:
> Hi Alicia,
> Alicia Carla Longstreet wrote in message <3494B7...@ici.net>...
Take care on attributes, I did *not* write this list of 'commandments'.
> >> >1. Actual programs must be written in it.
> >> >2. Lots of libraries must be written for it.
> >> >3. Most computer architectures must have a compatible version of it.
> >> >4. Source code must be easily understable (by good coders).
> >> >5. Lots of programmers must know the language in deep.
> >> >6. The syntax must be simple. The semantics must be well defined.
>
> Wow, another ten-commandments list.
> > Number 5, there are a lot of programmers who know C inside and out,
> > probabaly more than any other language (possibly excepting COBOL and
> > FORTRAN). I can name a dozen or more on this forum alone.
> > C is quite understandable to anyone who knows it.
> If you read twenty lines of any C code, you will understand it, no matter
> how badly/well written. Now, try to figure out some complex algorithm, or
> an entire application. When you look at some piece of C code, you read
> something like "*ptr++ = foo()" then you literarily interpret it as "call
> funcion f, store some scalar result in the address pointed by ptr and let
> ptr point to the next position of whatever the buffer". I don't call this
> "understantding" anything at all. You need to read lots of context and
> rebuild your mental interpretation of the code (just like a several-pass
> compiler) in order to finally obtain a high-level, "real" idea of the code.
> The problem with C is not its brackets or terseness or even absence of OO;
> the problem is expressiveness. of course you can write ling-long,
> descriptive variable names (complete with hungarian garbage so you can fake
> types in a language which requires types but doesn't really implement them)
> and LOTS of comments; but then the reader will interpret your documentation,
> not your code.
Comments are part of the source code IMO. Code is not only written for
the computer but for the human reader as well. Insisting that the
compilable part of the source code always be self-documenting is a
unrealistic goal. Most languages that try to be this tend to collapse
from the 'weight' of the source code. People like C, partly because its
terseness makes it easy to type. When properly done, short one page
functions with adaquete comments to explain the purpose of the function
and periodic comments to indicate what the next logical block of code is
supposed to do (commenting loops and conditionals for examples), C code
can be most readable and easily maintained.
I would *much* rather maintain C code than Clipper code! Imagine a
'private' variable that was 'in scope' for *every* function called even
callbacks to higher level functions ARRRRRGGGGGGGG!!!!! I *love* C's
lexical scoping rules.
--
****************************************************************
What is the speed of dark?
When you're sending someone Styrofoam, what do you pack it in?
Why are there Braille signs on drive-up ATM's?
How come you never hear about gruntled employees?
I have an answering machine in my car.
It says "I'm home now.
But leave a message and I'll call when I'm out."
=========================================
Alicia Carla Longstreet ca...@ici.net
=========================================
READ THE FAQ for more information:
C-FAQ ftp sites: ftp://ftp.eskimo.com or ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Alicia Carla Longstreet
Mark Framness wrote:
> Shmuel (Seymour J.) Metz" writes:
> #>> C provides the needed primitives to do anything you need.
> #> You got this wrong; C does not have the needed primitives to handle
> #> sets, do string matching, do record-oriented I/O, etc., except in the
> #> trivial sense that anything can be simultated on anything else.
What you are describing are *not* primitives.
Sets are a high-level construct, in C you define an array and write the
code to manipulate it, in C++ you create a class (which is a feature
filled container for what you do in C).
Strings are also a high level construct. C and C++ do not have string
data types, instead they use Zero terminated character arrays. *That*
is the primitive.
The same goes for Record-oriented I/O, this is a high level construct
*not* a primitive.
There are high level langauges that have these high-level constructs,
but they are built from the same primitives that the C porogrammer
*must* use. In other words, C programmers (and C++ programmers) write
those neat high-level constructs from the low-level primitives
available.
BTW, I recently upgraded to CodeBase 6.3 from Sequiter Software. This
library provides all those nice neat high level constructs for database
programming that you have confused with primitives.
> What do you mean sets? As in the mathematical sense? String matching? Huh?
> what do strcmp, strstr etc do?
Yes strcmp(), strstr(), etc are the high-level constructs built on the
primitives available to manage strings. String handling is the only
real 'high-level' construct that is available in Standard C. For linked
lists, matrices, record I/O, etc. you need to either write your own set
of functions or buy some prewritten functions.
> It seems to me that the first statement is accurate. You just have to do more
> work in C & C++ to do the same things in other languages.
P.S. To those of you in nyc.foods - Sorry but you *won't* see this!
Gary Howland
Craig A. Johnston wrote:
>
> COBOL. COBOL pays the most. Get to it, son.
This is not strictly true - MUMPS pays even more than COBOL.
However, there are more COBOL positions available (but it makes
no difference, since you'll never find an unemployed MUMPS or COBOL
programmer).
Gary
Klaus-Georg Adams
Alicia Carla Longstreet <ca...@ici.net> writes:
>
> Mark Framness wrote:
>
> > Shmuel (Seymour J.) Metz" writes:
>
> > #>> C provides the needed primitives to do anything you need.
>
> > #> You got this wrong; C does not have the needed primitives to handle
> > #> sets, do string matching, do record-oriented I/O, etc., except in the
> > #> trivial sense that anything can be simultated on anything else.
>
> What you are describing are *not* primitives.
> Sets are a high-level construct, in C you define an array and write the
> code to manipulate it, in C++ you create a class (which is a feature
> filled container for what you do in C).
Speaking for C. In ANSI C++ there is a datatype set.
> Strings are also a high level construct. C and C++ do not have string
> data types, instead they use Zero terminated character arrays. *That*
> is the primitive.
Speaking for C. In ANSI C++ there is a datatype string.
> > What do you mean sets? As in the mathematical sense? String matching? Huh?
> > what do strcmp, strstr etc do?
>
> Yes strcmp(), strstr(), etc are the high-level constructs built on the
> primitives available to manage strings. String handling is the only
> real 'high-level' construct that is available in Standard C. For linked
> lists, matrices, record I/O, etc. you need to either write your own set
> of functions or buy some prewritten functions.
>
> > It seems to me that the first statement is accurate. You just have to do more
> > work in C & C++ to do the same things in other languages.
If you scratch the `C++' from the above sentence, I'll agree :-)
Kenny A. Chaffin
In article <34996E...@hotlava.com>, ghow...@hotlava.com says...
> Craig A. Johnston wrote:
> >
> > COBOL. COBOL pays the most. Get to it, son.
>
> This is not strictly true - MUMPS pays even more than COBOL.
> However, there are more COBOL positions available (but it makes
> no difference, since you'll never find an unemployed MUMPS or COBOL
> programmer).
>
> Gary
> --
> "I kicked the perl habit, and so can you. Ask and I'll show you how."
>
> pub 1024/C001D00D 1996/01/22 Gary Howland <ga...@hotlava.com>
<G>
Happy Holidays,
--
KAC
Website Design, Programming, Graphics --> http://www.kacweb.com
Multi-Channel Server-Push Ticker at ----------^^^^^^^^
ke...@kacweb.com
Robert Garskof
Keep your options open, go for both!
--
/**************************************************************\
* Robert Garskof | robert....@snet.com *
* ICAS Development Team | rgar...@cris.com *
* Southern New England Telephone | *
\**************************************************************/
Quowong P Liu
In article <1997121219...@sirius.infonex.com>,
appearing in comp.lang.fortran, Mix <mixm...@remail.obscura.com> writes,
>The question is, which language will pay top 17457 in the long run?
Where the heck does 17457 come from?
Bill Gates is rich. What language does Bill Gates like?
I don't see why anyone who'll be programming professionally
shouldn't be able to pick up the essentials of Fortran(90/95/hpf),
C, C++, Eiffel, Java, Smalltalk, perl, or Ada(95) in short order,
especially with a good grounding in object oriented programming.
(I notice no languages emphasizing functional programming are in
the list.)
William J. Leary Jr.
Quowong P Liu wrote in message <67evu7$9db$1...@geraldo.cc.utexas.edu>...
>Bill Gates is rich. What language does Bill Gates like?
From what he said in the interview I saw (which had to have been a bit
dated, they were talking about Win 3.1 as "current.") the answer is: Basic.
- Bill
Kaz Kylheku
In article <349B0417...@its.cl>,
Guillermo Schwarz <gsch...@its.cl> wrote:
>This is a multi-part message in MIME format.
>--------------EC36FA96B4325E47CB41380A
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>
>Kaz Kylheku wrote:
>
>> In article <e9k976.8h3.ln@localhost>, Tad McClellan <ta...@metronet.com> wrote:
>> >: what do strcmp, strstr etc do?
>> > ^^^^^^ ^^^^^^
>> >
>> >Those are not *primitives* (ie. built-in to the language).
>> >
>> >Those are library calls (ie. add-ons to the language).
>>
>> standard.
>
>The standard C library, but not he standard C language.In the same way, other
>languages have standard libraries.
>Some have huge libraries, as Smalltalk does.
The library is part of the language, you buffoon, the same way that basic
words like 'air' and 'water' are part of English.
In C, the standard library functions have special status. First of all, their
names are reserved external symbols. If any C program contains an external
definition of an identifier that is an external name reserved by the standard
library, the behavior is undefined.
Secondly, if you include a standard header, you may not redeclare any symbol
in that standard header, not even in a nested scope.
>> >You won't find 'strcmp' in a C compiler's grammar.
>>
>> I use a compiler which will inline functions like strcpy() and abs().
>
>It has nothing to do with optimization. The point is that C has no built-in support
>for Strings.
I'm not talking about optimization. I'm talking about recognition of standard
functions as thought they where primitives. The C standard permits an
implementation to do that.
>Even worse, that optimization can be a bug.
>What if I define a class:
Doh! You can't define a class in C.
>class foo()
>{
>public:
> char * strcmp( char * a, char * b ) { ... }
> void bar()
> {
> ...
> strcmp( a, b );
> ...
> }
>};
>
>I wouldn't expect the compiler to "optimize" my code.
The above is C++, not C. It defines strcmp as a member function of class foo.
It cannot possibly be mistaken for the strcmp in <string.h>. It's full
name is foo::strcmp. It also has a different type signature.
Do you have any clue how compilers work? The name strcmp will be looked up
in a symbol table for the current scope. The compiler will recognize
that it belongs to the class scope foo:: so that it cannot possibly be
the standard function.
In C, it's like this: a strictly conforming program may not define its own
strcmp() function with external linkage. If you want to write your own strcmp,
you would have to give it internal linkage using the static keyword: static
int strcmp(...) { ... }. You are then forbidden from including the <string.h>
header in that translation unit. The compiler is then required to recognize
that you have defined your own strcmp and no longer treat it as a built-in
primitive.
It works just fine in GCC, for instance.
[ nyc.foods, misc.jobs.* trimmed from header ]
William J. Leary Jr.
Kaz Kylheku wrote in message <67gvpa$m3t$1...@brie.direct.ca>...
>The library is part of the language, you buffoon, the same way that basic
>words like 'air' and 'water' are part of English.
Not that I've ever noticed. I frequently use C compilers to target embedded
systems. We pretty much always discard the standard library and bring up
our own basic library for the features we actually need. The standard
library pretty much is always hooked into the OS (or OS's) the compiler is
targeting. Since we're usually either on the iron, or on an RTOS the
standard stuff the standard library want's isn't usuall there.
>In C, the standard library functions have special status.
> First of all, their names are reserved external symbols.
Not usually. Their "special status" comes from the fact that they get put
into the symbol table because you always include "stdio.h" or "stdlib.h" or
whatever. In some cases a compiler will pay special attention to some of
the routines (like strcpy) so it can inline them
automagically. In all cases where I've seen this there's been a compiler
switch to turn it off.
I've dumped the standard library lots of times and written new routines for
some of the standard features and never had a compiler or linker complain
about them.
> If any C program contains an external definition of an identifier that is
an external name
> reserved by the standard library, the behavior is undefined.
If you link in the standard library, you usually get a linker error, unless
the linker isn't too bright. If you don't link in the library, it usually
just works as expected. That is, your routine which replaced, say, fputc,
just gets linked in.
>Secondly, if you include a standard header, you may not redeclare any
symbol
>in that standard header, not even in a nested scope.
Done it several times. Program started in DOS, so I needed the standard
libs for progress messages. Switched to protected mode in high memory and
zapped DOS in low RAM for buffers. Used my own fputc and so forth after
that.
> I'm not talking about optimization. I'm talking about recognition of
standard
> functions as thought they where primitives. The C standard permits an
> implementation to do that.
Yep, some compilers will do that. Metaware, for example, will catch memcpy
and optimize it for the 80x86 REPT modifier. It can be turned off with a
compile time switch, because it's NOT part of the C langauge but rather is
the compiler maker noticing a chance to get you better executing code by
implementing one of the standard library functions as if it were a language
primitave.
> ((.. omitted..))
> In C, it's like this: a strictly conforming program may not define its own
> strcmp() function with external linkage. If you want to write your own
strcmp,
> you would have to give it internal linkage using the static keyword:
static
> int strcmp(...) { ... }. You are then forbidden from including the
<string.h>
> header in that translation unit. The compiler is then required to
recognize
> that you have defined your own strcmp and no longer treat it as a built-in
> primitive.
>
>It works just fine in GCC, for instance.
I just realized here that you guys may be discussing two different things.
It sounds like one of you is arguing about the C language itself, and the
other is arguing about what makes up a standard C program. The library
isn't part of the language. Look at the syntax diagrams for the language.
There's no library features in there. On the other hand, a standard C
program, one which is in compliance with the specs, does include that
library stuff.
- Bill
Kurt Watzka
"William J. Leary Jr." <Bill_...@msn.com> writes:
> Kaz Kylheku wrote in message <67gvpa$m3t$1...@brie.direct.ca>...
>>The library is part of the language, you buffoon, the same way that basic
>>words like 'air' and 'water' are part of English.
>Not that I've ever noticed. I frequently use C compilers to target embedded
>systems. We pretty much always discard the standard library and bring up
>our own basic library for the features we actually need. The standard
>library pretty much is always hooked into the OS (or OS's) the compiler is
>targeting. Since we're usually either on the iron, or on an RTOS the
>standard stuff the standard library want's isn't usuall there.
What Kaz Kylheku is missing is the word "hosted environement". He knows
quite well that in a hosted environment, all the functions, macros,
type definitions, and objects described in the library clause may
be used, whereas in a freestanding environment (for example, an implementation
targeting your average toaster), and libary facilities available to
a program are implementation-defined.
>>In C, the standard library functions have special status.
>> First of all, their names are reserved external symbols.
>Not usually. Their "special status" comes from the fact that they get put
>into the symbol table because you always include "stdio.h" or "stdlib.h" or
>whatever.
Not so. The names are reserved in a hosted environment no matter what
headers are included. This is what Kaz was trying to tell you.
"All identifiers with external linkage in any of the following (i.e
the library) subclauses including the future library directions
are always reserved for use as identifiers with external linkage"
cannot be interpreted in a way that restricts the reservation to
compilation units that include certain standard headers.
> In some cases a compiler will pay special attention to some of
>the routines (like strcpy) so it can inline them
>automagically.
I doubt that it is allowed to do so in a freestanding environenment
without explicitly stating that fact in its documentation.
> In all cases where I've seen this there's been a compiler
>switch to turn it off.
Again, the point is the difference between a freestanding environement
and a hosted environment. In a freestanding environment, the name and
type of the function called at program startup are implementation defined.
It may well be "void ToasterStart(float TimerSetting)". There are otherwise
no reserved external identifiers in a freestanding environment. This means
that you are indeed free to use names in your toaster control program
that would be reserved identifiers in a program targeting a hosted
environment.
>I've dumped the standard library lots of times and written new routines for
>some of the standard features and never had a compiler or linker complain
>about them.
>> If any C program contains an external definition of an identifier that is
>an external name
>> reserved by the standard library, the behavior is undefined.
This means that neither the compiler nor the linker is obliged in any
way to complain about the redefinition of functions from the standard
library, but the behaviour of such a program is still undefined. "It
worked so far" is a _very_ weak proof of correctness, given that
undefined behaviour may well be limited to Thursdays before Friday
the 13th in odd years.
>If you link in the standard library, you usually get a linker error, unless
>the linker isn't too bright. If you don't link in the library, it usually
>just works as expected. That is, your routine which replaced, say, fputc,
>just gets linked in.
This need not be true in a hosted environment. The compiler may well
inline calls to fputc(), or generate calls to __libc_term_FPUTC instead.
>>Secondly, if you include a standard header, you may not redeclare any
>symbol
>>in that standard header, not even in a nested scope.
>Done it several times. Program started in DOS, so I needed the standard
>libs for progress messages. Switched to protected mode in high memory and
>zapped DOS in low RAM for buffers. Used my own fputc and so forth after
>that.
You wouldn't mind telling us which companies use or sell your products,
would you?
>> I'm not talking about optimization. I'm talking about recognition of
>standard
>> functions as thought they where primitives. The C standard permits an
>> implementation to do that.
>Yep, some compilers will do that. Metaware, for example, will catch memcpy
>and optimize it for the 80x86 REPT modifier. It can be turned off with a
>compile time switch, because it's NOT part of the C langauge but rather is
>the compiler maker noticing a chance to get you better executing code by
>implementing one of the standard library functions as if it were a language
>primitave.
The possibility that the definition of the C programming language indeed
does permit what Kaz claims it to permit does obviously escape you. An
implementation of the C programming language is free to recognize calls
to functions from the standard C library as special cases and treat them
in a special way. If you think that this is not so, don't try to prove
your point with statements like "I tried it once and it looked as if it
worked on the implementation I was using at that time". Try to find some
text in the language definition that supports your point of view.
Kurt
--
| Kurt Watzka Phone : +49-89-2178-2781
| wat...@stat.uni-muenchen.de
James Giles
Person one writes freestanding C code and claims that, because
he can turn them off, the library and other features of a hosted
C implementation are not part of the language. Person two
claims (correctly) that they *are* part of the language and that
by disconnecting them and writing your own you are violating the
standard (which is not correct). Person three correctly describes
the difference between a hosted and a freestanding C implementation,
but aims his criticism and person one, when he was just as right - and
just as wrong -as person two. All these people are right, and all these
people are wrong, to some extent or other. In any case, none of
this has anything to do with comp.lang.(fortran, eiffel, smalltalk, or
ada) and I have removed all those from the distribution list. I'd
remove java too, but its name is in the title.
--
J. Giles
Ricercar Software
William J. Leary Jr.
>Kurt Watzka wrote in message <67hg7m$g9f$1...@sparcserver.lrz-muenchen.de>...
>>"William J. Leary Jr." <Bill_...@msn.com> writes:
>>> Kaz Kylheku wrote in message <67gvpa$m3t$1...@brie.direct.ca>...
--- ((..omitted..))
>What Kaz Kylheku is missing is the word "hosted environement".
Yes, very good. THAT makes a lot of sense, and I've seen that myself.
Still, that's the environment, not the langauge specification for C.
--- ((..omitted..))
>>Not usually. Their "special status" comes from the fact that they get put
>>into the symbol table because you always include "stdio.h" or "stdlib.h"
or
>>whatever.
>
> Not so. The names are reserved in a hosted environment no matter what
> headers are included.
Again, I agree. The environment might well require that. The language
spec. doesn't.
> This is what Kaz was trying to tell you.
Not me. he was writing to someone else.
> "All identifiers with external linkage in any of the following (i.e
> the library) subclauses including the future library directions
> are always reserved for use as identifiers with external linkage"
> cannot be interpreted in a way that restricts the reservation to
> compilation units that include certain standard headers.
Yep, no disagreement. But we seem to be getting rather far afield of the
argument I was commenting on, which *appeared* to be that the C language
_itself_ included the standard library.
>> In some cases a compiler will pay special attention to some of
>>the routines (like strcpy) so it can inline them
>>automagically.
>
>I doubt that it is allowed to do so in a freestanding environenment
>without explicitly stating that fact in its documentation.
Yes. The one I used (Metaware) and reviewed (Orin? Ordin? I'm not sure...
years ago) both had notes in their compiler switches section about these
features. Metaware also included it in the debugging section, since it was
impossible to set a breakpoint on, say, strcpy if it was inlined.
>> In all cases where I've seen this there's been a compiler
>> switch to turn it off.
>
>Again, the point is the difference between a freestanding environement
>and a hosted environment.
I absolutely agree with you. However, the thread of conversation I reviewed
didn't seem to be talking about operation under an environment. It seemed
to be a discussion about the basic C language and it's supposed inclusion of
the standard library as part of that language.
> In a freestanding environment, the name and type of the function called at
program
> startup are implementation defined. It may well be "void
ToasterStart(float
> TimerSetting)". There are otherwise no reserved external identifiers in a
freestanding
> environment. This means that you are indeed free to use names in your
toaster control
> program that would be reserved identifiers in a program targeting a
hosted
> environment.
Agreed again.
>> I've dumped the standard library lots of times and written new routines
for
>> some of the standard features and never had a compiler or linker complain
>> about them.
>
>>> If any C program contains an external definition of an identifier that
is
>>> an external name reserved by the standard library, the behavior is
undefined.
>
> This means that neither the compiler nor the linker is obliged in any
> way to complain about the redefinition of functions from the standard
> library, but the behaviour of such a program is still undefined. "It
> worked so far" is a _very_ weak proof of correctness, given that
> undefined behaviour may well be limited to Thursdays before Friday
> the 13th in odd years.
No disagreement here either.
>> If you link in the standard library, you usually get a linker error,
unless
>> the linker isn't too bright. If you don't link in the library, it
usually
>> just works as expected. That is, your routine which replaced, say,
fputc,
>> just gets linked in.
>
>This need not be true in a hosted environment. The compiler may well
>inline calls to fputc(), or generate calls to __libc_term_FPUTC instead.
It might well inline the function, but inlining is a performance issue.
It's not supposed to break the integrity of the program in doing so. On the
other hand, I don't disagree with you or him here. If the compiler writer
has chosen to make such things primative AND doesn't pass on the symbols for
the inlined to the linker, so they can be caught if re-used incorrectly,
then of course it's undefined.
>>> Secondly, if you include a standard header, you may not redeclare any
>>> symbol in that standard header, not even in a nested scope.
>
>>Done it several times. Program started in DOS, so I needed the standard
>>libs for progress messages. Switched to protected mode in high memory and
>>zapped DOS in low RAM for buffers. Used my own fputc and so forth after
>>that.
>
>You wouldn't mind telling us which companies use or sell your products,
>would you?
The Bytex Series 7700 Token Ring / Ethernet Programmable Hub.
Long before the product got to market we'd eliminated the DOS stage and
booted directly into protected mode from a modified BIOS, but the initial
system did indeed work this way.
The other I'm not at liberty to discuss due to non-disclosure agreements.
>>> I'm not talking about optimization. I'm talking about recognition of
standard
>>> functions as thought they where primitives. The C standard permits an
>>> implementation to do that.
>
>> Yep, some compilers will do that. Metaware, for example, will catch
memcpy
>> and optimize it for the 80x86 REPT modifier. It can be turned off with a
>> compile time switch, because it's NOT part of the C langauge but rather
is
>> the compiler maker noticing a chance to get you better executing code by
>> implementing one of the standard library functions as if it were a
language
>> primitave.
>
> The possibility that the definition of the C programming language indeed
> does permit what Kaz claims it to permit does obviously escape you.
Not at all. I've read the ANSI C spec and it clearly leave a lot of leeway
about how things are implemented. I agreed.
> An implementation of the C programming language is free to recognize calls
> to functions from the standard C library as special cases and treat them
in a
> special way.
Yep. I agreed with that. No argument at all. In fact, I provided an
example of an compiler I'd used which did just that.
> If you think that this is not so, don't try to prove your point with
statements like "I tried
> it once and it looked as if it worked on the implementation I was using at
that time".
I didn't. I pointed out how one specific implementation (Metaware) had both
done the optimization route AND complied with the language spec by providing
a switch to turn off the inlines.
> Try to find some text in the language definition that supports your point
of view.
Supports it how?
My point of view is that the C _language_ does not include the C
_standard_library_ functions as part of the _language_. A particular C
programming environment may well do something other than this, and that's
their option.
I don't see what it is I'm supposed to use to support my point of view,
unless you'd like me to quote the entire language and end up saying "no
standard library primitives found herein."
For that matter, whether you'd like me to do that or not, perhaps you can
point me to a place on the net where the ANSI C spec is available. I've
just done a search and I've found the ANSI C++ spec, but can't find the ANSI
C spec. The one I had belonged to my former employer and I had to leave it
there when I left the company.
- Bill
Peter Seebach
In article <ObfZp4Y...@upnetnews02.moswest.msn.net>,
William J. Leary Jr. <Bill_...@msn.com> wrote:
>Not that I've ever noticed. I frequently use C compilers to target embedded
>systems.
Then you're using "freestanding environments", which are a separate language.
The library is, indeed, part of the hosted environment form of C.
-s
--
se...@plethora.net -- I am not speaking for my employer. Copyright '97
All rights reserved. This was not sent by my cat. C and Unix wizard -
send mail for help, or send money for a consultation. Visit my new ISP
<URL:http://www.plethora.net/> --- More Net, Less Spam! Plethora . Net
Peter Seebach
In article <#vJ8k2aD9GA.169@upnetnews03>,
William J. Leary Jr. <Bill_...@msn.com> wrote:
>Yes, very good. THAT makes a lot of sense, and I've seen that myself.
>Still, that's the environment, not the langauge specification for C.
Except that it is in the language specification for C; C defines what
a hosted environment is, including the entire library, and, in a hosted
environment, there is no reason at all to assume that you can replace or
affect the standard library in any way, however trivial.
Note followups.
William J. Leary Jr.
Peter Seebach wrote in message <67iipp$ktj$1...@darla.visi.com>...
>Then you're using "freestanding environments", which are a separate
language.
>The library is, indeed, part of the hosted environment form of C.
As I've said in several other messages which have forked off this main one,
it was my understanding that the argument was over the LANGUAGE, not the
ENVIRONMENT.
The language spec (the part that says 'if means this, = means this, ++ means
this and so on) doesn't include that standard library jazz or specify that
things like "memcpy" are reserved words. The reserved words there are
things like "if," "for," "switch" and so forth. In that spec you won't find
"memcpy" along with "switch" as a reserved word.
The hosted environment may well do so.
The compilers I used (Metaware, Microsoft C/C++, and a few others we
evaluated but didn't use for production work) all did just what you say. If
we targeted DOS or UNIX or what have you, there were definite limitations on
what we could do. If we target nothing (or embedded, or whatever option the
compiler required) we could use any name we felt like for any purpose
whatever.
- Bill
David Grove
I should point out that these languages pay more because it's hard to
find people who would stoop so low as to work with them. :)
>Craig A. Johnston wrote:
>>
>> COBOL. COBOL pays the most. Get to it, son.
>
>This is not strictly true - MUMPS pays even more than COBOL.
>However, there are more COBOL positions available (but it makes
>no difference, since you'll never find an unemployed MUMPS or COBOL
>programmer).
>
>Gary
>--
>"I kicked the perl habit, and so can you. Ask and I'll show you how."
>
>pub 1024/C001D00D 1996/01/22 Gary Howland <ga...@hotlava.com>
steve
David Grove wrote:
> I should point out that these languages pay more because it's hard to
> find people who would stoop so low as to work with them. :)
>
> >Craig A. Johnston wrote:
> >>
> >> COBOL. COBOL pays the most. Get to it, son.
> >
Some people programming PB,VB,VC,C,C++ make a LOT more than the average
COBOL programmer, and some make less!
Lawrence Kirby
In article <67iipp$ktj$1...@darla.visi.com>
se...@plethora.net "Peter Seebach" writes:
>In article <ObfZp4Y...@upnetnews02.moswest.msn.net>,
>William J. Leary Jr. <Bill_...@msn.com> wrote:
>>Not that I've ever noticed. I frequently use C compilers to target embedded
>>systems.
>
>Then you're using "freestanding environments", which are a separate language.
>The library is, indeed, part of the hosted environment form of C.
Aren't the standard library identifiers with external linkage reserved
even in a freestandinhg environment?
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Kaz Kylheku
In article <67hhva$g...@bgtnsc02.worldnet.att.net>,
James Giles <james...@worldnet.att.net> wrote:
>Person one writes freestanding C code and claims that, because
>he can turn them off, the library and other features of a hosted
>C implementation are not part of the language. Person two
>claims (correctly) that they *are* part of the language and that
>by disconnecting them and writing your own you are violating the
>standard (which is not correct). Person three correctly describes
>the difference between a hosted and a freestanding C implementation,
>but aims his criticism and person one, when he was just as right - and
>just as wrong -as person two. All these people are right, and all these
>people are wrong, to some extent or other. In any case, none of
Note that a freestanding implementation is not fully governed by the C
standard. A freestanding C program may begin with a function other than main.
It can use all kinds of non-standard library functions and features. The C
standard provides an interpretation for hosted C programs; it says little
about freestanding implementations.
If I recall correctly, the Rationale says that this is because little is
achieved by constraining freestanding implementations.
host
Kaz Kylheku
In article <882756...@genesis.demon.co.uk>,
Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
>In article <67iipp$ktj$1...@darla.visi.com>
> se...@plethora.net "Peter Seebach" writes:
>
>>In article <ObfZp4Y...@upnetnews02.moswest.msn.net>,
>>William J. Leary Jr. <Bill_...@msn.com> wrote:
>>>Not that I've ever noticed. I frequently use C compilers to target embedded
>>>systems.
>>
>>Then you're using "freestanding environments", which are a separate language.
>>The library is, indeed, part of the hosted environment form of C.
>
>Aren't the standard library identifiers with external linkage reserved
>even in a freestandinhg environment?
Yes they are! Absolutely! A freestanding implementation of C is allowed
to provide as much or as little of the standard library.
In any case, the C standard does not define any notion of a ``freestanding
program''. In particular, it provides no interpretation for the meaning
of such programs.
For instance, a ``freestanding program'' might begin execution in a function
called 'init'. But the C standard only provides an interpretation for programs
that start in a function 'main' that returns int and takes either no arguments
or exactly two arguments of type int and char ** respectively.
A conforming implementation of C could well reject a program whose
startup function is called init.
Strictly speaking, such freestanding programs are not standard C; they are
examples of a local adaptation of C.
Kurt Watzka
fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
>In article <67iipp$ktj$1...@darla.visi.com>
> se...@plethora.net "Peter Seebach" writes:
>>In article <ObfZp4Y...@upnetnews02.moswest.msn.net>,
>>William J. Leary Jr. <Bill_...@msn.com> wrote:
>>>Not that I've ever noticed. I frequently use C compilers to target embedded
>>>systems.
>>
>>Then you're using "freestanding environments", which are a separate language.
>>The library is, indeed, part of the hosted environment form of C.
>Aren't the standard library identifiers with external linkage reserved
>even in a freestandinhg environment?
How about "In a freestanding environment the name and type of the function
called at program startup are implementation-defined. There are otherwise
no reserved external identifiers". I read that as excluding the reservation
of external identifiers defined in the library clause in a freestanding
environment. What am I missing?
Billy Chambless
In article <349d7218...@news.ntslink.net>, dgr...@ntslink.net (David Grove) writes:
|> I should point out that these languages pay more because it's hard to
|> find people who would stoop so low as to work with them. :)
|> >Craig A. Johnston wrote:
|> >> COBOL. COBOL pays the most. Get to it, son.
|> >This is not strictly true - MUMPS pays even more than COBOL.
|> >However, there are more COBOL positions available (but it makes
|> >no difference, since you'll never find an unemployed MUMPS or COBOL
|> >programmer).
clueless kids argue
which language is the best one
show me the money
Java, C or Perl
TK/tcl or scripts
show me the money
Ada or c plus plus
FORTRAN or even COBOL
show me the money
Financial reward:
sexier than aesthetics
show me the money.
Peter Seebach
In article <e8Hnv5nD9GA.93@upnetnews04>,
>it was my understanding that the argument was over the LANGUAGE, not the
>ENVIRONMENT.
There are two languages. "printf" is as much a part of the C language
as "++" is. Yes, there's a form of the C language in which there may or
may not be any printf - but in that form, you don't even know where
programs start, so we don't care much.
>The language spec (the part that says 'if means this, = means this, ++ means
>this and so on) doesn't include that standard library jazz or specify that
>things like "memcpy" are reserved words. The reserved words there are
>things like "if," "for," "switch" and so forth. In that spec you won't find
>"memcpy" along with "switch" as a reserved word.
No, you find it in a different section, because it is a different *kind*
of reserved word. (For instance, it is reserved only as an identifier
with external linkage, when reserved at all, or possibly also as a macro
in some cases.)
>The compilers I used (Metaware, Microsoft C/C++, and a few others we
>evaluated but didn't use for production work) all did just what you say. If
>we targeted DOS or UNIX or what have you, there were definite limitations on
>what we could do. If we target nothing (or embedded, or whatever option the
>compiler required) we could use any name we felt like for any purpose
>whatever.
True - they were compiling a different language. The C spec provides
for two very different things, both called C.
Roger Caffin
David Grove <dgr...@ntslink.net> wrote in article
<349d7218...@news.ntslink.net>...
> I should point out that these languages pay more because it's hard to
| > find people who would stoop so low as to work with them. :)
| > >Craig A. Johnston wrote:
| > >> COBOL. COBOL pays the most. Get to it, son.
| > >This is not strictly true - MUMPS pays even more than COBOL.
| > >However, there are more COBOL positions available (but it makes
| > >no difference, since you'll never find an unemployed MUMPS or COBOL
| > >programmer).
|
non-Fortran-related thread.
Cheers for Xmas all.
Roger
--
Roger Caffin (Dr)
Director
Berrilee Consulting Services P/L
5 Charltons Ck Rd
Berrilee NSW 2159
Australia
All the usual disclaimers apply....
Remove obvious antispam Xs from signature
Tim Oxler
steve <st...@seasoned-software.com> wrote:
>
>David Grove wrote:
>
>> I should point out that these languages pay more because it's hard to
>> find people who would stoop so low as to work with them. :)
>>
>> >Craig A. Johnston wrote:
>> >>
>> >> COBOL. COBOL pays the most. Get to it, son.
>> >
>
>Some people programming PB,VB,VC,C,C++ make a LOT more than the average
>COBOL programmer, and some make less!
>
Some COBOL programmers are competent, some aren't. Some
PB,VB,VC,C,C++ programmers are competent, some aren't.
Rates are very important, but so are hours. $100/hr is great, but if
you only bill 500 hours for the year, the fact is, you're making the
same money as the guy with steady work at $25/hr.
Personally, most of my work is in COBOL, and I haven't billed under
2000 hrs since 1985 (my first year in consulting).
This year will be in the 2300 hr range, and that doesn't include the
two other people I have working for me. None of it is Y2k, and almost
all of it is new development.
Tim Oxler
TEO Computer Technologies Inc.
http://www.i1.net/~troxler
http://users.aol.com/TEOcorp
John Porter
Lawrence Kirby wrote:
>
> Aren't the standard library identifiers with external linkage reserved
> even in a freestandinhg environment?
With the possible exception of environments for embedded development,
the identifiers defined in the standard or any other library are not
reserved words. If I don't include string.h, I am free to use the
id 'memcpy' for my own purposes. Even if I do link with a library which
defines memcpy, my definition overrides it. I'm not sure how you can
construe this to mean that 'memcpy' is in any way "reserved".
John Porter
jpo...@logicon.com
Kaz Kylheku
In article <34A14C...@min.net>, John Porter <jdpo...@min.net> wrote:
>Lawrence Kirby wrote:
>>
>> Aren't the standard library identifiers with external linkage reserved
>> even in a freestandinhg environment?
>
>With the possible exception of environments for embedded development,
>the identifiers defined in the standard or any other library are not
>reserved words. If I don't include string.h, I am free to use the
>id 'memcpy' for my own purposes. Even if I do link with a library which
False. Although 'memcpy' is not a reserved keyword by any means,
it is a reserved 'external name'. External names defined by the C library are
reserved as external names regardless of what header you include.
(An external name is an identifier with external linkage).
Not only are those names reserved, but certain external name SPACES are
reserved! A strictly conforming program may not define any external
name that begins with 'mem' followed by any combination of letters,
digits or underscores. This is true even though the library doesn't
currently define anything else in that category other than 'memcpy'
or 'memmove'. However, 'mem' itself is not reserved because it's
not followed by any letters, digits or underscores. Similarly,
identifiers beginning with 'to' and 'is' are reserved for future
extensions to <ctype.h>, and identifiers starting 'str' are reserved
for future extensions to <string.h>.
I have set up my Vim 5.0 editor to colorize any occurence of an identifier
that belongs to the forbidden name spaces. :)
>defines memcpy, my definition overrides it. I'm not sure how you can
>construe this to mean that 'memcpy' is in any way "reserved".
You are sadly mistaken. In fact your overriding definition must have static
linkage, otherwise your program invokes undefined behavior. Moreover, if you
write such a static function, you must not include the <string.h> header in
the same translation unit, else undefined behavior results.
There is no such thing as ``overriding'' in C. Each external name must
have exactly one definition if it is used anywhere in the program.
Additionally, an external name that is declared but never referenced, is
permitted to be without an external definition.
Overriding of library functions (via ``weak symbols'' or some other such
resolution mechanism) is possible as a system-specific extension.
How I can construe all this is by interpreting the fine words written
in a document entitled _American National Standard for Programming
Languages---C_, ANSI/ISO 9899:1990.
John Porter
Klaus-Georg Adams wrote:
> ...
> Speaking for C. In ANSI C++ there is a datatype set.
>
> > Strings are also a high level construct. C and C++ do not have string
> > data types, instead they use Zero terminated character arrays. *That*
> > is the primitive.
>
> Speaking for C. In ANSI C++ there is a datatype string.
>
May I gently point out that the discussion is whether the language
features
under discussion are *primitives* within the language, or are
constructed
features, built up from other features.
Set and String are in no way primitives -- at least not at the present
time,
and I personally doubt they will ever be.
John Porter
jpo...@logicon.com
Kurt Watzka
John Porter <jdpo...@min.net> writes:
>Lawrence Kirby wrote:
>>
>> Aren't the standard library identifiers with external linkage reserved
>> even in a freestandinhg environment?
>With the possible exception of environments for embedded development,
>the identifiers defined in the standard or any other library are not
>reserved words.
Would you mind telling the ISO about this observation of yours, so
that the language definition can be adapted to your views? They erronously
claim the identifiers of functions defined in the library clause as
reserved words for identifiers with external linkage.
>If I don't include string.h, I am free to use the
>id 'memcpy' for my own purposes.
No, since memcpy is not listed as an identifier with file scope. Only
for identifiers with file scope that do _not_ have external linkage
the reservation is limited to compilation units that include one of
the associated headers.
Even if I do link with a library which
>defines memcpy, my definition overrides it.
No, the behaviour of such a program is undefined. I see no other possible
interpretation of "If the program declares or defines an identifier with
the same name as an identifier reserved in that context (*) the behaviour
is undefined.
(*) denotes a cross reference that says: Provided that a library function
can be declared without reference to any type defined in a header, it is
also permissible to declare the function, either explicitly or implicitly,
and use it without including its associated header.
I'm not sure how you can
>construe this to mean that 'memcpy' is in any way "reserved".
I'm not sure how you can think that it is not reserved after reading this
thread. The question is whether it is reserved in a freestanding environment,
and the answer from the language definition is "no, it is not", as far as
I understand the language definition. In a hosted environment, it is
reserved through rather explicit verbiage in the language definition,
and the behaviour of programs using reserved identifiers in a context
in which they are reserved, is _explicitly declared undefined.
Guillermo Schwarz
Kaz Kylheku wrote:
> Although 'memcpy' is not a reserved keyword by any means,
> it is a reserved 'external name'.
> A strictly conforming program may not define any external
> name that begins with 'mem' followed by any combination of letters,
> digits or underscores.
It does.
> Define memcpy, if you write such a static function, you must not
> the same translation unit, else undefined behavior results.
The executable can't be generated.
> There is no such thing as ``overriding'' in C. Each external name must
> have exactly one definition if it is used anywhere in the program.
wannabe.
Patricia Shanahan
Guillermo Schwarz wrote:
>
> Kaz Kylheku wrote:
> > Although 'memcpy' is not a reserved keyword by any means,
> > it is a reserved 'external name'.
> It is the first time I see reserved external.
> > A strictly conforming program may not define any external
> > name that begins with 'mem' followed by any combination of letters,
> > digits or underscores.
> Ok. Define void memfoo() { } and see if it compiles.
> It does.
What does this have to do with the question of whether it is a
"strictly conforming program"? Surely that can be resolved only by
reference to the language standard. There is no certainty that the set
of programs accepted by a particular compiler exactly corresponds to
the set of strictly conforming programs.
> > Define memcpy, if you write such a static function, you must not
> > include the <string.h> header in
> > the same translation unit, else undefined behavior results.
> Wrong. The compiler points out two different implementations.
> The executable can't be generated.
> > There is no such thing as ``overriding'' in C. Each external name must
> > have exactly one definition if it is used anywhere in the program.
> That's true. C is not object oriented. C++ is just an Smalltalk
> wannabe.
This thread contains a lot of cross-purposes discussion, because some
participants are apparently using what the standard says as their
definition of C, while others are apparently using K&R or what the
compilers they use currently accept. For terms like "strictly
conforming program" I think the language standard is the only
reasonable basis. For other issues, common practice or K&R may be
appropriate, but please first discuss which basis should be used,
rather than diving straight into specific issues that may give
different answers.
Patricia
Joshua Waxman
On Sat, 27 Dec 1997, Guillermo Schwarz wrote:
> Kaz Kylheku wrote:
> > Although 'memcpy' is not a reserved keyword by any means,
> > it is a reserved 'external name'.
> It is the first time I see reserved external.
> > A strictly conforming program may not define any external
> > name that begins with 'mem' followed by any combination of letters,
> > digits or underscores.
> Ok. Define void memfoo() { } and see if it compiles.
> It does.
> > Define memcpy, if you write such a static function, you must not
> > include the <string.h> header in
> > the same translation unit, else undefined behavior results.
> Wrong. The compiler points out two different implementations.
> The executable can't be generated.
A few weeks ago, someone learning from Stroustrup's book asked a question
about versions of strlen and strcat and strcpy that he had written. He
included string.h, and a buch of people pointed out that he shouldn't
have, and that they were surprisd that the code compiled. I took that code
and put it into Borland C++ 5.02, and it indeed compikled. The executable
was generated.
Josh Waxman
Robert Dewar
G Shwarz replies to Kaz:
<<> A strictly conforming program may not define any external
> name that begins with 'mem' followed by any combination of letters,
> digits or underscores.
Ok. Define void memfoo() { } and see if it compiles.
It does.
>>
It is perhaps one of the most common serious misconceptions about what
language definitions mean to write a reply like this:
A standard specifies what strictly conforming programs do. The fact that
you can observe xyz behavior from a compiler when given a non-conforming
program is perhaps interesting, but has nothing whatsoever to do with the
standard.
I think this inability to understand the fundamental distinction between
the set of things that a standard defines, and the set of behaviors seen
experimentally from a given implementaqtion, is one of the most common
serious lapses of knowledge among programmers. Note that this understanding
must precede the realization that you cannot write correct programs in a
given language without knowing the standard for that language well. It always
amazes me how badly many C programmers are acquainted with the standard.
Many C programmers have never even *seen* the standard, let alone studied it
carefully to know exactly what it says.
People often argue over the relative merits of languages from a portability
point of view. While it is true that there are some important technical
differences (e.g. dealing with varying size of integer types in C and Ada),
these technical differences are often swamped in practice by the differences
in level of knowledge of the standard defining document, and very often
"portability" problems are just bugs where clearly non-conforming code has
been written.
OK, so your compiler can compile memfoo without compiling. Wunderbar! But
that does NOT mean that you can actually go ahead and call a routine memfoo
if the standard forbids it. To do so would be incompetent programming.
Charles F Hankel
Just to add to this debate, I had to look into the winsock.h file on
my PC the other day and the first glance showed why COBOL is so much
more easy to maintain. Anyone with a grain of sense would prefer the
sheer readability of COBOL to the mess that I saw.
Charles F Hankel
------------------------------------------------------------------
COBOLs: IBM D, E, F, ANS v4, VS, COBOL 2, LE/370, AIX, S/38, OS/2,
PC/MS-DOS, Honeywell GCOS, Burroughs 7000, Tandem, HP3000
all to varying degrees over the past 25 years or so.
Skip Sailors
Except the guy who had to write it in the first place :)
Michael C. Kasten
Charles F Hankel wrote:
>
> Just to add to this debate, I had to look into the winsock.h file on
> my PC the other day and the first glance showed why COBOL is so much
> more easy to maintain. Anyone with a grain of sense would prefer the
> sheer readability of COBOL to the mess that I saw.
In all fairness, header files like winsock.h are typically not
intended much for human consumption -- so readability is a minor
consideration. They are mainly targeted at the compiler, to declare
global variables, function prototypes, and macros. They may be
cluttered with directives for conditional compilation to accommodate
different environments. COBOL has nothing comparable.
A fairer comparison would be COBOL vs. winsock.c, or whatever other
procedural code #includes winsock.h.
(It is also possible that winsock.h in particular is badly written,
but that's not the fault of the language as such.)
Michael C. Kasten mc...@swbell.net
http://home.swbell.net/mck9/cobol/cobol.html
Kurt Watzka
Guillermo Schwarz <gsch...@netup.cl> writes:
>Kaz Kylheku wrote:
>> Although 'memcpy' is not a reserved keyword by any means,
>> it is a reserved 'external name'.
>It is the first time I see reserved external.
Well, looks as if there still is something to learn about C for you.
The exact wording is "are reserved as identifiers with external
linkage", but "reserved external name" looks close enough to me.
>> A strictly conforming program may not define any external
>> name that begins with 'mem' followed by any combination of letters,
>> digits or underscores.
>Ok. Define void memfoo() { } and see if it compiles.
>It does.
The behaviour of a program that declares or defines an identifier with
the same name as an identifier reserved in that context is undefined.
Undefined behaviour means: "No diagnostic required, and whatever the
implementor chooses to do is correct behaviour as far as the definition
of the C programming language is concerned".
>> Define memcpy, if you write such a static function, you must not
>> include the <string.h> header in
>> the same translation unit, else undefined behavior results.
>Wrong. The compiler points out two different implementations.
>The executable can't be generated.
If memcpy is not defined as a function with external linkage, and
if <string.h> is not included, an implementation that does not
sucessfully translate the program in question is at error. Did
you actually _try_ it, and if yes, which implementation did
"point out two different implementations"?
--------8<--------8<--------8<--------8<--------8<--------8<--------
#include <stdio.h>
static void *memcpy(void *to, const void *from, size_t n)
{
char *cto = to;
const char *cfrom = from;
while (n--)
*cto++ = *cfrom++;
}
struct foo
{
int fred;
char wilma[32];
double barney;
};
int main(void)
{
struct foo bar = { 0 }, baz = { 42, "Hello", 3.14159 };
memcpy(&bar, &baz, sizeof baz);
printf("%d, %s, %f\n", bar.fred, bar.wilma, bar.barney);
return 0;
}
--------8<--------8<--------8<--------8<--------8<--------8<--------
is a valid C program, because the header associated with the file scope
identifier memcpy() is not included, and because memcpy() is not defined
as a symbol with external linkage.
>> There is no such thing as ``overriding'' in C. Each external name must
>> have exactly one definition if it is used anywhere in the program.
>That's true. C is not object oriented. C++ is just an Smalltalk
>wannabe.
The object model and design ideas behind C++ are completely different
from Smalltalk. You could probably call C++ a Simula wannabe (If you
are prepared to call a Mustang a Modell T wannabe), but calling
it a Smalltalk wannabe indicates that you either don't know Smalltalk
or you don't know C++.
Alicia Carla Longstreet
Charles F Hankel wrote:
: Just to add to this debate, I had to look into the winsock.h file on
: my PC the other day and the first glance showed why COBOL is so much
: more easy to maintain. Anyone with a grain of sense would prefer the
: sheer readability of COBOL to the mess that I saw.
If you prefer a limited language that takes forever to type, fine. But
even COBOL can be made unreadable, and C can be made very readable.
--
Definition of BaseBall - Three minutes of action crammed into 3 hours.
****************************************************************
If at first you don't succeed -- give up! No use being a damn fool.
No job is so simple that is can't be done wrong.
You can only be young once, but you can be immature forever.
Only adults have difficulty with childproof bottles.
==========================================================
Alicia Carla Longstreet ca...@ici.net
Web Page http://www.ici.net/cust_pages/carla/index.html
==========================================================
READ THE FAQ for more information:
C-FAQ ftp sites: ftp://ftp.eskimo.com or ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Lawrence Kirby
In article <67l6kk$m7k$1...@sparcserver.lrz-muenchen.de>
wat...@stat.uni-muenchen.de "Kurt Watzka" writes:
>fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
>
>>In article <67iipp$ktj$1...@darla.visi.com>
>> se...@plethora.net "Peter Seebach" writes:
>
>>>In article <ObfZp4Y...@upnetnews02.moswest.msn.net>,
>>>William J. Leary Jr. <Bill_...@msn.com> wrote:
>>>>Not that I've ever noticed. I frequently use C compilers to target embedded
>>>>systems.
>>>
>>>Then you're using "freestanding environments", which are a separate language.
>>>The library is, indeed, part of the hosted environment form of C.
>
>>Aren't the standard library identifiers with external linkage reserved
>>even in a freestandinhg environment?
>
>How about "In a freestanding environment the name and type of the function
>called at program startup are implementation-defined. There are otherwise
>no reserved external identifiers". I read that as excluding the reservation
>of external identifiers defined in the library clause in a freestanding
>environment. What am I missing?
Good question. I thought I remembered a discussion in comp.std.c that
mentioned that there was a ruling about this and that the standard functions
are in fact reserved. However as something a little more concrete I see that
that last sentence has been removed from the C9X draft.
John Porter
Robert Dewar wrote:
> OK, so your compiler can compile memfoo without compiling. Wunderbar! But
> that does NOT mean that you can actually go ahead and call a routine memfoo
> if the standard forbids it. To do so would be incompetent programming.
So now a "language" is not defined by the compiler -- or even by the
preprocessor+compiler+linker+etc, as some have it...
I am forbidden by a piece of paper from calling a function 'memfoo'!
John Porter
jpo...@logicon.com
Patricia Shanahan
I would put it in a more positive light. You are promised that
programs that don't call a function "memfoo" and meet some other
conditions WILL compile with any correct C compiler, not just the
current version of the compiler you are using today.
Patricia
Alicia Carla Longstreet
John Porter wrote:
: Robert Dewar wrote:
: > OK, so your compiler can compile memfoo without compiling. Wunderbar!
But
: > that does NOT mean that you can actually go ahead and call a routine
memfoo
: > if the standard forbids it. To do so would be incompetent programming.
: So now a "language" is not defined by the compiler -- or even by the
: preprocessor+compiler+linker+etc, as some have it...
: I am forbidden by a piece of paper from calling a function 'memfoo'!
No the language is *not* defined by any single compiler, neither is it
defined by any piece of paper. A language is defined by usage. A
combination of compilers and the standard.
The ISO Standard defines the core of the language. Any C compiler *must*
support this common core, but it may also support various extensions to
support the specifics of its platform. Just like the English language is
not 'defined' by any single dictionary, rather the dictionary is a
'snapshot' of the language (or part of the language) at a particular point
in time.
Similarly the ANSI/ISO Standard is a snapshot of the common core of the C
language. The language itself continues to grow and evolve. Actually C9X
recognizes this but preparing a new 'snapshot' of the language (or at least
the core).
The standard is needed to keep the language balance. To keep it from
changing out of control. It is always an 'after the fact' situation.
--
If at first you don't succeed -- give up! No use being a damn fool.
No job is so simple that is can't be done wrong.
You can only be young once, but you can be immature forever.
==========================================================
Alicia Carla Longstreet ca...@ici.net
Web Page http://www.ici.net/cust_pages/carla/index.html
==========================================================
READ THE FAQ for more information:
C-FAQ ftp sites: ftp://ftp.eskimo.com or ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Remember: Those who think they know it all...
Are very annoying to those of us who do.
Lawrence Kirby
>Robert Dewar wrote:
>> OK, so your compiler can compile memfoo without compiling. Wunderbar! But
>> that does NOT mean that you can actually go ahead and call a routine memfoo
>> if the standard forbids it. To do so would be incompetent programming.
>
>So now a "language" is not defined by the compiler -- or even by the
>preprocessor+compiler+linker+etc, as some have it...
They may very well define a language but they certainly don't define the
C language.
>I am forbidden by a piece of paper from calling a function 'memfoo'!
You can't declare/define memfoo as an identifier with external linkage if
you are writing C code. That is because the standard permits compilers to
use it for their own purposes. If you want to use it with your particular
compiler because you "know" it works then nobody is going to stop you.
However any real guarantees you have that it will work are tenuous at best
and all bets are off from a portability perspective. It may be more
obvious when you consider functions like strdup() or strupr(). The
same considerations apply except that some compilers are actually known to
define these functions. Perhaps the nastiest header in this respect is
<ctype.h> which reserves identifiers starting with is and to (followed by
a lowercase letter). So names like issue and token are reserved.
Billy Chambless
In article <01bd147e$11496760$6a28...@carla.ici.net>, "Alicia Carla Longstreet" <ca...@ici.net> writes:
|> John Porter wrote:
|> : So now a "language" is not defined by the compiler -- or even by the
|> : preprocessor+compiler+linker+etc, as some have it...
|> No the language is *not* defined by any single compiler, neither is it
|> defined by any piece of paper. A language is defined by usage. A
|> combination of compilers and the standard.
mmmm.... well, I'd say the standard defines a lot of what the compilers
may and may not do.
ISO defines ISO C, Borland defines Borland C etc....
|> The ISO Standard defines the core of the language. Any C compiler *must*
|> support this common core, but it may also support various extensions to
|> Similarly the ANSI/ISO Standard is a snapshot of the common core of the C
|> language. The language itself continues to grow and evolve. Actually C9X
|> recognizes this but preparing a new 'snapshot' of the language (or at least
|> the core).
I don't think that's exactly right. It seems that some of the proposded
changes aren't really part of existing practice... but I'll shut up and
wait for committee members and people who have beed tracking the draft
to comment on that.
|> The standard is needed to keep the language balance. To keep it from
|> changing out of control. It is always an 'after the fact' situation.
No, there's more to the standards process than codifying existing
practice. Somewhere I have an article by Tom Plum where he says that
it was *mumble* months after C89 was ratified before even one compiler
passed the Plum Hall validation suite -- a suite of tests that verified
how well the compiler complied with the standard. I'm sure that somebody
who was closer to the action is reading this, and can comment.
Robert Dewar
John says
<<So now a "language" is not defined by the compiler -- or even by the
preprocessor+compiler+linker+etc, as some have it...
I am forbidden by a piece of paper from calling a function 'memfoo'!
John Porter
jpo...@logicon.com
>>
Of course the answer is that the language is defined by the standard. What
is surprising is your exclamation mark at the end of a statement that should
be common understanding for any programmer.
Of course the language is not defined by the compiler, or any combination
of tools. This is nothing new, languages have been defined by standards
for a very long time. C came rather late to the standards business, but
even before the ANSI C standard was approved, C was defined by pieces
of paper, including for example the reference manual at the back of K&R.
For anyone to think that a language is usefully defined by a compiler is
to me evidence of poor training. No one should be able to get out of any
CS degree program with this kind of misconception.
However, as I said in my earlier message, I am afraid that this confusion
is a very common one and is responsible for a huge percentage of the problems
in porting code, regardless of the language.
If your only knowledge of the definition of a language comes from what you
find is accepted by your compiler, you can be sure that your code is unlikely
to be anywhere as near portable as it should be.
Guillermo Schwarz
Kurt Watzka wrote:
> Guillermo Schwarz <gsch...@netup.cl> writes:
>
> >Kaz Kylheku wrote:
> >> Although 'memcpy' is not a reserved keyword by any means,
> >> it is a reserved 'external name'.
> >It is the first time I see reserved external.
>
> Well, looks as if there still is something to learn about C for you.
> The exact wording is "are reserved as identifiers with external
> linkage", but "reserved external name" looks close enough to me.
>
It's nice to know C advances so fast I can't keep up to date with its
definition."Reserved as identifiers" is something meaningful to you? Can you
reserve a name as
a non indentifier?
"with external linkage"? Those are too many words just to mean an extrernal
name.
The point is, at least when I studied the good and old K&R, it didn't mention
"reserved as identifiers with external linkage", that for me means "don't
touch this,
or trick"... The C guys modify their language each 3 months just when they
realize
something is missing. If you think it is funny, I think it is pretty messy.
In Smalltalk, there is USUALLY no need to change the language, but just the
need
to add new classes and methods to achieve what's needed.
> If memcpy is not defined as a function with external linkage, and
> if <string.h> is not included, an implementation that does not
> sucessfully translate the program in question is at error. Did
> you actually _try_ it, and if yes, which implementation did
> "point out two different implementations"?
You are right! I'm amazed. GNU gcc does implement memcpy directly (what is to
say thatmemcpy is inlined into the resulting exe, independently from how it
is defined
in the program).
I would like to follow the only faith: smallTalk, so that my flesh doesn't
get rotten.
How can somebody have a life, if the ANSI is changing the language so fast?
They think that by changing minor things they can keep C alive?
(I'm not meaning C is dead, but let Electronic Engineers do the drivers for
their
HW in C, but don't tell the rest of the world C is the right language because
it
is well implemented or something else wrong like that).
Maybe not too much people write their dirvers in Smalltalk because the
drivers
are very simple pieces of code. Drivers have no complex algorithms, they just
need sti(), cli(). That's why drivers are made in C. That's why drivers were
made
in assembly.
> The object model and design ideas behind C++ are completely different
> from Smalltalk.
Objects have behavior and state in both languages.C doesn't have objects, nor
behavior, nor state.
C++ is backward compatible with C.
----------------------------------------
C++ is a Smalltalk wannabe (at least an OOL wannabe).
> You could probably call C++ a Simula wannabe (If you
> are prepared to call a Mustang a Modell T wannabe)
Oops! It seems a C++ defender is here. You think C++ is fast as a mustang?At
least a Model T is not as fast as a Mustang, but C is usually faster than C++
unless
the coder is at least 3 years experience.
Model T is more like Simula, very old, very good for their time. Now they
wouldn't sell.
Mercedes is more like Smalltalk. Well designed. Strong. Fast. Everything in
it is a pleasure.
Fiat 600 is more like C++. Old desing. Poor. Pieces doesn't fit. Nothing in
it is beautiful.
Shopping Cart is more like C. You must do everything by hand. Walking is the
only way to
move it. Put two people in it, and they will be discussing all the time. Be
careful or you can
drop to the floor very easily and get your mouth red with your own blood. Or
what's worse,
your body can become a corpse dump.
> , but calling
> it a Smalltalk wannabe indicates that you either don't know Smalltalk
> or you don't know C++.
I'm sorry to hurt your feelings about C++. But it turns out that C++ is a
very poorlanguage. You can't know how many bits does an int have. Or if long
is actually bigger
than int. You can't ask an structure how many fields does it have. You can't
tell an
structure to write itself into a file. You can't code an algorithm that works
with any
kind of numbers: int, double, big int, etc.
In C++ there is no way to handle overflow of integers.
Ask in runtime how many classes do you have in your image.
Or try to figure out which classes descend from which.
Try to make a single general program.
Try to create a Set of objects in C++.
Try to create a Bag of objects in C++.
Try to create a SortedCollection of objects in C++.
Convert one collection into another. (SortedCollection as Bag or whatever).
Put a Set inside another Set.
Try to create a Dictionary of pairs of objects in C++ using hashing to index
the keys.
Then put a Dictionary and a Set inside a Dictionary with the Dictionary as
the key.
If you can do a single thing of what I wrote here you are a good C++
programmer.
All this can be done in 10 minutes in Smalltalk (if lazy).
I'm sorry if I hurt your feelings, but for the last 3 months I've been
Smalltalking more than
keeping up with the C crap. (C++ being the cream of the crap and Java being
coffe you
drink with cream).
I mean no offense to other languages. Fortran had its time. C had it. C++ had
it. Java is having it.
Smalltalk deserves a little respect as the king of OOL. (Maybe CLOS guys will
not agree with
me), but trying to say that C++ object model is better than Smalltalk object
model is saying
GW BASIC is more structured than Pascal. And claiming you know C++ and
Smalltalk more
than me is something to prove, sir!
Kaz Kylheku
In article <34A50C...@netup.cl>,
Guillermo Schwarz <gsch...@netup.cl> wrote:
>Kaz Kylheku wrote:
>> Although 'memcpy' is not a reserved keyword by any means,
>> it is a reserved 'external name'.
>It is the first time I see reserved external.
The second time may come when you actually read the standard.
>> A strictly conforming program may not define any external
>> name that begins with 'mem' followed by any combination of letters,
>> digits or underscores.
>Ok. Define void memfoo() { } and see if it compiles.
>It does.
You clearly have no idea about what distinguishes a language definition
from a language implementation.
Of course the definition of memfoo compiles! But a future version of the C
language may add memfoo to the standard library, at which point your program
might not compile. An existing implementation may also define its own
memfoo, knowing that a strictly conforming C program won't use such
an identifier as an external name.
>> Define memcpy, if you write such a static function, you must not
>> include the <string.h> header in
>> the same translation unit, else undefined behavior results.
>Wrong. The compiler points out two different implementations.
>The executable can't be generated.
That is a possible consequence of undefined behavior, yes. On many systems,
however, you _can_ in fact write your own version of a standard function
with external linkage. The result is that your program, and all libraries
it is linked to, use the new function. That is another possible
consequence of undefined behavior.
If the standard required the implementation to fail to make an executable,
it would not be undefined behavior.
>> There is no such thing as ``overriding'' in C. Each external name must
>> have exactly one definition if it is used anywhere in the program.
>That's true. C is not object oriented. C++ is just an Smalltalk
>wannabe.
I wasn't talking about overriding methods in an ancestor class, but a physical
overriding of external names at link time! This capability C++ does not have
either; it has the One Definition Rule (ODR).
Kaz Kylheku
In article <34A7B4...@min.net>, John Porter <jdpo...@min.net> wrote:
>Robert Dewar wrote:
>> OK, so your compiler can compile memfoo without compiling. Wunderbar! But
>> that does NOT mean that you can actually go ahead and call a routine memfoo
>> if the standard forbids it. To do so would be incompetent programming.
>
>preprocessor+compiler+linker+etc, as some have it...
>I am forbidden by a piece of paper from calling a function 'memfoo'!
That piece of paper, as you say, doesn't forbid any such thing! It merely
states that all bets are off if you do that, because the identifier
belongs to a reserved name space.
What is important is not what the paper forbids, but what it allows!
It allows an actual implementation to forbid you from calling an
external function by a reserved name. What's worse, it allows an
implementation to behave unpredictably.
Go ahead! Break the rules! Ignore the paper! You will look foolish in the end.
Kaz Kylheku
In article <685mee$5d4$1...@sparcserver.lrz-muenchen.de>,
>>> Although 'memcpy' is not a reserved keyword by any means,
>>> it is a reserved 'external name'.
>>It is the first time I see reserved external.
>
>The exact wording is "are reserved as identifiers with external
>linkage", but "reserved external name" looks close enough to me.
The first occurence of ``external name'' appears in italics in the standard.
It is formally defined as having the same meaning as ``name with external
linkage''; to say that something is reserved as an external name is
*precisely* the same as saying that it is reserved as an identifier with
external linkage, not merely ``close enough''.
:))
Kaz Kylheku
In article <34A812F9...@its.cl>,
Guillermo Schwarz <gsch...@its.cl> wrote:
>It's nice to know C advances so fast I can't keep up to date with its
>definition."Reserved as identifiers" is something meaningful to you? Can you
>reserve a name as
>a non indentifier?
No, but you can reserve a name for use as one kind of identifier but not
another. ``Reserved for external linkage'' means that your program cannot
define certain identifiers such that these identifiers have external
linkage.
It means that you can still use 'memcpy' as the name of a local variable,
as a typedef name, or as a name with internal linkage or a macro name.
(However, if you use the name in these ways, you may not include the
<string.h> header in the translation unit because such uses may clash
with that header.)
>"with external linkage"? Those are too many words just to mean an extrernal
>name.
The term ``external name'' is a short way of saying ``name with external
linkage''. What's the big deal about that?
>The point is, at least when I studied the good and old K&R, it didn't mention
>
>"reserved as identifiers with external linkage", that for me means "don't
>touch this,
Note that what is now the library was not yet a formal part of the language
then. The standard C library had its beginnings as an actual UNIX library.
Anyway, K&R1 did _not_ bless any program which has multiple definitions
of external names!
The library is a required component of a hosted implementation of modern,
standard C. Thus it follows that its external names are off-limits
to the programmer who wishes to write strictly conforming C code,
or come as close as possible.
>or trick"... The C guys modify their language each 3 months just when they
>realize
>something is missing. If you think it is funny, I think it is pretty messy.
Nonsense. The standard has been stable for 8 years now, with only very
minor changes in response to genuine defect reports, the addition of
one header file <iso646.h> and support for wide character I/O. Prior
to the standard, the C language was in shambles.
The big changes are coming in C9X, which will be a distinct language from
1989 C.
>In Smalltalk, there is USUALLY no need to change the language, but just the
>need
>to add new classes and methods to achieve what's needed.
Are you talking about an implementation of Smalltalk or the language
Smalltalk? Based on your previous posting, it's obvious that you confuse
the two.
How do you add these new methods and classes to the *language*? That would
require that you join some committee and push for the changes to be
added to the language definition.
If what you mean is that you can add some classes to your Smalltalk
programming environment, then so what? You can also add your own libraries
to a C project, or classes to a C++ project.
Alicia Carla Longstreet
Robert Dewar wrote:
: John says
: <<So now a "language" is not defined by the compiler -- or even by the
: preprocessor+compiler+linker+etc, as some have it...
: I am forbidden by a piece of paper from calling a function 'memfoo'!
: Of course the answer is that the language is defined by the standard.
What
: is surprising is your exclamation mark at the end of a statement that
should
: be common understanding for any programmer.
Only programmers who have no concept of what a language, any language is.
Even if the Standard does define the language, it only did so on the day
the standard was finalized. Languages, even programming language, evolve
and change over time. A Standards document can never be a current
definition of a language, only the definition of the language at some point
in the past. Even so, the ANSI/ISO Standards defining C only define the
common core of the C language. When C9X is finalized, at that moment it
will define the core of the C programming language. By the time it is
actually published and distributed the language will have changed to a
small extent.
: Of course the language is not defined by the compiler, or any combination
: of tools. This is nothing new, languages have been defined by standards
: for a very long time. C came rather late to the standards business, but
: even before the ANSI C standard was approved, C was defined by pieces
: of paper, including for example the reference manual at the back of K&R.
Keep on dreaming. No language, ever, can be defined by a piece of paper.
Unless it is a dead language that is no longer used and therefore no longer
changes. This concept is simply impossible.
: For anyone to think that a language is usefully defined by a compiler is
: to me evidence of poor training. No one should be able to get out of any
: CS degree program with this kind of misconception.
This is true. The language is defined by usage (*All* languages are
defined by usage).
: However, as I said in my earlier message, I am afraid that this confusion
: is a very common one and is responsible for a huge percentage of the
problems
: in porting code, regardless of the language.
Yes it is important to understand the each compiler may represent a
different dialect of the C language, one that may or may not be compatible
with any other specific compiler.
: If your only knowledge of the definition of a language comes from what
you
: find is accepted by your compiler, you can be sure that your code is
unlikely
: to be anywhere as near portable as it should be.
True. Too many programmers learn from BASIC where there is almost no
cross-platform or even cross-compiler/interpreter compatibility. It is
difficult to impress students with the need to write portably with a
language that is not portable. About as effective as your father telling
you not to smoke in between drags on his cigarette. Just another reason
not to use BASIC as a teaching tool (unless you are teaching how to make
spagetti).
Robert Dewar
<<Keep on dreaming. No language, ever, can be defined by a piece of paper.
Unless it is a dead language that is no longer used and therefore no longer
changes. This concept is simply impossible.
>>
This is complete nonsense. It does not correspond to the real situation
with many standardized languages. Many programmers know the C standard
well, carefully adhere to it, and succeed in writing portable code, and
the same thing can be said of Fortran, COBOL and Ada programmers (
particularly in the latter case, Ada programmers tend to know the standard
well).
The idea that a language wanders around ill-defined, and programmers follow
it may seem familiar to undisciplined hackers, but it does not required
dreamers to correct this totally unacceptable behavior!
<<Only programmers who have no concept of what a language, any language is.
Even if the Standard does define the language, it only did so on the day
the standard was finalized. Languages, even programming language, evolve
and change over time. A Standards document can never be a current
definition of a language, only the definition of the language at some point
in the past. Even so, the ANSI/ISO Standards defining C only define the
common core of the C language. When C9X is finalized, at that moment it
will define the core of the C programming language. By the time it is
actually published and distributed the language will have changed to a
small extent.
>>
Sounds like you have very little direct experience with language
standardization efforts, your account above bares no relation to reality.
Lawrence Kirby
>Kurt Watzka wrote:
>
>> Guillermo Schwarz <gsch...@netup.cl> writes:
>>
>> >Kaz Kylheku wrote:
>> >> Although 'memcpy' is not a reserved keyword by any means,
>> >> it is a reserved 'external name'.
>> >It is the first time I see reserved external.
>>
>> Well, looks as if there still is something to learn about C for you.
>> The exact wording is "are reserved as identifiers with external
>> linkage", but "reserved external name" looks close enough to me.
>>
>
>It's nice to know C advances so fast I can't keep up to date with its
>definition."Reserved as identifiers" is something meaningful to you?
No, it doesn't out of context. Actually the wording above doesn't appear to
be exact. The full sentence is (in 7.1.3)
"- All identifiers with external linkage in any of the following subclauses
(including the future library directions) are always reserved for use
as identifiers with external linkage"
That means that if any of the following subclauses define an identifier
(or name if you like) as having external linkage then you can't declare
that identifier/name yourself with external linkage. If you do you get
undefined behaviour which means anything can happen. It could be that the
code compiles and does what you expected it to, that the code fails to
compile, that the code compiles and does something completely different
possibly even crashing during execution.
This is reiterated to an extent in subclause 7.13 (Future library durections):
"All external names described below are reserved no matter what headers
are included by the program"
One of the sections "below" is:
"7.13.8 String handling <string.h>
Function names that begin with str, mem, or wcs and a lowercase letter
(followed by any combination of digits, letters, and inderscore) may be
added to the declarations in the <string.h> header."
>Can you reserve a name as a non indentifier?
No, but that's not what it said. You're trying to take this out of context.
>"with external linkage"? Those are too many words just to mean an extrernal
>name.
>The point is, at least when I studied the good and old K&R, it didn't mention
>
>"reserved as identifiers with external linkage", that for me means "don't
>touch this,
>or trick"...
K&R2 doesn't define the language. It is an excellent book but there do seem to
be a few things it doesn't cover properly. The index lists "reserved words"
but that just seems to refer to keywords. Even though it was revised after
the standard was released it seems to be based mainly on a draft standard.
>The C guys modify their language each 3 months just when they
>realize
>something is missing. If you think it is funny, I think it is pretty messy.
I don't know where you got that idea. The text I quoted was directly from
the 1990 ISO standard. The text in the original 1989 ANSI standard is
almost certainly the same - the only major thing that changed between the
two was the section numbering. There have been 2 or maybe 3 changes to the
standard since then but the scope of them is minor, mostly fixing errors
and areas of confusion in the original.
>In Smalltalk, there is USUALLY no need to change the language, but just the
>need
>to add new classes and methods to achieve what's needed.
If you take K&R1 as a revision the C language seems to get revised in a
significant way roughly every 10 years. That's not dissimilar to other
languages (e.g. Ada-83,95 and Fortran 66,77,90)
>> If memcpy is not defined as a function with external linkage, and
>> if <string.h> is not included, an implementation that does not
>> sucessfully translate the program in question is at error. Did
>> you actually _try_ it, and if yes, which implementation did
>> "point out two different implementations"?
>
>You are right! I'm amazed. GNU gcc does implement memcpy directly (what is to
>say thatmemcpy is inlined into the resulting exe, independently from how it
>is defined
>in the program).
It is an optimisation choice the compiler is free to make for itself. This
is possible because the language allows it to do anything it likes if you
break the rules such as try to define your own memcpy() with external
linkage. The compiler is allowed to "know" how standard library functions
behave.
>I would like to follow the only faith: smallTalk, so that my flesh doesn't
>get rotten.
>
>How can somebody have a life, if the ANSI is changing the language so fast?
It isn't. (As an aside ISO has controlled the C standard since 1990).
>They think that by changing minor things they can keep C alive?
>(I'm not meaning C is dead, but let Electronic Engineers do the drivers for
>their
>HW in C, but don't tell the rest of the world C is the right language because
>it
>is well implemented or something else wrong like that).
No, the one thing that standardisation did was to effectively halt the
development of the C language. This is a good thing for the reasons you
imply. However C does still need to be allowed to develop occasionally.
The 1989 language is showing its age in some areas e.g. lack of guaranteed
support for 64 bit (or larger) integers. Being a lower level language
than many it does have greater pressure on it to adapt to changing
hardare capabilities. Still, the change rate is hardly excessive.
>Maybe not too much people write their dirvers in Smalltalk because the
>drivers
>are very simple pieces of code. Drivers have no complex algorithms, they just
>
>need sti(), cli(). That's why drivers are made in C. That's why drivers were
>made
>in assembly.
>
>> The object model and design ideas behind C++ are completely different
>> from Smalltalk.
>
>Objects have behavior and state in both languages.C doesn't have objects, nor
>behavior, nor state.
C has objects but it doesn't have all the OO paraphernalia that goes with
them in a language like C++ (you could say it lacks the behaviour part).
The purpose of an object in C is to store state. Maybe the OOP'ers have a
more abstract view of what an object is.
>C++ is backward compatible with C.
It might be fair to say that C++ is mostly backwards compatible with C.
However there is enough incompatibility to make it a bad idea to try to
compile natural C code with a C++ compiler.
Gary Drummond
Charles F Hankel wrote:
>
> Just to add to this debate, I had to look into the winsock.h file on
> my PC the other day and the first glance showed why COBOL is so much
> more easy to maintain. Anyone with a grain of sense would prefer the
> sheer readability of COBOL to the mess that I saw.
>
> ------------------------------------------------------------------
> COBOLs: IBM D, E, F, ANS v4, VS, COBOL 2, LE/370, AIX, S/38, OS/2,
> PC/MS-DOS, Honeywell GCOS, Burroughs 7000, Tandem, HP3000
> all to varying degrees over the past 25 years or so.
done in C?
Patricia Shanahan
> >The point is, at least when I studied the good and old K&R, it didn't mention
> >
> >"reserved as identifiers with external linkage", that for me means "don't
> >touch this,
> >or trick"...
>
> K&R2 doesn't define the language. It is an excellent book but there do seem to
> be a few things it doesn't cover properly. The index lists "reserved words"
> but that just seems to refer to keywords. Even though it was revised after
> the standard was released it seems to be based mainly on a draft standard.
"good and old K&R" may be K&R1, not K&R2.
Bob Jarvis
If you've spent your career writing COBOL it shouldn't be surprising
that a C header file appears confusing.
I just looked through winsock.h and it didn't look incomprehensible
to me. Of course, I've got about 15 years of C behind me.
I haven't looked at COBOL in over 10 years. No doubt it'd take me a
while to come up to speed on it again.
So how do you feel about Smalltalk? :-)
--
Bob Jarvis
Mail address hacked to foil spammers!
Remove "ob" from address to reply
Charles F Hankel <cha...@hankel.mersinet.co.uk> wrote in article <34a61f24...@news.mersinet.co.uk>...
Billy Chambless
|> Kurt Watzka wrote:
|> > Guillermo Schwarz <gsch...@netup.cl> writes:
>
|> > Well, looks as if there still is something to learn about C for you.
|> > The exact wording is "are reserved as identifiers with external
|> > linkage", but "reserved external name" looks close enough to me.
|> It's nice to know C advances so fast I can't keep up to date with its
|> definition.
Yeah, it's pretty tough, trying to look at the new version of the
standard every decade or so.
|> "Reserved as identifiers" is something meaningful to you? Can you
|> reserve a name as a non indentifier? "with external linkage"?
The exact quote ( from ISO 9899-1990) is:
-- All identifiers with external linkage in any of the following
subclauses (including the future library directions) are always
reserved for use as idenitiers with external linkage.
You have to read the sentence all the way through in order to
understand. "Reserved as identifiers" might be a bit silly, but
"reserved as identifiers with external linkage" makes some sense, no?
|> The point is, at least when I studied the good and old K&R, it didn't
|> mention "reserved as identifiers with external linkage",
Why don't you take a bold step forward into the 1980's and take a look
at ANSI/ISO C? ;)
|> or trick"... The C guys modify their language each 3 months just when they
|> realize
|> something is missing. If you think it is funny, I think it is pretty messy.
They do? Which C guys is that? The bit about external identifiers is a
quote from C89. We have great hopes that C9X will be ratified before we
call have to call it C01 or something.
There have been a couple addenda to the C standard, but no big changes
in 7 years.
|> In Smalltalk, there is USUALLY no need to change the language, but just the
|> need to add new classes and methods to achieve what's needed.
[ assorted language advocacy snipped. You've heard it all before... ]
|> I'm sorry to hurt your feelings about C++. But it turns out that C++ is a
|> very poorlanguage.
Yeah, it sucks. That's why so many people get paid so much money tp
program in it when they'd really rather be using Smalltalk. Or Lisp.
|> You can't know how many bits does an int have. Or if long
|> is actually bigger than int.
You can't? Wow...I though you could.
|> You can't tell an structure to write itself into a file.
You can't? I thought I had....
|> You can't code an algorithm that works with any
|> kind of numbers: int, double, big int, etc.
You can't? Has anybody told Alexander Stepanov about this?
|> Try to make a single general program.
Huh? A single general program? Help me out here...what does that mean?
|> Try to create a Set of objects in C++.
|> Try to create a Bag of objects in C++.
|> Try to create a SortedCollection of objects in C++.
Hmmmm.... I get it. Your knowledge of C++ is as current as your
knowledge of C.
|> I'm sorry if I hurt your feelings, but for the last 3 months I've been
|> Smalltalking more than keeping up with the C crap.
Obviously.
|> (C++ being the cream of the crap and Java being coffe you
|> drink with cream).
I do like that, though: "C++ : The cream of the Crap!".
|> I mean no offense to other languages. Fortran had its time. C had it. C++ had
|> it. Java is having it.
And Smalltalk...?
|> And claiming you know C++ and Smalltalk more
|> than me is something to prove, sir!
...and the band played on.
[ spewage apparantly generated by Web browser being overloaded as
newsreader deleted ]
Billy Chambless
In article <dewar.883445953@merv>, de...@merv.cs.nyu.edu (Robert Dewar) writes:
|> <<Keep on dreaming. No language, ever, can be defined by a piece of paper.
|> Unless it is a dead language that is no longer used and therefore no longer
|> changes. This concept is simply impossible.
|> >>
|> This is complete nonsense. It does not correspond to the real situation
|> with many standardized languages. Many programmers know the C standard
|> well, carefully adhere to it, and succeed in writing portable code, and
|> the same thing can be said of Fortran, COBOL and Ada programmers (
|> particularly in the latter case, Ada programmers tend to know the standard
|> well).
And the converse is true, as well. Many "programmers" who consider the
compiler to define the laguage generate code that runs fine, but creates
major migraines when it has to be ported, or even compiled with a
different compiler. On Unix, for instance, the standard Sun C compiler
will accept crap that the SGI compiler will choke on.
|> The idea that a language wanders around ill-defined, and programmers follow
|> it may seem familiar to undisciplined hackers, but it does not required
|> dreamers to correct this totally unacceptable behavior!
Yep. It's not really all that hard to base one's programing style on the
formal definition of the language, making use of extensions as needed.
It's more an attitude than anything.
|> Sounds like you have very little direct experience with language
|> standardization efforts, your account above bares no relation to reality.
Indeed.
Jeffrey Templon
"Alicia Carla Longstreet" <ca...@ici.net> writes:
> No the language is *not* defined by any single compiler, neither is it
> defined by any piece of paper. A language is defined by usage. A
> combination of compilers and the standard.
I'd guess this opinion is generated by doing the majority of one's
work on the same platform, possibly even using the same development
tools, whenever you use C.
We have had *no end* of headaches on our big code, because the original
lead programmer agreed with your definition of the language (in this
case, Fortran). He declared that one extension he made extensive
use of (no pun intended, but I like it) was *standard* because every
compiler he ever used supported it. The year after the first major
release, CEBAF made a big investment in IBM RS/6000 machines, and lo
and behold this wonderful extension was *not* supported in IBM's
compiler suite! Also lots of people started getting Linux boxes
at about the same time, and it has only been in the last year that
Linux compilers are available which support this extension (although
there were a number of Fortran compilers available which did not
support the extension.) So our project does not have access to a
significant fraction of the on-site horsepower, and we're looking at
a six-month project to convert this extension usage to conform to the
F90 standard.
Good luck with any porting projects you may have in the future.
JAT
Patricia Shanahan
Jeffrey Templon wrote:
>
> "Alicia Carla Longstreet" <ca...@ici.net> writes:
>
> > No the language is *not* defined by any single compiler, neither is it
> > defined by any piece of paper. A language is defined by usage. A
> > combination of compilers and the standard.
>
> I'd guess this opinion is generated by doing the majority of one's
> work on the same platform, possibly even using the same development
> tools, whenever you use C.
I sometimes think that every programmer should be required to port a
large program to its second platform before doing any new code.
Preferably, the first platform should differ in word size, endianness,
and general software heritage (e.g. UNIX vs. MSWindows vs. VMS) from
the new target. There is nothing quite like this experience for an
enhanced appreciation the value of standards.
Patricia
Charles R Martin
Years ago, I helped teach an undergrad software engineering
this-is-what-it's-
like-in-the-real-world-kiddies course at Duke. We included an
assignment in which the students had to perform maintenance on an
existing PL/I program in order to add new functionality. (It was a
reasonably well-structured program on which I had [hee hee] removed
almost all comments and somewhat obfuscated the variable names -- a lot
like trying to maintain a lot of C code.) years later, students I run
in to STILL tell me that it was the only class they had that prepared
them for real life. (They're wrong -- the data structures class and
other such just aren't as obvious in their effects, but that's another
posting.)
Eventually, the faculty member who owned the course didn't get tenure,
and the course was taken over by a guy who felt that "software
engineering" was best taught by writing the fastest program to find
discontinuities in the REAL type.
Joshua Waxman
On Mon, 29 Dec 1997, Guillermo Schwarz wrote:
> very poorlanguage. You can't know how many bits does an int have. Or if long
> is actually bigger
> than int.
You can't? How about sizeof(int) and if(sizeof(int) < sizeof(long))
> You can't ask an structure how many fields does it have.
True. But structures in C++ tend to have a constant number of fields, no?
> You can't tell an
> structure to write itself into a file.
Yes you can. You just have to include in the definition of the struction a
function the does output. Most overload the << with the ostream operator.
> You can't code an algorithm that works
> with any
> kind of numbers: int, double, big int, etc.
Ever hear of template functions?
> In C++ there is no way to handle overflow of integers.
Check after each addition to see if you reversed signs, and act
accordingly.
> Ask in runtime how many classes do you have in your image.
I'm interested what this means. What is an image that contains classes?
> Or try to figure out which classes descend from which.
I think it is possible to do this. RTTI. Also, can't you do a dynamic_cast
and check if the pointer is null, if not then the class descends?
> Try to make a single general program.
What does this mean?
> Try to create a Set of objects in C++.
#include <set>
using namespace std;
set <int> h; set <set<char> > k;
> Try to create a Bag of objects in C++.
ditto, just replace with multiset.
> Try to create a SortedCollection of objects in C++.
extend it from one of the base containers.
> Convert one collection into another. (SortedCollection as Bag or whatever).
The generic copy algorithm.
> Put a Set inside another Set.
set <set <char > > k;
or do you mean copy the contents? There is a copy.
> Try to create a Dictionary of pairs of objects in C++ using hashing to index
> the keys.
Your speaking about the map type. Maps aren't actually implemented using
hashes, I don't think, but in Stroustrup's book he shows how to quickly do
this.
> Then put a Dictionary and a Set inside a Dictionary with the Dictionary as
> the key.
Can do.
> If you can do a single thing of what I wrote here you are a good C++
> programmer.
Or a programmer who knows the Standard Template Library.
> All this can be done in 10 minutes in Smalltalk (if lazy).
>
By all, do you mean that in 10 minutes you would have completed EVERY
item, of that each item in turn could be completed in 10 minutes?
In C++, most of the stuff you listed could be done in less than a minute
each. The hash is a bit more complicated, and might take 1/2 an hour. For
a more experienced programmer, possibly shorter.
> I'm sorry if I hurt your feelings, but for the last 3 months I've been
> Smalltalking more than
> keeping up with the C crap.
C++, you mean. And apperently you haven't. :)
(C++ being the cream of the crap and Java being coffe you drink with
cream).
>
> I mean no offense to other languages. Fortran had its time. C had it. C++ had
> it. Java is having it.
> Smalltalk deserves a little respect as the king of OOL. (Maybe CLOS guys will
> not agree with
> me), but trying to say that C++ object model is better than Smalltalk object
> model is saying
> GW BASIC is more structured than Pascal. And claiming you know C++ and
> Smalltalk more
> than me is something to prove, sir!
>
I don't know Smalltalk at all. C++ did I prove?
Josh Waxman
firewind
On Tue, 30 Dec 1997, Joshua Waxman wrote:
> On Mon, 29 Dec 1997, Guillermo Schwarz wrote:
> > very poorlanguage. You can't know how many bits does an int have. Or if long
> > is actually bigger
> > than int.
> You can't? How about sizeof(int) and if(sizeof(int) < sizeof(long))
sizeof(int) gives the size in bytes, which you need to multiply by
CHAR_BIT to get the number of bits.
> > You can't ask an structure how many fields does it have.
>
> True. But structures in C++ tend to have a constant number of fields, no?
And I'm curious as to the usefulness of this, anyway. How can you use a
structure that you don't know the layout of?
> > In C++ there is no way to handle overflow of integers.
>
> Check after each addition to see if you reversed signs, and act
> accordingly.
What about unsigned arirthmetic? What if sign reversal is possible (but
not garunteed) in this expression, without any overflow?
[- firewind -]
[- email: fire...@metroid.dyn.ml.org (home), fire...@aurdev.com (work) -]
[- "You're just jealous because the voices talk to -me-." -]
[- Have a good day, and enjoy your C. -]
[- (on a crusade of grumpiness where grumpiness is due) -]
Kaz Kylheku
In article <34A812F9...@its.cl>,
Guillermo Schwarz <gsch...@its.cl> wrote:
>I'm sorry to hurt your feelings about C++. But it turns out that C++ is a
>very poorlanguage. You can't know how many bits does an int have. Or if long
>is actually bigger
>than int. You can't ask an structure how many fields does it have. You can't
Why would this be useful?
>tell an
>structure to write itself into a file. You can't code an algorithm that works
Why not? Have you never heard of object store databases?
>with any
>kind of numbers: int, double, big int, etc.
Nonsense. You obviously haven't heard of C++ features such as templates,
and operator and function overloading.
>In C++ there is no way to handle overflow of integers.
An overflow is a serious programming error. The way you handle it is by not
making the error in the first place. In C and C++, integer overflow invokes
undefined behavior---an implementation isn't required to handle overflow, but
may.
You can detect overflows with assertions. I could lecture you how, but
it would probably be a waste of time. You first need to learn the basics,
like what a language standard is and how it differs from a compiler
manual.
>Ask in runtime how many classes do you have in your image.
I can't imagine what possible benefit it could have, but I will concede
that ``it's neat''.
>Or try to figure out which classes descend from which.
If you don't know which classes descend from which, you probably have a
mess of a design.
C++ is a _statically_ typed language; this gives it a performance advantage
and added safety (though the type safety of C++ does arguably leave
something to be desired.) Who writes high-performance applications in
Smalltalk?
>Try to make a single general program.
What's that? I'm conjuring images of something that plays chess and routes
IP packets at the same time.
>Try to create a Set of objects in C++.
>Try to create a Bag of objects in C++.
>Try to create a SortedCollection of objects in C++.
I'm not thorougly versed with the standard template library, but I believe
that it has enough clout for this sort of thing. If not, you can implement
your own classes.
>Convert one collection into another. (SortedCollection as Bag or whatever).
>Put a Set inside another Set.
>Try to create a Dictionary of pairs of objects in C++ using hashing to index
>the keys.
>Then put a Dictionary and a Set inside a Dictionary with the Dictionary as
>the key.
>If you can do a single thing of what I wrote here you are a good C++
>programmer.
I've created dictionaries having arbitrary element and key types (including
self referential types) in the *C* programming language.
In fact, I did them in my very first C programming project as an undergraduate
freshman, in which I had to implement an interpreter for a small PostScript
like language. In that language, it was possible to create dictionaries
that contain keyword and value pairs, where the values can be of dictionary
type.
>All this can be done in 10 minutes in Smalltalk (if lazy).
Yeah, and that's about how long it will take the executable to process
ten dictionary items.
Kaz Kylheku
In article <Pine.A41.3.95.971230...@acis.mc.yu.edu>,
Joshua Waxman <jwa...@ymail.yu.edu> wrote:
>> In C++ there is no way to handle overflow of integers.
>
>accordingly.
That is absurd. Overflow invokes undefined behavior in C++. To check
for sign reversal, you would have to depend on a particular platform's
handling of overflow. On two's complement systems, overflow on addition or
subtraction can be detected by examining the most significant bit of the
result and those of the operands. This isn't true in general, however.
It's possible to determine whether a given operation will occur by
writing a test expression (or assertion) which itself does not invoke
overflow.
Robert Dewar
<<> In C++ there is no way to handle overflow of integers.
Check after each addition to see if you reversed signs, and act
accordingly.
>>
Surely that is wrong, where in the C++ standard can you find a guarantee
on results obtained following signed numeric overflow?
Kaz Kylheku
In article <dewar.883523608@merv>, Robert Dewar <de...@merv.cs.nyu.edu> wrote:
><<> In C++ there is no way to handle overflow of integers.
>
>accordingly.
>>>
>
>Surely that is wrong, where in the C++ standard can you find a guarantee
>on results obtained following signed numeric overflow?
Failing that, you can search the help materials in Developer Studio 97.
<g> :)
Joshua Waxman
On Tue, 30 Dec 1997, firewind wrote:
> On Tue, 30 Dec 1997, Joshua Waxman wrote:
>
> > On Mon, 29 Dec 1997, Guillermo Schwarz wrote:
> > > very poorlanguage. You can't know how many bits does an int have. Or if long
> > > is actually bigger
> > > than int.
>
> > You can't? How about sizeof(int) and if(sizeof(int) < sizeof(long))
>
> sizeof(int) gives the size in bytes, which you need to multiply by
> CHAR_BIT to get the number of bits.
>
> > > You can't ask an structure how many fields does it have.
> >
> > True. But structures in C++ tend to have a constant number of fields, no?
>
> And I'm curious as to the usefulness of this, anyway. How can you use a
> structure that you don't know the layout of?
Well, if you had a Stack structure, which has a variable number of fields,
you can still know the basic layout of it and thus use it, but it would be
useful to know how many stack elements there are. C++, of course,
might do this with a structure containing a linked list of constant sized
elements, and in this case the size is known or can easily be determined.
>
> > > In C++ there is no way to handle overflow of integers.
> >
> > Check after each addition to see if you reversed signs, and act
> > accordingly.
>
> What about unsigned arirthmetic? What if sign reversal is possible (but
> not garunteed) in this expression, without any overflow?
>
He said integers, and int without any modifier is signed. I was talking in
terms of addition, and when you add or multiply by positive numbers, I
would expect the only way to change sign is with overflow. If a newgative
number you are adding, sign change is possible, but then we wouldn't worry
about overflow. Anyway, probably the best way to handle this is to make
classes Integer, and UnsignedInteger, overload operators, and let the
internals worry about checking for overflow conditions.
By the way, it is spelled *guaranteed*.
Josh Waxman
Joshua Waxman
On 30 Dec 1997, Kaz Kylheku wrote:
> In article <Pine.A41.3.95.971230...@acis.mc.yu.edu>,
> Joshua Waxman <jwa...@ymail.yu.edu> wrote:
> >> In C++ there is no way to handle overflow of integers.
> >
> >Check after each addition to see if you reversed signs, and act
> >accordingly.
>
> That is absurd. Overflow invokes undefined behavior in C++. To check
> for sign reversal, you would have to depend on a particular platform's
> handling of overflow. On two's complement systems, overflow on addition or
> subtraction can be detected by examining the most significant bit of the
> result and those of the operands. This isn't true in general, however.
>
> It's possible to determine whether a given operation will occur by
> writing a test expression (or assertion) which itself does not invoke
> overflow.
Oops! Thanks for pointing that out.
By the way, does your later post indicate that Borland guarantees
that overflow will wrap around?
Also, clue me in on "undefined behavior." From the rest of your postr, I
would call this "implementation dependant behavior." What are the various
degrees and meanings of evil things in C++?
Josh Waxman
Robert Dewar
Kaz says
<<That is absurd. Overflow invokes undefined behavior in C++. To check
for sign reversal, you would have to depend on a particular platform's
handling of overflow. On two's complement systems, overflow on addition or
subtraction can be detected by examining the most significant bit of the
result and those of the operands. This isn't true in general, however.
It's possible to determine whether a given operation will occur by
writing a test expression (or assertion) which itself does not invoke
overflow.
>>
Yes, it is possible, but gruesome, especially for multiplication. And rather
silly, since at the hardware level it is typically easy to detect overflow.
The lack of overflow detection in a language like C++ seems a clear and
annoying ommission (actually I had been told this was fixed in the latest
standard, but I guess that was false information). Anyway, the Ada approach
makes far more sense than appealing to highly dubious assertions!
Dann Corbit
Robert Dewar wrote in message ...
nice. But we can make the same sort of decisions for other languages and use
efficient fixed sizes or new types of our own design. Instead of growing a
bit at a time, we grow in jumps. Now, if I declare a type of 60 bits of
precision, am I guaranteed that it will never overflow? Obviously, I still
have to perform the same analysis that I would need for any other software
system. Getting exactly what you want is much easier, though.
Exception handling is not perfect a solution either. It is even better to
engineer a solution where the types used never extend beyond the design range.
If there is any possibility that a counter of type short is not large enough,
use long. And if there is any chance that long is too small, use a larger
type or invent one. Same for float, double, long double.
Exception handling for memory or disk problems makes excellent sense, since
those are often limited resources of unknown quantity. But integer overflow
and the like is an indication of a serious flaw in the original physical
design.
If an exhaustive test of the domain is applied, using assert() is as good as
any other method, and it has the added benefit of documenting the thinking of
the software analyst very concisely. However, with more than 5 bytes of data
length in the domain, exhaustive testing is prohibitive.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software? Algorithms? Pubs? http://www.infoseek.com
Eric Clayberg
Kaz Kylheku <bi...@cafe.net> wrote in article
<68btos$g7d$1...@brie.direct.ca>...
>
> Who writes high-performance applications in Smalltalk?
Lots of people do. Why do you ask? Smalltalk is used for building
everything from large, mission critical business systems, to tiny embedded
systems. For more information, you might want to visit the Smalltalk
Industry Council's web site at http://www.stic.org/.
> >All this can be done in 10 minutes in Smalltalk (if lazy).
>
> Yeah, and that's about how long it will take the executable to process
> ten dictionary items.
You obviously know a great deal about C++. You might wish to educate
yourself further about Smalltalk before taking gratuitously silly pot shots
at it. You might be interested to know, for example, that compiled versions
of Smalltalk (like Smalltalk MT) can be used to create very small,
high-performance apps that are just as fast as anything you can build with
C++. Even the various JIT-based Smalltalk dialects on the markets, while
admittedly not as fast as C++, are not "slow" by any means and are more
than adequate to the task of building mission critical software systems.
-Eric
Robert Dewar
<<He said integers, and int without any modifier is signed. I was talking in
terms of addition, and when you add or multiply by positive numbers, I
would expect the only way to change sign is with overflow. If a newgative
number you are adding, sign change is possible, but then we wouldn't worry
about overflow. Anyway, probably the best way to handle this is to make
classes Integer, and UnsignedInteger, overload operators, and let the
internals worry about checking for overflow conditions.
>>
Unfortunately, the point is that there is no reasonable way to program
these internals in an efficient portable manner in C++
David Thornley
In article <01bd14b4$dc6f6a80$6428...@carla.ici.net>,
Alicia Carla Longstreet <ca...@ici.net> wrote:
>Robert Dewar wrote:
>: John says
>
>: <<So now a "language" is not defined by the compiler -- or even by the
>: preprocessor+compiler+linker+etc, as some have it...
>: I am forbidden by a piece of paper from calling a function 'memfoo'!
>
>: Of course the answer is that the language is defined by the standard.
>What
>: is surprising is your exclamation mark at the end of a statement that
>should
>: be common understanding for any programmer.
>
>Even if the Standard does define the language, it only did so on the day
>the standard was finalized. Languages, even programming language, evolve
>
their newsgroup, and I've noticed that there are two basic responses to
complaints that "the compiler does X":
1. Sorry, but the compiler is conforming to the standard. You'll
have to change your code.
2. Sorry, you're right, the compiler isn't conforming to the standard.
We'll have that changed next version/next month with a patch. In the
meantime, here's a workaround.
Codewarrior, as shipped from the factory, is not a standard C compiler,
but it can be made to be one (modulo bugs) with a few option selections.
If I write standard C, I can use it with Codewarrior, or I can move it
to a Unix box and use gcc, or I can....
Think of the standard as what you can count on in the language. The
actual language a given compiler will accept is different, of course,
and the range of C "dialects" increases with every release with a
new feature or pragma or whatever. If you are writing a particular
program for use with one version of one compiler on one system
(and I haven't done that in a *long* time), you can go wild with
the extensions. If you might want to reuse some of your code
sometime, be careful with them.
--
David H. Thornley | These opinions are mine. I
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
Keith G. Murphy
David Thornley wrote:
[snip good stuff]
>
> Think of the standard as what you can count on in the language. The
> actual language a given compiler will accept is different, of course,
> and the range of C "dialects" increases with every release with a
> new feature or pragma or whatever. If you are writing a particular
> program for use with one version of one compiler on one system
> (and I haven't done that in a *long* time), you can go wild with
> the extensions. If you might want to reuse some of your code
> sometime, be careful with them.
>
frame within which code will be forced to run. Witness this little
thing called the Y2K problem...
David Thornley
In article <68c66j$ei3$1...@client3.news.psi.net>,
Dann Corbit <dco...@solutionsiq.com> wrote:
>Robert Dewar wrote in message ...
>>Kaz says
>>
>><<That is absurd. Overflow invokes undefined behavior in C++. To check
>>for sign reversal, you would have to depend on a particular platform's
>>handling of overflow. On two's complement systems, overflow on addition or
>>subtraction can be detected by examining the most significant bit of the
>>result and those of the operands. This isn't true in general, however.
>>
>>It's possible to determine whether a given operation will occur by
>>writing a test expression (or assertion) which itself does not invoke
>>overflow.
>>>>
>>
>>
>>Yes, it is possible, but gruesome, especially for multiplication. And rather
>>silly, since at the hardware level it is typically easy to detect overflow.
>
of any size, subject of course to machine limitation. I can write a
program that will handle integers accurately, without overflow. The
downside is the performance hit, but there are ways around that.
First, I can introduce spot checks to see if my integers are staying
in the "fixnum" range rather than the "bignum" range; second, I can
use declarations to tell the compiler to optimize performance at the
expense of safety. It fits in well with my attitude of getting it
working without worrying about low-level optimization.
John Porter
Dann Corbit wrote:
>
> Now, with Ada we can simply declare precision, and I will agree this is very
> nice. But we can make the same sort of decisions for other languages and use
> efficient fixed sizes or new types of our own design. Instead of growing a
> bit at a time, we grow in jumps. Now, if I declare a type of 60 bits of
> precision, am I guaranteed that it will never overflow? Obviously, I still
> have to perform the same analysis that I would need for any other software
> system. Getting exactly what you want is much easier, though.
>
> Exception handling is not perfect a solution either. It is even better to
> engineer a solution where the types used never extend beyond the design range.
> If there is any possibility that a counter of type short is not large enough,
> use long. And if there is any chance that long is too small, use a larger
> type or invent one. Same for float, double, long double.
Of course in C++ it would be pretty easy to make a class that implements
integers of unlimited (dynamic) size. Making it efficient would be a
little
harder...
John Porter
Jon S Anthony
John Porter <jdpo...@min.net> writes:
> Of course in C++ it would be pretty easy to make a class that implements
> integers of unlimited (dynamic) size. Making it efficient would be a
> little
> harder...
There is nothing special about C++ in this respect. You can do this
in anything (in particular the Ada take would in all likelihood look
very close to the C++ take). Now, OTOH (as someone else already
mentioned), you already get this for free in Common Lisp. Of course
making it efficient is rather more than "a little harder"...
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Robert Dewar
David says
<<My preferred solution is the Common Lisp one. It will handle integers
of any size, subject of course to machine limitation. I can write a
program that will handle integers accurately, without overflow. The
downside is the performance hit, but there are ways around that.
>>
Sure, but you should be able to program this easily in any language.
Unfortunately, in practice it is often difficult to program efficient
multiple precision arithmetic because none of the common languages
provide the necessary primitives, e.g.
Add A+B generating sum, carry
Add A+B+carry, generating sum, carry
In addition you need
Multiply single length giving double length
Divide single into double giving single quotient and single remainder
COBOL has the last two, but other languages do not. Your compiler may
recognize some idiom such as
x = (long)a + (long)b;
or
X := Long_Integer (A) + Long_Integer (B);
(C or Ada)
and generate reasonable code, but it may well not, and you may end up with
a horror, particularly if the addition is replaced by multiplication in
the above assignments.
Brock
firewind wrote in message ...
<<snipp
>And I'm curious as to the usefulness of this, anyway. How can you use a
>structure that you don't know the layout of?
<<
I would think that an OO programmer in particular would not want to know
anything about the implementation(layout) of the object, just the interface.
Joshua Waxman
many fields in the (otherwise unknown) structure. I assume firewind's
question was, assuming you do know the number of fields, but you have no
other clue of what thsoe fields mean, how would you use that data to your
advantage. His words "using the structure" I read as "using the number of
fields for modifying the object."
Josh Waxman
Dann Corbit
Brock wrote in message <68edmi$g46$1...@news2.ispnews.com>...
>
>firewind wrote in message ...
><<snipp
>>And I'm curious as to the usefulness of this, anyway. How can you use a
>>structure that you don't know the layout of?
><<
>
>I would think that an OO programmer in particular would not want to know
>anything about the implementation(layout) of the object, just the interface.
Except, of course, when he/she is designing the class. Before the complexity
gets abstracted, someone has to deal with it.
firewind
On Wed, 31 Dec 1997, Brock wrote:
> firewind wrote in message ...
> <<snipp
> >And I'm curious as to the usefulness of this, anyway. How can you use a
> >structure that you don't know the layout of?
> <<
>
> I would think that an OO programmer in particular would not want to know
> anything about the implementation(layout) of the object, just the interface.
But the poster complained that there was no way to find out how many
things were -in- the object. If you don't want and don't need to know the
layout, why would you need to know -this-?
Robert Dewar
David said
<<Think of the standard as what you can count on in the language. The
actual language a given compiler will accept is different, of course,
and the range of C "dialects" increases with every release with a
new feature or pragma or whatever. If you are writing a particular
program for use with one version of one compiler on one system
(and I haven't done that in a *long* time), you can go wild with
the extensions. If you might want to reuse some of your code
sometime, be careful with them.
>>
Even if you are using one particular compiler on one particular system,
you should not go "wild" using extensions. There are definite downsides
to using extensions:
1. They are often ill defined compared to the standardized features
2. There is no guarantee that they will continue to work in the same
way from one version of the compiler to another
3. Standard tools for the language that might otherwise be usable may not
be able to handle the extensions.
4. Programmers who know the language well may still not know the
extensions, so the resulting program may be less maintainable.
This does not mean that extensions should never be used, just that the
programmer should
(a) be very aware of what is and is not an extension.
(b) use extensions judiciously when they are definitely useful (i.e.
it would be much harder or impossible to perform the required
function without using the extensions.
As an example of a worthwhile extension, consider the nested functions
of GNU C. These are quite portable, in that they can be used on any
GCC implementation, are well defined, and are extremely useful (it
continues to amaze me that C and C++ omit this very useful feature, well
known, and well understood to be useful, since the days of Algol-60).
(note that nested functions are particularly valuable in the
context of multi-threaded programs, since they allow the use of non-local
variables that are thread specific.
Patricia Shanahan
Robert Dewar wrote:
...
> This does not mean that extensions should never be used, just that the
> programmer should
>
> (a) be very aware of what is and is not an extension.
>
> (b) use extensions judiciously when they are definitely useful (i.e.
> it would be much harder or impossible to perform the required
> function without using the extensions.
>
> As an example of a worthwhile extension, consider the nested functions
> of GNU C. These are quite portable, in that they can be used on any
> GCC implementation, are well defined, and are extremely useful (it
> continues to amaze me that C and C++ omit this very useful feature, well
> known, and well understood to be useful, since the days of Algol-60).
> (note that nested functions are particularly valuable in the
> context of multi-threaded programs, since they allow the use of non-local
> variables that are thread specific.
I would add:
(c) Prominently document the use of extensions. If the extension is
critical to the structure of the program, make sure it is discussed in
the highest level of program documentation.
For example, if your C-with-gcc-extensions program does depend on
nested functions, say so somewhere where anyone considering compiling
the program is likely to see it, so they won't be trapped into
thinking it is a standard conforming program.
Patricia
Shelly Mujtaba
the truth of this whole matter is none...what will eventually pay off is
your application modeling skills. If you can take a problem and model an
elegant solution for it ...any language will do. I have created
applications in Java and then recreated them in smalltalk and c++ and what
really helped was not my knowledge of the language but understanding the
model. but then if we are discussing career as a "coder" ...well...
regards
shelly
--
she...@objsoft.com
http://www.objsoft.com
Serious Tools for Serious Java Developers
Tor Iver Wilhelmsen
On Sat, 27 Dec 1997 10:11:55 -0400, Guillermo Schwarz
<gsch...@netup.cl> uttered:
>That's true. C is not object oriented. C++ is just an Smalltalk
>wannabe.
Um, nope. Stroustrup missed the language Simula, so C++'s OO roots
like in the language Simula-67. For a Smalltalk wannabe, try
Objective-C, which essentially is "C with embedded Smalltalk
statements". Other OO C-like languages include LPC, C+@ ("cat"), TADS
etc. The "language list" is posted to comp.lang.misc every now and
then, and is accessible via the web, though I do not have an URL
handy.
--
"In practical terms, borders are little more than lines on a map."
- FAO lady, "The X-Files"
to...@online.no http://www.pvv.org/%7etoriver/
Robert Dewar
Jon said
<<There is nothing special about C++ in this respect. You can do this
in anything (in particular the Ada take would in all likelihood look
very close to the C++ take). Now, OTOH (as someone else already
mentioned), you already get this for free in Common Lisp. Of course
making it efficient is rather more than "a little harder"...
>>
No, it is easier to do this in Ada because of the exception support.