Why do you like C more than other programming languages?

[istillshine]

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I could not understand why people are using and talking about other
programming languages.

[santosh]

is*********@gmail.com wrote:

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them.

Then you are probably prejudiced. Each language has certain merits and
demerits. You must try not to approach other languages from a C point
of view and vice versa. You will likely end up judging them unfairly or
inappropriately.

Is it because C was my first programming language?

No. It's probably because you are, despite what you might tell yourself,
probably looking to criticise.

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I could not understand why people are using and talking about other
programming languages.

Because some types of programming are made more efficient by languages
specifically meant for them. C is a general purpose language and while
it can theoretically be programmed to do any computation possible on a
Turing machine, many tasks are rendered easier to accomplish with
specific languages. You will appreciate this if you attempt widely
varied programming tasks.

[Walter Roberson]

In article <ed**********************************@y38g2000hsy. googlegroups.com>,
<is*********@gmail.comwrote:

>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

>I could not understand why people are using and talking about other
programming languages.

One uses the best tool for the task at hand.

At work, these days I mostly use two programming languages,
MATLAB and Maple.

MATLAB has been designed to provide interactive prototyping of a mix of
array operations and graphics; it is suitable for the needs of my major
task because that major task involves R&D of a package for visualizing
the results of performing various mathematical operations upon data
sets. Formal design is not especially practical in our environment,
as we change our mind several times a day about what we're trying to do,
as our experiences or further thoughts or additional papers tell us
more about what does or does not work, so a prototyping language is
appropriate for the task. When we've figured out what we want done
and how it should be done, a team will take it over and re-write it
in a structured language such as C or C++.

Maple I use to compute symbolic formulae. It has an extensive
library of symbolic manipulation routines; it would be completely
impractical for us to use C to write routines to do complicated
symbolic integration. No point in re-inventing the wheel!
I don't use Maple for any kind of hard-core numeric evaluation
of data: I use it to figure out good ways to express formulae.
For example, for solving simultaneous non-linear equations
and then finding a compact form for expressing the parametric
form of the intersection.

--
"Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us." -- Ecclesiastes

[Ron Ford]

On Tue, 8 Jul 2008 03:31:41 +0000 (UTC), Walter Roberson posted:

In article <ed**********************************@y38g2000hsy. googlegroups.com>,
<is*********@gmail.comwrote:

>>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

>>I could not understand why people are using and talking about other
programming languages.

One uses the best tool for the task at hand.

At work, these days I mostly use two programming languages,
MATLAB and Maple.

MATLAB has been designed to provide interactive prototyping of a mix of
array operations and graphics; it is suitable for the needs of my major
task because that major task involves R&D of a package for visualizing
the results of performing various mathematical operations upon data
sets. Formal design is not especially practical in our environment,
as we change our mind several times a day about what we're trying to do,
as our experiences or further thoughts or additional papers tell us
more about what does or does not work, so a prototyping language is
appropriate for the task. When we've figured out what we want done
and how it should be done, a team will take it over and re-write it
in a structured language such as C or C++.

Maple I use to compute symbolic formulae. It has an extensive
library of symbolic manipulation routines; it would be completely
impractical for us to use C to write routines to do complicated
symbolic integration. No point in re-inventing the wheel!
I don't use Maple for any kind of hard-core numeric evaluation
of data: I use it to figure out good ways to express formulae.
For example, for solving simultaneous non-linear equations
and then finding a compact form for expressing the parametric
form of the intersection.

I thought Walter might express an affinity to perl, which I've seen him
post when asked a question that needed a language appropriate to perl's
purview.

You never really can get away from C, try as you will. I have affairs with
syntaxes but find the influence of C is always right under the hood. In my
syntax of choice, fortran, they defined an ISO_C_BINDING last standard
around. It's public comments now for the new standard, so it's getting a
little thick there.
--
Democracy is the art and science of running the circus from the monkey
cage.
H. L. Mencken

[Dand]

<is*********@gmail.comwrote in message
news:ed**********************************@y38g2000 hsy.googlegroups.com...

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I could not understand why people are using and talking about other
programming languages.

I think on any low-level tasks its by far the best choice and in many cases
the only real alternative to assembly.

As for high-end PC software, I would probably say no. Try programming even a
simple windows API ap and you will see why, 1000 lines of code just to get
one window to appear.

[jacob navia]

Dand wrote:

<is*********@gmail.comwrote in message
news:ed**********************************@y38g2000 hsy.googlegroups.com...

>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I could not understand why people are using and talking about other
programming languages.

I think on any low-level tasks its by far the best choice and in many cases
the only real alternative to assembly.

As for high-end PC software, I would probably say no. Try programming even a
simple windows API ap and you will see why, 1000 lines of code just to get
one window to appear.

This is not true.

You can use the windows API in C. Many compilers under windows
will generate a windows skeleton for you. lcc-win, for instance
needs 2-3 clicks in a "wizard" and you get all the basic framework
written for you.

The advantage of using the windows API is that you are NOT tied to
a specific library and you get the advantage of using and reusing
the same code in all versions of windows.

I started writing the IDE of lcc-win under windows 16 bits. It was
ported to 32 bits, then to 64 bits with much less effort than it
would have been if I was dependent on a third party library.

Take MFC for instance. The last version of it dated from
1998. Recently (some months ago) Microsoft decided to bring a new
update, the first since 1998. If you program using MFC you
would have been forced to use the API anyway since the library
wasn't updated.

Other libraries like Borland's or the hundreds of libraries that
were developed have all disappeared. Programming in C with the
raw API is a guarantee that your code will survive.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Dand said:

<snip>

Try programming
even a simple windows API ap and you will see why, 1000 lines of code
just to get one window to appear.

You are exaggerating by a very, very, very great margin. To get one window
to appear, you need only call CreateWindow (or, if it is already created,
ShowWindow) - one line of code. If it is the *first* window of its type to
appear, then you must first set up an appropriate window class (not the OO
kind) - i.e. define and populate a reasonably small struct - and then call
a function to register the class.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

is*********@gmail.com said:

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

There are many colours around: Red, PURPLE, GREY, and so on. I tried to
like Red and GREY, but ended up criticising them. Is it because I've
always been very fond of Green?

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I like C because it's easy, which in turn means I can write stuff in C
pretty quickly that would take me longer in some other language.

I could not understand why people are using and talking about other
programming languages.

Cultural diversity is a Good Thing.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

<is*********@gmail.comwrote in message
news:ed**********************************@y38g2000 hsy.googlegroups.com...

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

I like C because, comparatively, it is small,

C is deceptively small. It's so small that some ten years on hardly anyone
has managed to create a full compiler for the latest standard... and some
compilers have lists of options that are bigger than your entire
application!

>efficient

It's not bad, but when I needed speed I had to use asm code.

>, and able to handle large and complex tasks.

Yeah, it's able to.

I think it wasn't for it's #define statement to program your way of trouble,
C's usefulness would be seriously diminished.

In fact #define may well be the most important feature in C. (Although,
#define may also have hindered C's normal development as a language:
everytime someone proposes a genuine improvement, someone else will come up
with an ugly #hack, sorry, #define, macro to do the same job nearly, but not
quite, as well.)

--
Bartc

[Walter Roberson]

In article <1r*****************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:

>On Tue, 8 Jul 2008 03:31:41 +0000 (UTC), Walter Roberson posted:

>At work, these days I mostly use two programming languages,
MATLAB and Maple.

>I thought Walter might express an affinity to perl, which I've seen him
post when asked a question that needed a language appropriate to perl's
purview.

Yes, I use perl when I have something perl-ish to do. However,
my job duties changed a few years ago, from systems work to R&D,
so it is now far less common that perl is the right tool for
what I am doing these days; it was a good tool when I needed to do
practical text extraction and reporting such as using SNMP probes
to detect whether someone had illicitly moved a device to another port
in our network.
--
"It is surprising what a man can do when he has to, and how
little most men will do when they don't have to."
-- Walter Linn

[Kaz Kylheku]

On 2008-07-08, is*********@gmail.com <is*********@gmail.comwrote:

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

No, that's not the reason. It's because if those are the alternatives you are
looking at---C++, Pascal, Java---then of course C looks damn good.

I could not understand why people are using and talking about other
programming languages.

Maybe because there are languages in which you can write things which would
require ten to one hundred times as much syntax in C, not counting the
code in the libraries that would have to be supplied to actually make that
syntax work.

Are you retarded or what?

[Linonut]

* Dand peremptorily fired off this memo:

<is*********@gmail.comwrote in message
news:ed**********************************@y38g2000 hsy.googlegroups.com...

>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I could not understand why people are using and talking about other
programming languages.

I think on any low-level tasks its by far the best choice and in many cases
the only real alternative to assembly.

As for high-end PC software, I would probably say no. Try programming even a
simple windows API ap and you will see why, 1000 lines of code just to get
one window to appear.

Huh? Try gtk+, then.

I like C++ a lot, but have lately taken to writing stuff in C and then
wrappering it.

Python is not bad, though indenting the wrong lines of code by accident
can screw things up.

Perl is nice for word manipulations.

Ruby, well, I haven't used it enough, but....

I still prefer C/C++ -- the compile-time type-checking is very nice.

--
VMS is like a nightmare about RXS-11M.

[Linonut]

* jacob navia peremptorily fired off this memo:

You can use the windows API in C. Many compilers under windows
will generate a windows skeleton for you. lcc-win, for instance
needs 2-3 clicks in a "wizard" and you get all the basic framework
written for you.

The advantage of using the windows API is that you are NOT tied to
a specific library and you get the advantage of using and reusing
the same code in all versions of windows.

Yeah, but, dude! It's /Windows/!!!

Other libraries like Borland's or the hundreds of libraries that
were developed have all disappeared. Programming in C with the
raw API is a guarantee that your code will survive.

At least until Microsoft gets Windows Presentation Foundation working.

Or you can adopt cross-platform GUI library's such as Qt, gtk, Fox,
Tk/Tcl, or wxWidgets.

--
No one becomes depraved in a moment.
-- Decimus Junius Juvenalis

[Harold Aptroot]

<snip>

>Other libraries like Borland's or the hundreds of libraries that
were developed have all disappeared. Programming in C with the
raw API is a guarantee that your code will survive.

At least until Microsoft gets Windows Presentation Foundation working.

</snip>

If they decide to deprecate the whole raw windows API then programmers will
just ignore that version of windows and normal users will try to avoid it
because none of the programs they like work on it. In short, it will fail
even faster and more completely than Vista
So why would they do that? It'll only cost them money

[jacob navia]

Harold Aptroot wrote:

<snip>

>>Other libraries like Borland's or the hundreds of libraries that
were developed have all disappeared. Programming in C with the
raw API is a guarantee that your code will survive.

At least until Microsoft gets Windows Presentation Foundation working.

</snip>

If they decide to deprecate the whole raw windows API then programmers
will just ignore that version of windows and normal users will try to
avoid it because none of the programs they like work on it. In short, it
will fail even faster and more completely than Vista
So why would they do that? It'll only cost them money

Exactly.
C# would not work, neither would .net. They all use at the end
the windows API.

Yes, They will bring new stuff, but... did you know?

I installed a pre-release of VISTA more than a year ago,
and what did I see in C:\ ?

AUTOEXEC.BAT
CONFIG.SYS

Microsoft has sometimes a funny attitude towards compatibility but
it has greatly contributed to their success.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

Dand said:

<snip>

>Try programming
even a simple windows API ap and you will see why, 1000 lines of code
just to get one window to appear.

You are exaggerating by a very, very, very great margin. To get one window
to appear, you need only call CreateWindow (or, if it is already created,
ShowWindow) - one line of code. If it is the *first* window of its type to
appear, then you must first set up an appropriate window class (not the OO
kind) - i.e. define and populate a reasonably small struct - and then call
a function to register the class.

I use the following procedure.
Each window class I will create has its own file. Initially it exports just
one function - RegisterXXXXX, where XXXXX is the name of the class.
That file has a static wndProc routine which the register function passes to
the windowing system. WndProc then calls all the logic of the window - for
simplicity, let's say put up a "Hello World" message.
To use the class the caller calls the register function early on in his
WinMain. Then he creates an instance using CreateWindow and the class name.

A complication is that the main window has to be coded specially. Normally
there will be one call to CreateWindow from WinMain with the main window as
the class, then all the sub-windows are created in response to the WM_CREATE
message, from the main window.

Finally WinMain goes into the message translation loop, where it remains for
the life of the application.

So yes, there is quite a bit of code, but once you get used to the scheme
it's all boiler-plate stuff. Actual logic then gets slotted in.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

Dand said:

<snip>

>Try programming
even a simple windows API ap and you will see why, 1000 lines of code
just to get one window to appear.

You are exaggerating by a very, very, very great margin. To get one window
to appear, you need only call CreateWindow (or, if it is already created,
ShowWindow) - one line of code. If it is the *first* window of its type to
appear, then you must first set up an appropriate window class (not the OO
kind) - i.e. define and populate a reasonably small struct - and then call
a function to register the class.

I use the following procedure.
Each window class I will create has its own file. Initially it exports just
one function - RegisterXXXXX, where XXXXX is the name of the class.
That file has a static wndProc routine which the register function passes to
the windowing system. WndProc then calls all the logic of the window - for
simplicity, let's say put up a "Hello World" message.
To use the class the caller calls the register function early on in his
WinMain. Then he creates an instance using CreateWindow and the class name.

A complication is that the main window has to be coded specially. Normally
there will be one call to CreateWindow from WinMain with the main window as
the class, then all the sub-windows are created in response to the WM_CREATE
message, from the main window.

Finally WinMain goes into the message translation loop, where it remains for
the life of the application.

So yes, there is quite a bit of code, but once you get used to the scheme
it's all boiler-plate stuff. Actual logic then gets slotted in.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[copx]

"Bartc" <[e-mail] im Newsbeitrag news:bV*******************@text.news.virginmedia.c om...

>
<is*********@gmail.comwrote in message news:ed**********************************@y38g2000 hsy.googlegroups.com...

>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

I like C because, comparatively, it is small,

C is deceptively small. It's so small that some ten years on hardly anyone has managed to create a full compiler for the latest
standard...

[snip]

That's because few people tried. Some small company who is specialized
in standard conforming compilers managed to produce a fully conforming
C99 compiler rather quickly.
Thing is, the new C standard is simply irrelevant.
Visit any programming forum / read any programming book, almost
anyone in the industry considers you insane if you write any
new software in C except device drivers and OS kernels and those
things are compiler specific anyway.
If Microsoft, Borland, the companies behind GCC etc. wanted too
they could have released a fully conforming C99 compilers in less
than a year. There was and is simply no interest / profit in doing that.

and some compilers have lists of options that are bigger than your entire application!

...and you can usually ignore them all.

[rahul]

On Jul 8, 7:52*am, [e-mail] wrote:

There are many languages around: C++, JAVA, PASCAL, and so on. *I
tried to learn C++ and JAVA, but ended up criticizing them.

I like C because, comparatively, it is small, efficient, and able to

At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process. I am not trying to demean C but when you are considering
a language, you have to consider both sides of the coin.

handle large and complex tasks.

Agreed. If system as large and complex as Linux Kernel and Windows can
be written in C, pretty much anything can be written in C. But the
point is, how convenient is it going to be writing that "anything".

I could not understand why people are using and talking about other
programming languages.

You won't use a chain-saw to drive a nail, will you? It isn't about
what you can possibly do something in a particular language but its
about how easy it is. Consider perl - a text processing program
written in perl is way, way shorter than the equivalent written in
C(generally). But no one would consider writing a device driver in
perl.

At the end of the day, its not the language but the programmer.

[Richard Heathfield]

rahul said:

On Jul 8, 7:52 am, [e-mail] wrote:

>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them.

>I like C because, comparatively, it is small, efficient, and able to

At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

No, the portability loss is inherent in the nature of those tasks.

<snip>

At the end of the day, its not the language but the programmer.

At the end of the day, it's the language, the programmer, the team, the
environment, the specification, the design, the testing, the budget, the
schedule, and the boss. All must be right for the task at hand to succeed.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

copx wrote:

"Bartc" <[e-mail]:

.... snip ...

>

>C is deceptively small. It's so small that some ten years on
hardly anyone has managed to create a full compiler for the
latest standard...

.... snip ...

>
If Microsoft, Borland, the companies behind GCC etc. wanted
too they could have released a fully conforming C99 compilers
in less than a year. There was and is simply no interest /
profit in doing that.

The basic reason is that, back in the 1990 era, compilers sold for
considerable dollars. Today they are generally free. This greatly
reduces the profit incentive.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[copx]

"CBFalconer" <cb********@yahoo.comschrieb im Newsbeitrag news:48***************@yahoo.com...

copx wrote:

>"Bartc" <[e-mail]:

... snip ...

>>

>>C is deceptively small. It's so small that some ten years on
hardly anyone has managed to create a full compiler for the
latest standard...

... snip ...

>>
If Microsoft, Borland, the companies behind GCC etc. wanted
too they could have released a fully conforming C99 compilers
in less than a year. There was and is simply no interest /
profit in doing that.

The basic reason is that, back in the 1990 era, compilers sold for
considerable dollars. Today they are generally free. This greatly
reduces the profit incentive.

That's not true. The "professional" version of the Microsoft's
compiler (for example) costs big bugs. Also they DO aim to
support current standards .. namely the current C++ standard,
the OpenMP standard, etc.
It is just C they don't care about. Does any big developer
still sell a plain C compiler? They all sell C++ "Development Studios"
or what they call it which just happen to support some C mode
for legacy apps. This is usually not even managed on the product
page.
Yeah, said for the C programmer, but that's how it is.

[copx]

"copx" <co**@gazeta.plschrieb im Newsbeitrag news:g5**********@inews.gazeta.pl...
[snip].

That's not true. The "professional" version of the Microsoft's
compiler (for example) costs big bugs. Also they DO aim to
support current standards .. namely the current C++ standard,
the OpenMP standard, etc.
It is just C they don't care about. Does any big developer
still sell a plain C compiler? They all sell C++ "Development Studios"
or what they call it which just happen to support some C mode
for legacy apps. This is usually not even managed on the product
page.

"managed" should be "mentioned" here.

[Ian Collins]

copx wrote:

"copx" <co**@gazeta.plschrieb im Newsbeitrag news:g5**********@inews.gazeta.pl...
[snip].

>That's not true. The "professional" version of the Microsoft's
compiler (for example) costs big bugs. Also they DO aim to
support current standards .. namely the current C++ standard,
the OpenMP standard, etc.
It is just C they don't care about. Does any big developer
still sell a plain C compiler? They all sell C++ "Development Studios"
or what they call it which just happen to support some C mode
for legacy apps. This is usually not even managed on the product
page.

"managed" should be "mentioned" here.

While your at it, "costs big bugs" was rather amusing.

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

copx wrote:

>"copx" <co**@gazeta.plschrieb im Newsbeitrag news:g5**********@inews.gazeta.pl...
[snip].

>>That's not true. The "professional" version of the Microsoft's
compiler (for example) costs big bugs. Also they DO aim to
support current standards .. namely the current C++ standard,
the OpenMP standard, etc.
It is just C they don't care about. Does any big developer
still sell a plain C compiler? They all sell C++ "Development Studios"
or what they call it which just happen to support some C mode
for legacy apps. This is usually not even managed on the product
page.

"managed" should be "mentioned" here.

While your at it, "costs big bugs" was rather amusing.

While you're

--
Ian Collins.

[Nick Keighley]

On 8 Jul, 11:00, "Bartc" <[e-mail]:

<[e-mail] in message
news:ed**********************************@y38g2000 hsy.googlegroups.com...

There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them. Is it
because C was my first programming language?

maybe. Try
- a global substitution in a large code base.
(new -NEW_) [perl]
- drawing a picture [python]
- querying a database [SQL]

even things like socket programming are cleaner in say
Python than C. Yes C can bind to libraries that do
these things but it can't do them out of the box.

[prediction 1: someone will submit code to do the above]
[prediction 2: "yes but XXXX can only do these things because of the
libraries" <yawn>]

Uou need to read a lisp book.

I like C because, comparatively, it is small,

C is deceptively small. It's so small that some ten years on hardly anyone
has managed to create a full compiler for the latest standard...

I don't think it's the size that causes the problem. I think
there isn't enough demand for the new standard. The original
C89 has plenty of compilers. I reject your "C is deceptivly small"

and some
compilers have lists of options that are bigger than your entire
application!

:-)

efficient

It's not bad, but when I needed speed I had to use asm code.

really? What was you application (if you're allowed to say)

, and able to handle large and complex tasks.

Yeah, it's able to.

yup. Eg Unix.

I think it wasn't for it's #define statement to program your way of trouble,
C's usefulness would be seriously diminished.

I find this surprising

In fact #define may well be the most important feature in C.

I find this *really* surprising!

(Although,
#define may also have hindered C's normal development as a language:
everytime someone proposes a genuine improvement, someone else will come up
with an ugly #hack, sorry, #define, macro to do the same job nearly, but not
quite, as well.)

99% of my uses for #define fall into two groups

- simple constant definitions
- defines for #ifdef

and I try to keep the second group to a bare minimum.

Another 0.9% comes from hiding __LINE__ and __FILE__
in diagnostic calls.

Otherwise I don't heavily use #define. I don't like code
that does.

I have defined so huge macros that effectivly acted
as templates. Given my time over again I'd probably
have generated the code (it would have made debugging easier).
--
Nick Keighley

Consistency is the last refuge of the unimaginative.
-- Oscar Wilde

[Chris H]

In message <48***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>copx wrote:

>"Bartc" <[e-mail]:

... snip ...

>>

>>C is deceptively small. It's so small that some ten years on
hardly anyone has managed to create a full compiler for the
latest standard...

... snip ...

>>
If Microsoft, Borland, the companies behind GCC etc. wanted
too they could have released a fully conforming C99 compilers
in less than a year. There was and is simply no interest /
profit in doing that.

The basic reason is that, back in the 1990 era, compilers sold for
considerable dollars. Today they are generally free.

Generally they are not free. It is just one or two are.

This greatly
reduces the profit incentive.

GCC is no more C99 than any other others and there is no profit
incentive for GCC

The reason why [almost] no one has done a fully c99 compiler is because
there is no business case for it. There are not enough significant
users who want C99

If there were 99% of the worlds compilers would be C99 by the end of the
year.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris H]

In message
<24**********************************@s50g2000hsb. googlegroups.com>,
rahul <ra*********@gmail.comwrites

>On Jul 8, 7:52*am, [e-mail] wrote:

>There are many languages around: C++, JAVA, PASCAL, and so on. *I
tried to learn C++ and JAVA, but ended up criticizing them.

>I like C because, comparatively, it is small, efficient, and able to

At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process

Portability may not be an issue. A lot of libraries are portable.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[santosh]

Richard Heathfield wrote:

rahul said:

>On Jul 8, 7:52 am, [e-mail] wrote:

>>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them.

>>I like C because, comparatively, it is small, efficient, and able to

At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

No, the portability loss is inherent in the nature of those tasks.

Not if the language happened to provide procedures to accomplish them
across all it's supported environments. Of course, in that case, one is
likely to find that the number of supported environments is adversely
affected.

But IMHO portability is more a context dependant property than something
defined independently and absolutely. If a project is *meant* for just
N platforms and if language A supports all those *and* happens to
portably provide more facilities than language B, which however
supports more than N platforms, then, IMO, language A is
more "portable" than language B for this particular project.

Lots of similar "fuzzy" logic is possible, which computers struggle
with, but humans excel in. :-)

This is why so many languages exist, despite the consternation of the
OP.

<snip>

[Antoninus Twink]

On 9 Jul 2008 at 6:11, Richard Heathfield wrote:

rahul said:

>At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

No, the portability loss is inherent in the nature of those tasks.

That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

[Walter Roberson]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>On 9 Jul 2008 at 6:11, Richard Heathfield wrote:

>rahul said:

>>At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

>No, the portability loss is inherent in the nature of those tasks.

>That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

Rubbish. GTK cannot possibly support graphics, networking
and threading *completely* portably in C because all three of them
are hardware-dependant; GTK can at best support them on a "wide
variety" of platforms that it happens to have been implemented on.

For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?
--
"The study of error is not only in the highest degree
prophylatic, but it serves as a stimulating introduction to the
study of truth." -- Walter Lipmann

[dj3vande]

In article <g5**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

>But IMHO portability is more a context dependant property than something
defined independently and absolutely. If a project is *meant* for just
N platforms and if language A supports all those *and* happens to
portably provide more facilities than language B, which however
supports more than N platforms, then, IMO, language A is
more "portable" than language B for this particular project.

Not "more portable". *As* portable[1], and more useful. (At least
until somebody decides they want the project to support a platform that
doesn't have an implementation of language A.)
dave

[1] Actually, not quite even that. B is still more portable, but not
usefully so in this case. "Equivalently meets the relevant
portability constraints" is kind of a mouthful, but I think it's
what you really want to say here.

--
Dave Vandervies dj3vande at eskimo dot com

EMACS. The editor that OS's are jealous of.

I thought it was the OS that editors were jealous of.
--Curt Schemmel and Dann Corbit in comp.lang.c

[Richard Heathfield]

Walter Roberson said:

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>>On 9 Jul 2008 at 6:11, Richard Heathfield wrote:

>>rahul said:
At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

>>No, the portability loss is inherent in the nature of those tasks.

>>That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

Rubbish.

It's rather sad to see (in the text you quote) that there has been no
improvement in the accuracy of the articles posted by our resident
buffoons. But then, what did we expect? Some people can't be taught.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Antoninus Twink]

On 9 Jul 2008 at 21:20, Richard Heathfield wrote:

>In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>>>That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

It's rather sad to see (in the text you quote) that there has been no
improvement in the accuracy of the articles posted by our resident
buffoons. But then, what did we expect? Some people can't be taught.

Yes Heathfield, carry on living in your dream-world, and I'll carry on
promoting common-sense practicality in this group.

GTK is 100% supported on all Unices, MS Windows and Mac OS X. It's also
widely supported on embedded platforms. That sounds pretty damned
portable to me. Of course, I guess there isn't a version yet for you and
your "friends"' DeathStations, but really, who cares?

[Bartc]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g5**********@canopus.cc.umanitoba.ca...

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>>On 9 Jul 2008 at 6:11, Richard Heathfield wrote:

>>rahul said:
At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

>>No, the portability loss is inherent in the nature of those tasks.

>>That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

Rubbish. GTK cannot possibly support graphics, networking
and threading *completely* portably in C because all three of them
are hardware-dependant; GTK can at best support them on a "wide
variety" of platforms that it happens to have been implemented on.

What's the difference between a portable C program that needs a C
implementation for each platform it runs on, and, say, GTK which also needs
an implementation for each platform it runs on?

For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

Graphics on a text terminal is going to be difficult, not only with GTK.

--
Bartc

[Richard Tobin]

In article <g5**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

>For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

I don't know, but the aalib library allows the display of graphics
using "ascii art", rather in the style of those 1970s line printer
pictures. I have watched part of Blade Runner rendered with this
library, and it's remarkable to say the least.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[robertwessel2]

On Jul 8, 3:50*pm, jacob navia <[e-mail]:

Harold Aptroot wrote:

If they decide to deprecate the whole raw windows API then programmers
will just ignore that version of windows and normal users will try to
avoid it because none of the programs they like work on it. In short, it
will fail even faster and more completely than Vista
So why would they do that? It'll only cost them money

Exactly.
C# would not work, neither would .net. They all use at the end
the windows API.

Why? The new system would just need a version of the .NET runtime
that called whatever system API that was actually there. Think about
Mono, for example, it will run most C# programs (ignoring library
issues) just fine on *nix, with no Windows API in sight. Obvious
exceptions include .NET programs that directly call the Windows API.

OTOH, I agree that it's pretty unlikely that the Windows API is going
to go away any time soon. The MS-DOS API (aka Int 21h) survived the
introduction of the Windows API by better than two decades, and the
Win16 API survived the introduction of Win32 by something like 15
years. Although both are now going away. As for desktop/server OSs,
neither is available on any 64 bit version of Windows (although both
were supported on all 32 bit Oss, including the non-x86 ones, at least
until now). Nor are the DOS or Win16 APIs supported on any version of
Windows CE.

So the Win32 and Win64 APIs will certainly survive in the short/medium
term. But 15 or 20 years from now? Who knows.

[dj3vande]

In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

>is*********@gmail.com wrote:

>There are many languages around: C++, JAVA, PASCAL, and so on. I
tried to learn C++ and JAVA, but ended up criticizing them.

[...]

>Is it because C was my first programming language?

No. It's probably because you are, despite what you might tell yourself,
probably looking to criticise.

I disagree.
If C is the OP's first language and he hasn't learned to use a second
one well, he's probably judging languages by their resemblance to C;
this indicates a limited view that it would be good to get out of, but
it's a bit of a stretch to go from there to "looking to criticise".

There are languages that actually *are* inferior and not just
different, though. If the OP manages to get good at something like
Scheme or Erlang, or Forth, or Smalltalk, and then comes back to C++ or
Java and still hates them, then that criticism will be easier to take
seriously (even though it will probably still say more about the source
of the criticism than the target).
(Moderately amusing aside: The first three or four times I picked up a
project thinking it would use enough C++ features that C didn't have to
provide an excuse to learn C++, I ended up getting frustrated with the
additional complexity of C++ and learning how to make C do what I
thought I wanted C++ for.)
dave

--
Dave Vandervies dj3vande at eskimo dot com

EMACS. The editor that OS's are jealous of.

I thought it was the OS that editors were jealous of.
--Curt Schemmel and Dann Corbit in comp.lang.c

[Richard Heathfield]

Bartc said:

>
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g5**********@canopus.cc.umanitoba.ca...

>In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>>>On 9 Jul 2008 at 6:11, Richard Heathfield wrote:
rahul said:
At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

>>>No, the portability loss is inherent in the nature of those tasks.

>>>That's just total nonsense. For example, GTK is a cross-platform C
library that lets you do all these things completely portably in C.

Rubbish. GTK cannot possibly support graphics, networking
and threading *completely* portably in C because all three of them
are hardware-dependant; GTK can at best support them on a "wide
variety" of platforms that it happens to have been implemented on.

What's the difference between a portable C program that needs a C
implementation for each platform it runs on, and, say, GTK which also
needs an implementation for each platform it runs on?

Platforms for which a C implementation does not exist are very rare.
Platforms for which a GTK implementation does not exist are not so rare.

>For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics
by reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

Graphics on a text terminal is going to be difficult, not only with GTK.

Yeah, that's kinda the point - hardware features are inherently
non-portable, which is why GTK does *not* give you the magical ability to
do graphical stuff completely portably in C.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

ro***********@yahoo.com wrote:

>
OTOH, I agree that it's pretty unlikely that the Windows API is going
to go away any time soon. The MS-DOS API (aka Int 21h) survived the
introduction of the Windows API by better than two decades, and the
Win16 API survived the introduction of Win32 by something like 15
years. Although both are now going away. As for desktop/server OSs,
neither is available on any 64 bit version of Windows (although both
were supported on all 32 bit Oss, including the non-x86 ones, at least
until now). Nor are the DOS or Win16 APIs supported on any version of
Windows CE.

Boy I'm gad I only use POSIX systems!

--
Ian Collins.

[soscpd]

Hello List

Why do you like C more than other programming languages?

I don't. I just like to use the right tool (one can argue here) to get
the job done.
So... where/when use C? Most likely (to me) when you need to build the
tool. To work with development, you can only use C where only c fit.
In this same place (the world), just the standard have not much to do.

Regards
Rafael

[Ian Collins]

Richard Heathfield wrote:

Bartc said:

>What's the difference between a portable C program that needs a C
implementation for each platform it runs on, and, say, GTK which also
needs an implementation for each platform it runs on?

Platforms for which a C implementation does not exist are very rare.
Platforms for which a GTK implementation does not exist are not so rare.

But platforms capable of supporting GTK without an implementation are
less rare. One could argue the same point with sockets, platforms that
support IP and don't use the BSD socket interface are pretty scarce.

>>For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics
by reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

Graphics on a text terminal is going to be difficult, not only with GTK.

Yeah, that's kinda the point - hardware features are inherently
non-portable, which is why GTK does *not* give you the magical ability to
do graphical stuff completely portably in C.

I guess we have to find a way to define portability in terms of
platforms that support a feature.

--
Ian Collins.

[rahul]

On Jul 9, 11:11*am, Richard Heathfield <[e-mail]:

At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

No, the portability loss is inherent in the nature of those tasks.

But had networking and other libraries been standardized for C, it
would have remained same across platforms. The changes will be there
in implementation of libraries on various platforms but source code
portability will still be there.

Regarding nature of the tasks, even addition of two numbers is not a
portable tasks on two platforms depending upon the opcode to be
generated, format of the executable, width of the data bus, width of
the address bus, representation (big, small-endian or the middle one
you mentioned) etc. But the underlying implementation takes care of it
so we call it portable. The same could have been done for the tasks
you were saying are inherently non-portable. In fact, Java and ports
of perl, python etc do that.

[Richard Heathfield]

rahul said:

On Jul 9, 11:11 am, Richard Heathfield <[e-mail]:

At the same time, C is so small that you have to rely on third-party
libraries(graphics, networking, threading etc), losing portability in
the process.

No, the portability loss is inherent in the nature of those tasks.

But had networking and other libraries been standardized for C, it
would have remained same across platforms.

Just because ISO says "here is a standard set of networking functions",
that does NOT mean that hardware manufacturers are suddenly obliged to put
networking hardware onto their engine management system or washing machine
or programmable calculator. The lack of portability is a fact of life.

The changes will be there
in implementation of libraries on various platforms but source code
portability will still be there.

Some de facto partial standards exist, giving a certain amount of very
limited source code portability.

Regarding nature of the tasks, even addition of two numbers is not a
portable tasks on two platforms depending upon the opcode to be
generated, format of the executable, width of the data bus, width of
the address bus, representation (big, small-endian or the middle one
you mentioned) etc. But the underlying implementation takes care of it
so we call it portable. The same could have been done for the tasks
you were saying are inherently non-portable. In fact, Java and ports
of perl, python etc do that.

Really? Okay, pretend I'm from Missouri - show me a Java program that can
open a network connection on my 80286 (which has no IP stack, no network
card, and no Java implementation).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

rahul wrote:

On Jul 9, 11:11*am, Richard Heathfield <[e-mail]:

At the same time, C is so small that you have to rely on
third-party libraries(graphics, networking, threading etc), losing
portability in the process.

No, the portability loss is inherent in the nature of those tasks.

But had networking and other libraries been standardized for C, it
would have remained same across platforms.

Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).

If the C Standard codified interfaces for networking or graphics they
would either have to be left out on implementations targetting these
platforms (thus non-confirming), or create stubs and no-ops for these
routines. Both will break source code portability.

The changes will be there
in implementation of libraries on various platforms but source code
portability will still be there.

Not on all platforms that C intends to target. C (at least as the ISO
Committee envisage) aspires for "maximal" portability, which
essentially means that the language be kept small and easily
implementable, so that compilers can be quickly created for new
systems. If it were to be as ambitious as say C++ or Java, this would
not be possible.

Regarding nature of the tasks, even addition of two numbers is not a
portable tasks on two platforms depending upon the opcode to be
generated, format of the executable, width of the data bus, width of
the address bus, representation (big, small-endian or the middle one
you mentioned) etc. But the underlying implementation takes care of it
so we call it portable. The same could have been done for the tasks
you were saying are inherently non-portable. In fact, Java and ports
of perl, python etc do that.

There is a very great difference (in terms of magnitude) between
implementing basic arithmetic operations and something like a portable
graphics library.

No computer language has built-in facilities for doing all possible
tasks. Each language chooses to implement a subset of tasks when it is
designed, according to the consensus that emerges from the language's
purpose and consideration of various pros and cons.

C has chosen to implement a small subset of tasks so that the language
itself can be easily and widely implemented. Other tasks are either
performed by a sequence of built-in steps or are provided by external
code (which may not be in C).

Other languages have chosen to implement a plethora of features for the
sacrifice of some portability.

It is the task of the programmer to choose the appropriate language for
a task based on availability, requirements, skills, support and so on.

Unfortunately learning only one (or a few) language and expecting it to
provide built-in routines to solve all problems is an easy trap to fall
in. In practise you'll have to mix and match code in many languages if
you want to avoid endless frustration or time wasted in reinventing the
wheel again and again.

[soscpd]

Hello Walter, List

On Jul 9, 1:52 pm, [e-mail] (Walter Roberson)
wrote:

For example, buried somewhere in my basement at home is an RS232
24 x 80 character display terminal which can theoretically do graphics by
reprogramming the font sets via bitmaps. Does GTK *already* support
graphics on that?

Yes. I'm building, right now, one application to one display really
close to your's (but mine has 8x22), graphics enabled, RS232 too. I
can run graphics (on that display) with framebuffer (that is the
project main goal - *already* archived). I can run GTK over this same
framebuffer (but by hand the startup speed's up, and the graphics
interface don't need to be something that user friendly). Anything
that cannot run over GTK will, probably, work better (if not only)
with C and ASM coded directly to do hardware calls. That's
automagically possible, but rarely indicated.
Regards
Rafael

[Ian Collins]

santosh wrote:

rahul wrote:

>On Jul 9, 11:11 am, Richard Heathfield <[e-mail]:

>>>At the same time, C is so small that you have to rely on
third-party libraries(graphics, networking, threading etc), losing
portability in the process.
No, the portability loss is inherent in the nature of those tasks.

But had networking and other libraries been standardized for C, it
would have remained same across platforms.

Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).

Yet the standard includes _Complex and all that wonderful stuff in
<tgmath.hthat programmers of 8 bit micros had (not) been crying out for.

--
Ian Collins.

[santosh]

Ian Collins wrote:

santosh wrote:

>rahul wrote:

>>On Jul 9, 11:11 am, Richard Heathfield <[e-mail]:

At the same time, C is so small that you have to rely on
third-party libraries(graphics, networking, threading etc), losing
portability in the process.
No, the portability loss is inherent in the nature of those tasks.
But had networking and other libraries been standardized for C, it
would have remained same across platforms.

Many systems that C excels in targetting (embedded micros) often do
not have *any* support for network, graphics etc, (think micros in
your car engine or DVD player).

Yet the standard includes _Complex and all that wonderful stuff in
<tgmath.hthat programmers of 8 bit micros had (not) been crying out
for.

True, though tgmath.h isn't required under freestanding implementations.
As Keith said over in comp.std.c, the choices of the Committee don't
always seem logical. I think that complex support was standardised when
directory support was not because there was active demand for the
former from implementors and this was not the case with the latter,
perhaps because there were existing, well known, well implemented APIs
for them (POSIX), while there was no such thing for complex. Of course,
I'm purely speculating here, as I have never been involved with C
standardisation.

Actually rahul (and jacob) have a point. Things like network,
directories, and perhaps even graphics *could* be standardised, perhaps
by having several different overlapping standards (like we have today
with freestanding, hosted, with __STDC_IEC_559__). But it would be a
gigantic task, and mostly duplicating the efforts of existing standards
like POSIX, OpenGL, and would probably remain totally unimplemented by
virtually every implementation, even if the Committee could develop
such a document in the first place. I think what it would bring in
terms of advantages (theoretical portability), would not be sufficient
to justify the duplication of effort. If the adoption of C99 is an
indicator, then standardising things like network etc., would be doomed
from the start.

[Bartc]

"Nick Keighley" <ni******************@hotmail.comwrote in message
news:27**********************************@56g2000h sm.googlegroups.com...

On 8 Jul, 11:00, "Bartc" <[e-mail]:

><[e-mail] in message
news:ed**********************************@y38g200 0hsy.googlegroups.com...

I like C because, comparatively, it is small,

C is deceptively small. It's so small that some ten years on hardly
anyone
has managed to create a full compiler for the latest standard...

I don't think it's the size that causes the problem. I think
there isn't enough demand for the new standard. The original
C89 has plenty of compilers. I reject your "C is deceptivly small"

On the face of it C can be described on the back of an envelope. But I keep
seeing stuff in clc that I had no idea was in the language. Sometimes this
stuff is new even to the C-compiler writer jacob navia!

>It's not bad, but when I needed speed I had to use asm code.

really? What was you application (if you're allowed to say)

It's not a secret, it was a language interpreter I mentioned in clc a few
months back.

I was porting from a language (one of mine) that mixed a C-like semantics
with inline assembler. The compiler for this was very simple and I thought
that 100% C combined with this super-optimisation of modern compilers I kept
hearing about would result in something at least as fast. Then I would also
have a hll implementation that I could tweak and make even faster!

But instead I got a slow-down of 3-4 times, eventually down to 2x slower
with tweaking of the code and using gcc (I never tried ICC). To achieve my
original speed I had to use a separate ASM module (not inline), with
dedicated registers, for the main loop.

I'd also looked at the threaded code methods of gcc (goto plus an array of
&& labels) but this was doing strange things in the generated code.

However with use of ASM and compiler-specific code, and loads of
weird-looking macros (to achieve in C what I'd been doing easily in the
other language), it seemed that C wasn't helping me any. So I've abandoned
the port to C for now, and I'm using my original language. I'm now planning
an interpreter that will be 2-4 times faster than my original; I can't
afford to use C and take a couple of steps back!

--
Bartc

[Bartc]

"santosh" <sa*********@gmail.comwrote in message
news:g5**********@registered.motzarella.org...

rahul wrote:

>On Jul 9, 11:11 am, Richard Heathfield <[e-mail]:

>At the same time, C is so small that you have to rely on
third-party libraries(graphics, networking, threading etc), losing
portability in the process.

No, the portability loss is inherent in the nature of those tasks.

But had networking and other libraries been standardized for C, it
would have remained same across platforms.

Many systems that C excels in targetting (embedded micros) often do not
have *any* support for network, graphics etc, (think micros in your car
engine or DVD player).

DVD players with no graphics are not going to be too popular...

The graphics (video display) is either built-in (to a screen), or present in
the video output.

--
bartc