Re using BREAK in 'C'

[peter green-2]

> All in all I think intrinsic functions should be limited, especially when
> common names are chosen.  It's dangerous to have a lot of reserved names in
> a namespace the user can also create symbols in.
The way to get arround that is to give the intrinsic functions names in
the compiler private namespace (__ prefix in c) and then provide headers
with the compiler that use #define to map user visible names to the
internal names. Gcc does this for varargs support for example.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[PPA]

Gerhard Fiedler wrote:

You need to look at the bigger picture. C didn't become popular because
of PICs. There are many C programs that compile (and run) on any
standard-compliant compiler, on quite different platforms. While
platform differences sometimes need some conditional parts in the code,
it is possible (and common) to write portable C code that compiles on
gcc, VC++ (in C mode) and a number of other compilers and runs on Linux,
Unix, Solaris, Windows, Mac OSX and others (and depending on the amount
of resources and OS support required for the specific program, also on a
bare-metal PIC).

Also, while with Pascal you may be able to port your code from one
Pascal to the other, from one platform to the other, but then you have
two (or more) code bases. With C, even if you have to make adjustments
for a specific platform, you usually integrate them into the code -- and
end up with code that compiles and works on the previously supported
platforms and on the new platform.

Try that with (any) Pascal. The lack of standardization (and of a
standard preprocessor, for the sometimes necessary platform adjustments)
makes this pretty much impossible.

Let me laugh a bit...
I jump into this so funny discussion since I'm an ol'Pascal'er among other activities...
Maybe all of this WAS quite true a while ago, but nowadays we can see that there is a LOT of #IFDEF in C sources to support multiple platforms. Nobody (I think) is coding in "pure" C (or "pure" Pascal) - whatever that means - because everybody want the bells and wistles of the compiler toolchain they have choosen; if they don't manage toolchain specificities (a big work), when they want to change there is always a bigest work to do to adapt their supposed to be "portable" sources...
In Pascal this is the same, a lot of $IFDEF and so on... No less no more.
This is far from "impossible" as you said. I do it every day since TP3. Some of my old libraries still compiles both in TP3 and the latest Delphi. So they are "portable".
What you qualify as "Pascal dialects" for me is nothing different than "C dialects" and now there is a few Pascal ones that survives and the differences are very tight. The more boring work is on adapting libraries for one environment to another one, not on the language by itself.
Pascal (and inheritors) is alive and still growing, thanks. OK, not so popular as C but it is far from RIP.

Gerhard Fiedler wrote:

(I'm not trying to say that "C is better than Pascal" :)

Just a bit ;-) ...

[Olin Lathrop]

PPA wrote:

> Nobody (I think) is coding in "pure" C (or "pure" Pascal) - whatever
> that means -
> because everybody want the bells and wistles of the compiler
> toolchain they
> have choosen; if they don't manage toolchain specificities (a big
> work),
> when they want to change there is always a bigest work to do to adapt
> their
> supposed to be "portable" sources...
> In Pascal this is the same, a lot of $IFDEF and so on... No less no
> more.

I do it a different way.  First, my Pascal has deliberate portability
features built in.  This includes data types that are defined to map in
certain ways to the target hardware or OS and are therefore different on
different implementations.  The rest is done thru our libaries.  We have
abstracted operations that underlying systems do for you, but each does in a
different way.  The real job of porting applications between systems is in
porting this layer once to each system.  The applications then just work.

Since the libraries are designed to be ported, it's not that hard.  I just
checked, and the unique code for the Win32 implementation is under 8500
lines.  This includes I/O, system functions like multi-threading, thread
interlocks, time, etc, except graphics.  There's a whole seperate library
for graphics.  This environment has been to Apollo Aegis, 4 different
flavors of Unix, and Windows.  All this time the applications themselves
haven't changed and just work on all these different systems with virtually
no compile time customizations.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

PPA wrote:

>> You need to look at the bigger picture. C didn't become popular
>> because of PICs. There are many C programs that compile (and run) on
>> any standard-compliant compiler, on quite different platforms. While
>> platform differences sometimes need some conditional parts in the
>> code, it is possible (and common) to write portable C code that
>> compiles on gcc, VC++ (in C mode) and a number of other compilers
>> and runs on Linux, Unix, Solaris, Windows, Mac OSX and others (and
>> depending on the amount of resources and OS support required for the
>> specific program, also on a bare-metal PIC).
>>
>> Also, while with Pascal you may be able to port your code from one
>> Pascal to the other, from one platform to the other, but then you
>> have two (or more) code bases. With C, even if you have to make
>> adjustments for a specific platform, you usually integrate them into
>> the code -- and end up with code that compiles and works on the
>> previously supported platforms and on the new platform.
>>
>> Try that with (any) Pascal. The lack of standardization (and of a
>> standard preprocessor, for the sometimes necessary platform
>> adjustments) makes this pretty much impossible.

> Let me laugh a bit...

This is always good, (almost) no matter the cause :)

> I jump into this so funny discussion since I'm an ol'Pascal'er among
> other activities... Maybe all of this WAS quite true a while ago, but
> nowadays we can see that there is a LOT of #IFDEF in C sources to
> support multiple platforms.

Of course there are. (BTW, it's #ifdef in C.)

Even though many things are standardized, many things can't be in order
to be able to run on different platforms. For those people have to use
the system APIs -- and these are different on different platforms. This
has always been this way, back then and is still so.

> Nobody (I think) is coding in "pure" C (or "pure" Pascal) - whatever
> that means -

You might be surprised. Not sure about Pascal, but there are many people
who do most of their work in standard C or C++, and in such cases only a
small part of an application (if any) deals with the platform
differences and encapsulates them. This part, of course, tends to have a
lot of preprocessor constructs around the system APIs. But the rest is
plain, standard C (or C++) -- which is probably what you call "pure" C
(or C++). So yes, lots of people code in this. I currently spend much of
my day doing just this.

> because everybody want the bells and wistles of the compiler toolchain
> they have choosen; if they don't manage toolchain specificities (a
> big work), when they want to change there is always a bigest work to
> do to adapt their supposed to be "portable" sources...

If you don't write with portability in mind, this may be the case. And
in some cases, it makes sense not to write with portability in mind --
for example, if you don't anticipate that the code will have to be
ported.

I can have all the bells and whistles of the VC++ or gcc toolchain and
code most of the time in standard C or C++. (When I say "most of the
time" I mean in the 99% of the application that are not platform or
compiler specific.) I don't see what the toolchain has to do with
standard or non-standard code.

Of course, if you mean a GUI library, then you're pretty much hosed if
the one you chose doesn't support all your target platforms. If you
started out with MFC and need Linux support, then all compiler
compatibility doesn't help because the GUI support on the different
platforms is different enough to make portability a real challenge.
That's why there are portable GUI libraries that provide the same
interface on different platforms. You better choose one that supports
all your target platforms right from the beginning... independently of
the language you're programming in.


> In Pascal this is the same, a lot of $IFDEF and so on... No less no
> more. This is far from "impossible" as you said. I do it every day
> since TP3. Some of my old libraries still compiles both in TP3 and
> the latest Delphi. So they are "portable".

I'm not sure we mean the same thing with "portable". My C and C++
Windows sources, for example, compile on any standard C or C++ compiler
for Windows -- and there are a bunch, from different vendors. Same goes
for Linux, Unix, Solaris, Apple OSX.

For me, being able to compile the program in different versions of a
compiler of the same vendor is the lowest level; I wouldn't even call
this "portability", it's more like version compatibility. The next level
is being able to compile on compilers from different vendors (on the
same operating system); this maybe I'd start to call portability. Then
come different operating systems and different target processors; here
we get into what I call portability.

So how does this aspect look for Pascal? (This is not a rhetorical
question; I really want to know from someone who uses Pascal portably.)

One application I work on has several 100kLOC that compiles fine on gcc
and VC++ for Linux and Windows, with a very small and isolated part
being compiler and platform specific. Recently we tested the Intel C++
compiler for Windows, and the code compiled without any changes. (We
dropped it, though, because the performance advantages were small, and
the compile times were horrible.) Is this possible with Pascal -- taking
such a complex application, pick another vendor's compiler, and it "just
works"?

> What you qualify as "Pascal dialects" for me is nothing different than
> "C dialects"

Besides some odd vendors of small micro compilers, there aren't really
any C dialects. The few there are are really niche thingies, mostly
restricted to the PIC world (and maybe the one or other small micro, but
I think the PIC compilers are worse than most others in this respect).
In the great scheme of C, they almost play no role at all. Every
compiler that wants to be worth its money has to be standard compatible,
and therefore allows programming in standard C (or C++). Which is more
common as you seem to think.


>> (I'm not trying to say that "C is better than Pascal" :)
>>
> Just a bit ;-) ...

No, I'm not. If you're reading this into my messages, maybe it's because
you're defensive about Pascal. Fact is that Pascal is almost dead in the
professional world. Another fact is that I started serious PC
programming with Pascal. And yet another fact is that I had to give it
up because Pascal is almost dead for most professional purposes. And
part of this thread is about why this is.

I really really didn't like it. Turbo Pascal was miles ahead of anything
else. The IDE was snappy and functional, compilation was fast and the
executables were, too, it was affordable and powerful. But it didn't
make it into the big league, and my guess is that it's about
standardization. Microsoft was and is big enough to be able to make a
vendor-specific language popular (see VB and C#) without a
vendor-independent standard, Borland wasn't and isn't, Delphi
notwithstanding.

It doesn't help pretending that Pascal isn't dead in the professional
world, or make this into yet another "this language is better than that
language" pissing contest... It's about finding out why Pascal, with all
the perceived advantages, didn't make it -- and, arguably, at this
point, has little chance of making it ever.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[William "Chops" Westfield]

On Jul 9, 2009, at 7:28 AM, Olin Lathrop wrote:

> he wants things that look like library calls but that are really  
> intrinsic functions that the compiler understands natively.

This of course was very common in languages before (and other than)  
C.  I've opined before that part of C's success may have been due to  
having the language specification  completely separate from the  
language definition.  That wasn't true of Fortran, it's not true of  
Pascal (one of things that particularly annoyed me about  Pascal was  
that the language's built-in functions got to have more features than  
user-written functions.  Like variable numbers of arguments.)  Indeed,  
I think many languages got "bogged down" trying to define a "complete"  
set of useful library functions.

With C, the standardization of libraries was done separately, much  
later, and with (perhaps) more experience behind the decisions.  
Perhaps.  ("Posix")


> But didn't AT&T (owner of Bell Labs) sell Unix licenses? Not to the  
> general public, but still sell them?

I don't think so.  Not tell MUCH later, anyway (depending on who you  
mean by "not the general public.")  Until the mid-80s, unix was almost  
exclusively found only in universities and research institutes and  
such.  I'm not positive; prior to those times I worked at universities  
and research institutes :-)  Post mid-80s you had the famous "System  
V" (AT&T) vs BSD (Berkeley) wars.  The early 68000 systems (right  
about that same time) had real operating system difficulties.


> Maybe all of this WAS quite true a while ago, but nowadays we can  
> see that there is a LOT of #IFDEF in C sources to support multiple  
> platforms.

Actually, it's MUCH better than it used to be.  Get some code from  
about 1990, and it'll have conditionals for SYSV vs BSD vs (if you're  
luck) PC.  And it'll have LOTS of them, and they're UGLY (remember  
"near" and "far" for pre-386 intel CPUs?)  Post-standards, post-Posix,  
post-gcc there are comparatively minor differences for architecture  
(sometimes), plus what you might expect for difference windowing  
subsystems and so on.

Which is another point.  C *has* been getting better.   The compilers  
and error checking within the compiler has gotten better.  Compilers  
find errors that used to require "lint."  New functions have been  
defined that have better error checking capabilities (not "built it",  
but present) (alas, not always well-thought-out.  There was a whole  
generation of string functions that paid attention to "length" in  
rather useless ways.)   More than that, there's been so much USE of  
the languages that the "unwritten" standards have improved a great  
deal.  Compilers now post warnings about constructs like "if (a = b)",  
because programmers demand it.  They check the types of printf()  
arguments against the format descriptors (which is a really weird  
thing for a compiler that doesn't define printf() to do, but still  
rather useful.)  People are more careful about using explicitly  
defined data types.
That 1990 code wouldn't have had function prototypes.  It wouldn't  
have uint8_t.   It probably wouldn't have nice include files defining  
the APIs.
(Of course, your 1990 programs would have been a lot smaller than  
todays programs...)

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tony Smith-11]

> >> (I'm not trying to say that "C is better than Pascal" :)
> >>
> > Just a bit ;-) ...
>
> No, I'm not. If you're reading this into my messages, maybe it's because
> you're defensive about Pascal. Fact is that Pascal is almost dead in the
> professional world. Another fact is that I started serious PC
> programming with Pascal. And yet another fact is that I had to give it
> up because Pascal is almost dead for most professional purposes. And
> part of this thread is about why this is.
>
> I really really didn't like it. Turbo Pascal was miles ahead of anything
> else. The IDE was snappy and functional, compilation was fast and the
> executables were, too, it was affordable and powerful. But it didn't
> make it into the big league, and my guess is that it's about
> standardization. Microsoft was and is big enough to be able to make a
> vendor-specific language popular (see VB and C#) without a
> vendor-independent standard, Borland wasn't and isn't, Delphi
> notwithstanding.
>
> It doesn't help pretending that Pascal isn't dead in the professional
> world, or make this into yet another "this language is better than that
> language" pissing contest... It's about finding out why Pascal, with all
> the perceived advantages, didn't make it -- and, arguably, at this
> point, has little chance of making it ever.

I still use TurboPascal when fiddling with TurboCNC.

That said, the differences are often just perception, BASIC is for little
kiddies, Pascal for quiche-eating professors, and 'Real Men' (TM) use C.

Years ago I'd write apps for people using either QuickC or QuickBasic (acually
PDS which could do overlays).  If they didn't get the source code I'd do it in
Basic, otherwise they got to choose.  Many insisted on C, even though I then
charged at least twice as much and took twice the time to do it.

The joke was, of course, that once compiled you couldn't tell the difference as
to whether it was in C or Basic.  (I wasn't writing ray-tracers or such things
where C would have been a better choice).

Microsoft wised up with Windows C & Basic, so VB didn't get a compiler, thus
letting the 'Real Men' (TM) get on with the job of doing whatever it is they
do.  Probably telling the VB weenies their language of choice sucks - "Pfft, it
doesn't even compile".

No-one needs the 'power' that C gives you these days, it's all libraries, web
apps and front-ends for SQL databases.  You don't need C for that.

Tony

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

William "Chops" Westfield wrote:

> I've opined before that part of C's success may have been due to
> having the language specification  completely separate from the
> language definition.  That wasn't true of Fortran, it's not true of
> Pascal (one of things that particularly annoyed me about  Pascal was
> that the language's built-in functions got to have more features than
> user-written functions.  Like variable numbers of arguments.)
> Indeed, I think many languages got "bogged down" trying to define a
> "complete" set of useful library functions.

I think this is something that made the porting of compilers rather
easy, and may be one of the reasons why C spread so (comparatively
easily) to many platforms. Especially true in the small micro and bare
metal world, where it's important that it's easy to replace the standard
library functions with custom implementations with little effort.

See for example printf and putch (used by printf) -- it's easy to adapt
the functionality of a standard function (printf), without having to
provide a custom implementation for it, by redefining another standard
function (putch) for your specific system. Which is easily possible
without modifying the compiler itself, even for the user.


>> But didn't AT&T (owner of Bell Labs) sell Unix licenses? Not to the  
>> general public, but still sell them?
>
> I don't think so.  Not tell MUCH later, anyway (depending on who you
> mean by "not the general public.")  Until the mid-80s, unix was
> almost exclusively found only in universities and research institutes
> and such.  

But how did those universities and research institutes get it? Did they
get it for free? I thought they had to buy it.


> They check the types of printf() arguments against the format
> descriptors (which is a really weird thing for a compiler that
> doesn't define printf() to do, but still rather useful.)  

Now /this/ is something that's closely related to what I was talking
about :)

Because how printf works is defined in the standard, even though it's
not part of the compiler, the compiler "knows" what printf is supposed
to do. And so it can do argument checking against the format string,
simply because this is defined in the standard. The compiler doesn't
have to have a built-in implementation of printf to do that -- it simply
will work with any standard implementation of printf.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> You were talking about intent. For a normal library, the compiler
>> doesn't know about intent. For a library with a standardized
>> interface (for example, the C++ STL) the compiler does know about
>> intent.
>
> I think you guys are talking past each other.  I think what Gerhard is
> trying to say, but not doing a good job of it, ...

Of course I'm not doing a good job of it (I'm just Gerhard)... But
luckily I have Olin doing the job of telling the world what I /really/
want to say.

> ... is that he wants things that look like library calls but that are
> really intrinsic functions that the compiler understands natively.  

I don't "want" intrinsics nor has anything I wrote to do with
intrinsics. Has it occurred to you that if I wanted to talk about
intrinsic functions, I'd have done so?

I think I've been pretty clear about the fact that I was talking about
standard libraries (as the part you quoted spells out quite literally),
and in another part I mentioned that I'm talking about the compiler
seeing these libraries in source code form. No talk or thought of
intrinsics, ever, not even close.

> All in all I think intrinsic functions should be limited, especially
> when common names are chosen.  It's dangerous to have a lot of
> reserved names in a namespace the user can also create symbols in.  

In a sensibly designed language, the user wouldn't create names in the
same namespace where the standard library function names are.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[M.L.-2]

On Fri, Jul 10, 2009 at 8:20 AM, Tony Smith<ajsmith@...> wrote:

> Years ago I'd write apps for people using either QuickC or QuickBasic (acually
> PDS which could do overlays).  If they didn't get the source code I'd do it in
> Basic, otherwise they got to choose.  Many insisted on C, even though I then
> charged at least twice as much and took twice the time to do it.
>
> The joke was, of course, that once compiled you couldn't tell the difference as
> to whether it was in C or Basic.  (I wasn't writing ray-tracers or such things
> where C would have been a better choice).
>
> Microsoft wised up with Windows C & Basic, so VB didn't get a compiler, thus
> letting the 'Real Men' (TM) get on with the job of doing whatever it is they
> do.  Probably telling the VB weenies their language of choice sucks - "Pfft, it
> doesn't even compile".

I was under the impression that QuickBASIC "compiled" the ASCII source
code to byte-code and included an interpreter in the EXE?
This is sort of what compiled Perl does now - though there is a real
Perl -> C translator back-end. (B::C) - not that I would compare QB to
Perl.
--
Martin K.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Tony Smith wrote:
> No-one needs the 'power' that C gives you these days, it's all
> libraries, web apps and front-ends for SQL databases.

That's baltantly wrong, of course.  Sure there are a lot of web apps and
such where CPU power is not the limiting factor.  But to say that this is
never the case is rediculous.  Maybe you don't ever run a programs that you
have to wait on because of the sheer number of calculations required, but
that doesn't make it true for everyone.  Programs in that catagory for me
include the Eagle auto router and some image processing utilities.

I recently wrote a program for a customer that performs 50000 relaxation
passes on 10s to 100s of polar grids.  The total run time can be 10s of
minutes or more, depending on the number of thingies installed at a
particular site.  While a hour per customer site installation once is
acceptable, I'm sure the field folks would love it to be faster.

That's just a few examples of the many out there, although only a single one
disproves your blanket statement.

> You don't need C for that.

True.  The language is not the issue as long as it's a truly compiled one
intended for general purpose from the start.  As long as you understand what
goes on underneath and don't do something stupid, most truly compiled
languages with modern compilers will give you about the same performance.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Terry Harris]

On Fri, 10 Jul 2009 09:45:30 -0300, you wrote:

>I think I've been pretty clear about the fact that I was talking about
>standard libraries (as the part you quoted spells out quite literally),
>and in another part I mentioned that I'm talking about the compiler
>seeing these libraries in source code form.

Are you talking about effectively what Hi-Tech OCG does (or tries to)?

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Gerhard Fiedler wrote:
> In a sensibly designed language, the user wouldn't create names in the
> same namespace where the standard library function names are.

That would be nice, but then you get the flip side of library functions
being more special than what the user can write.  That defeats one of the
things you said you liked about C, such as being able to create your own low
level functions (like PUTC or whatever) that are called by higher level
standard library functions like PRINTF.

None of the mainstream languages I've used had a reserved namespace for
standard library functions.  In fact, C is unusual with its notion of
standard library functions.  Some operating systems take care to use special
naming for their routines that are easily avoided by the user, but
unfortunately Unix and Windows are not among them.  The standard C library
routines and Unix routines are particularly bad in this regard.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dave Tweed]

olin_piclist@... (Olin Lathrop) wrote:
> Gerhard Fiedler wrote:
> > In a sensibly designed language, the user wouldn't create names in
> > the same namespace where the standard library function names are.
>
> None of the mainstream languages I've used had a reserved namespace for
> standard library functions. In fact, C is unusual with its notion of
> standard library functions.

I think that's what's special about C relative to most other compiled
languages. Yes, there's a "standard C library", but it is in fact
completely distinct and separable from the language/compiler itself.
You can write major applications -- especially embedded applications --
in C without even once calling a standard library function. I know,
because I've done it. I've even replaced parts of "crt.s" (implicit code
in the library that sets up the environment for and supports the compiled
code, usually in assembly language) without fuss.

Some of the participants in this thread are downplaying the whole notion
of separate compilation with an explicit linking step that is actually a
fairly key part of C. This is what allows you, for example, to replace a
standard library function wtih a custom implementation, again, with little
to no fuss. Suppose you don't need the full-blown functionality of
printf(), with its dependency on the floating-point library, etc. Just
write your own and link it in ahead of the standard library and it will be
used instead.

> Some operating systems take care to use special naming for their routines
> that are easily avoided by the user, but unfortunately Unix and Windows
> are not among them. The standard C library routines and Unix routines
> are particularly bad in this regard.

Well, now you're conflating several issues, few of which have anything to
do with the actual definition of the language. Library naming issues are a
problem in any language.

Again, I think C does fairly well in this area because of the separate
compilation. You can easily limit the scope of any particular set of names
down to a particular file if you need to. Setting up the linking sequence
may then takes some care, and you have to learn how to avoid circular
dependencies at that level. But once a project gets to this level of
complexity, the issues are largely independent of the particular
language(s) in use.

-- Dave Tweed
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Terry Harris wrote:

>> I think I've been pretty clear about the fact that I was talking
>> about standard libraries (as the part you quoted spells out quite
>> literally), and in another part I mentioned that I'm talking about
>> the compiler seeing these libraries in source code form.
>
> Are you talking about effectively what Hi-Tech OCG does (or tries
> to)?

Yes, in a way, and Microsoft, and probably a number of other vendors.
While standard C and C++ are based on the notion of completely
independent translation units, we're talking about how things could (or
should) be, and nothing hinders us to dream ahead a bit :)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Dave Tweed wrote:

> olin_piclist@... (Olin Lathrop) wrote:
>> Gerhard Fiedler wrote:
>>> In a sensibly designed language, the user wouldn't create names in
>>> the same namespace where the standard library function names are.
>>
>> None of the mainstream languages I've used had a reserved namespace
>> for standard library functions. In fact, C is unusual with its
>> notion of standard library functions.

C++ has a namespace "std" for its standard library. The functions in
there are not treated any special (even though, in the sense of the
discussion around built-in vs library, they could be as the compiler can
assume it knows what they are doing). A user may define functions in the
std namespace, or override any of the library functions with his own
implementation. But no reasonable user will define his own symbols in
the std namespace. The namespace is there to avoid name clashes.

Java also has what you can call namespaces for their library functions
(mainly java and javax); they just call them packages. Works similar to
what I described above. It's not such a rare concept.

> I think that's what's special about C relative to most other compiled
> languages. Yes, there's a "standard C library", but it is in fact
> completely distinct and separable from the language/compiler itself.
> You can write major applications -- especially embedded applications
> -- in C without even once calling a standard library function. I
> know, because I've done it. I've even replaced parts of "crt.s"
> (implicit code in the library that sets up the environment for and
> supports the compiled code, usually in assembly language) without
> fuss.

I think pretty much every embedded C developer has done this at one
point or another. (Even though some standard library functions are so
small that deliberately avoiding calling them and instead doing it with
custom code doesn't buy much if anything.)

> Some of the participants in this thread are downplaying the whole
> notion of separate compilation with an explicit linking step that is
> actually a fairly key part of C. This is what allows you, for
> example, to replace a standard library function wtih a custom
> implementation, again, with little to no fuss. Suppose you don't need
> the full-blown functionality of printf(), with its dependency on the
> floating-point library, etc. Just write your own and link it in ahead
> of the standard library and it will be used instead.

Exactly. I think this flexibility is a good part of the popularity of C.


>> Some operating systems take care to use special naming for their
>> routines that are easily avoided by the user, but unfortunately Unix
>> and Windows are not among them. The standard C library routines and
>> Unix routines are particularly bad in this regard.
>
> Well, now you're conflating several issues, few of which have
> anything to do with the actual definition of the language. Library
> naming issues are a problem in any language.

There isn't really anything that would prevent a compiler vendor to ship
a library with its compiler where the Windows API is in namespace
"windows", the Posix API in a namespace "posix" and so on. They don't go
there, I think, because of the extra work required to wrap the Microsoft
etc. headers. (There is the functionality in the standard Microsoft C
headers that depends on the preprocessor, and the C/C++ preprocessor
doesn't know namespaces, so at least for C++, this would probably
require quite some work.)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Tony Smith wrote:

>> It doesn't help pretending that Pascal isn't dead in the professional
>> world, or make this into yet another "this language is better than
>> that language" pissing contest... It's about finding out why Pascal,
>> with all the perceived advantages, didn't make it -- and, arguably,
>> at this point, has little chance of making it ever.
>
> I still use TurboPascal when fiddling with TurboCNC.

Which probably doesn't make up a big chunk of your income.

> That said, the differences are often just perception, BASIC is for
> little kiddies, Pascal for quiche-eating professors, and 'Real Men'
> (TM) use C.

Not sure where the people are that perceive it like this, but not around
where I make my money. VB /is/ a professional tool, so is Delphi. And
nobody in his right mind would use C (or pay for someone using C) for
something these two are usually used.

But compare the "bucks made" with Delphi and other Pascal variants with
the "bucks made" with other languages, and you'll probably see why I
said "dead in the professional world".

This isn't a judgment of the "quality" of the language. It's a fact of
the market.


> Microsoft wised up with Windows C & Basic, so VB didn't get a
> compiler, thus letting the 'Real Men' (TM) get on with the job of
> doing whatever it is they do.  

It's been a long time that Microsoft has last promoted a C compiler.
They do sell a C++ compiler that also (as a rarely used side effect) can
compile C sources. But their heart (and their money) lies with VB and C#
(both running on the same engine), not with C and not with C++.

> Probably telling the VB weenies their language of choice sucks -

No, not really. VB is probably more popular than C++ in the professional
Windows world. C++ is treated like some kind of a step child; many of
the useful RAD features that VB and C# have for GUI development (in the
Visual Studio IDE) don't work with C++. It's probably still there mostly
because of legacy applications that need to be supported, and because
some people develop highly optimized applications where the additional
control a low-level language like C++ provides may be helpful (and they
don't need the GUI RAD features for that).

> No-one needs the 'power' that C gives you these days, it's all
> libraries, web apps and front-ends for SQL databases.  You don't need
> C for that.

Nobody really uses it (professionally) for that. But then, check out
what the SQL databases are written in... Chances are it's not a BASIC or
Pascal dialect. (Which again is not to say they couldn't be; just that
they aren't.)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tony Smith-11]

> > Years ago I'd write apps for people using either QuickC or QuickBasic (acually
> > PDS which could do overlays).  If they didn't get the source code I'd do it in
> > Basic, otherwise they got to choose.  Many insisted on C, even though I then
> > charged at least twice as much and took twice the time to do it.
> >
> > The joke was, of course, that once compiled you couldn't tell the difference as
> > to whether it was in C or Basic.  (I wasn't writing ray-tracers or such things
> > where C would have been a better choice).
> >
> > Microsoft wised up with Windows C & Basic, so VB didn't get a compiler, thus
> > letting the 'Real Men' (TM) get on with the job of doing whatever it is they
> > do.  Probably telling the VB weenies their language of choice sucks - "Pfft, it
> > doesn't even compile".
>
>
> I was under the impression that QuickBASIC "compiled" the ASCII source
> code to byte-code and included an interpreter in the EXE?
> This is sort of what compiled Perl does now - though there is a real
> Perl -> C translator back-end. (B::C) - not that I would compare QB to
> Perl.

VB did the byte-code & interpreter, as do the .Net languages now.  QB always compiled to a real .exe file.  Or at least a a.com that pretended to be a .exe.  I know some Basics did store source files like that, but we're back in the days of the Apple ][ now.  

Dropping the compiler from VB meant Microsoft got to sell both you VB & C, VB for the UI, and C for the hard stuff.  That was the theory, but most people picked one or the other, causing themselves all sorts of grief.

The PDS variant (Professional Development System) of QuickBasic did a few things QB didn't, but I've forgotten exactly what.  It optimised code better, could create .obj files and did overlays, so you'd have trouble convincing people that yes, that 4mb exe was in fact written in Basic.  Everyone knew only C could do that, Basic had to CHAIN stuff together.

PDS became VB-DOS, and you could use its compiler on your existing stuff.  I think it moved strings from near to far memory, which was helpful.

Tony


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[PPA]

Gerhard Fiedler wrote:

...
For me, being able to compile the program in different versions of a
compiler of the same vendor is the lowest level; I wouldn't even call
this "portability", it's more like version compatibility. The next level
is being able to compile on compilers from different vendors (on the
same operating system); this maybe I'd start to call portability. Then
come different operating systems and different target processors; here
we get into what I call portability.

My assertions were a bit simplified; I'm sometimes a bit lazy on my keyboard...
Sure that you are right on these points.

Gerhard Fiedler wrote:

So how does this aspect look for Pascal? (This is not a rhetorical
question; I really want to know from someone who uses Pascal portably.)

Is this irony? Well as I already said, you may use $ifdef constructs in "the units that gather all portability sensitive parts" to manage portability, say, from TP3 to Delphi (same vendor) or FPC (near compatible one) or Acme Pascal or whatever one.
As I said no less no more than with C. OK, there may be more $ifdef than #ifdef due to language compatibility, but these language differences are very tight (more than in C witch may be qualified as nearly fully "standard"); that's not "impossible", please stop saying that: that's just a little bit harder than with C, no more. If you are used to do that that's not really boring.

Gerhard Fiedler wrote:

One application I work on has several 100kLOC that compiles fine on gcc
and VC++ for Linux and Windows, with a very small and isolated part
being compiler and platform specific. Recently we tested the Intel C++
compiler for Windows, and the code compiled without any changes. (We
dropped it, though, because the performance advantages were small, and
the compile times were horrible.) Is this possible with Pascal -- taking
such a complex application, pick another vendor's compiler, and it "just
works"?

Not “it just works” for sure it needs often some work, but not so much as you seem to want to make us to trust.
I've also managed several 100KLOC applications in Pascal. One was started in TP3 under dos and now works in W32, on the latest compiler / windows environment. I have to say that a big part of the functionalities are skipped in the old dos version due to HW; I've not checked it recently but I think that it would still compile with TPW for W3.11... Never tried on Kylix or ThinkPascal that was not relevant but why not...
You have just to find a good method to be compatible, that's not very complicated: just a matter of methodology. We are more used to do this in Pascal since we have more issues to manage due to the lack of standardization

Gerhard Fiedler wrote:

Besides some odd vendors of small micro compilers, there aren't really
any C dialects. The few there are are really niche thingies, mostly
restricted to the PIC world (and maybe the one or other small micro, but
I think the PIC compilers are worse than most others in this respect).
In the great scheme of C, they almost play no role at all. Every
compiler that wants to be worth its money has to be standard compatible,
and therefore allows programming in standard C (or C++). Which is more
common as you seem to think.

You said "odd vendors", "niche thingies", "almost no role at all".
There is always special needs and niches; people that are there would be upset to read your comments; some niches may be less than a few percent of percent of all the "great scheme of C world", but this may represent thousands of people that are NOT playing "no role"; same as with Pascal or even Cobol (there is even an object Cobol nowadays) or whatever...
On "has to be standard compatible" that's the point. Even if the standard is not good enough? Even if you have a good idea that is non standard? Do you think that in 2050 we will use the same old low level less common denominator things? I hope not. A language should evolve or die, C as any one; I think it will die because of these too low level standards that nobody can jump off. Other languages are born, some died; see Cobol or Fortran users that don't want to see the cliff edge: the final fall will be hard - same for me with my Pascal and its childs? Can be, but in a long time I hope; there's many choices nowadays; Java (a C child?) engines on chip among other not so new things...

Gerhard Fiedler wrote:

>> (I'm not trying to say that "C is better than Pascal" :)
>>
> Just a bit ;-) ...

No, I'm not. If you're reading this into my messages, maybe it's because
you're defensive about Pascal. Fact is that Pascal is almost dead in the
professional world. Another fact is that I started serious PC
programming with Pascal. And yet another fact is that I had to give it
up because Pascal is almost dead for most professional purposes. And
part of this thread is about why this is.

I really really didn't like it. Turbo Pascal was miles ahead of anything
else. The IDE was snappy and functional, compilation was fast and the
executables were, too, it was affordable and powerful. But it didn't
make it into the big league, and my guess is that it's about
standardization. Microsoft was and is big enough to be able to make a
vendor-specific language popular (see VB and C#) without a
vendor-independent standard, Borland wasn't and isn't, Delphi
notwithstanding.

It doesn't help pretending that Pascal isn't dead in the professional
world, or make this into yet another "this language is better than that
language" pissing contest... It's about finding out why Pascal, with all
the perceived advantages, didn't make it -- and, arguably, at this
point, has little chance of making it ever.

You're saying nice things and you say you don't like what has happened to it but also you say wrong things. If you gave up on Pascal, maybe it is because your job cannot be done with it at these times; that's not the case for everybody so far. If there was another language that I can jump into as a better replacement I would have done the break, but for now I've not searched for because I don't need it. I've never used a C or C++ compiler at all; some developments in VB / VB.NET because of an inevitable marketing buzz touching some customers in the industrial world (Bad memories of these dark ages)...

I'm not making another language war. As Olin, I'm speaking about methodology and since I know what I say about Pascal, I compare with Pascal; if it was another language I would have compared with it.
Also I'm not so defensive about Pascal; I know every limitation of this language and every powerful thing as well.

I just don't like when people are saying that a language cannot do something without arguments or even that it is dead without seeing/knowing all the actual reality. This is surprising from somebody who comes from Pascal...

I may agree on discussions about why Pascal (or whatever language) does not have found its place, not to discuss about not argued assertions.

Note that the beginning of the thread (not the OP) was on C good and bad behaviors, on it's poor type checking among other things, not on if Pascal didn't make it or was dead or not...
You wrote yourself some assertions that can be read as the beginnings of another stupid language war by saying wrong things, so you cannot blame anybody if you got answers on that, so please maybe we can let this aside now.

On Microsoft vs. Borland, don't forget that Borland C/C++ compilers was far better than Microsoft ones; all new improvements came from Borland; Microsoft has copied everything, with the power of Microsoft, as they do with other tools and good ideas, when finally they delivered their "revolutionary" Visual tools... This is not technical, this is business and in this domain they will stay #1 for a long time I guess.

Pascal side, Borland made a nearly de facto standard (the most used I think); I don't understand why an official standardization was not done when Borland was on top of the wave; then Pascal activity has decreased because they had enough concerns to make survive their non-Pascal tools against the power of Microsoft witch makes business on everything other than compilers. An excellent technical level is not enough.
See what Microsoft is giving us at each new good business idea: we need to come back to school to un-teach all what they teach us last time, new layers that gives slower software even with a CPU power that doubles regularly... Definitively not a good model for technical comparison of why something is popular or not...

[Tony Smith-11]

> > No-one needs the 'power' that C gives you these days, it's all
> > libraries, web apps and front-ends for SQL databases.
>
> That's baltantly wrong, of course.  Sure there are a lot of web apps and
> such where CPU power is not the limiting factor.  But to say that this is
> never the case is rediculous.  Maybe you don't ever run a programs that
you

> have to wait on because of the sheer number of calculations required, but
> that doesn't make it true for everyone.  Programs in that catagory for me
> include the Eagle auto router and some image processing utilities.
>
> I recently wrote a program for a customer that performs 50000 relaxation
> passes on 10s to 100s of polar grids.  The total run time can be 10s of
> minutes or more, depending on the number of thingies installed at a
> particular site.  While a hour per customer site installation once is
> acceptable, I'm sure the field folks would love it to be faster.
>
> That's just a few examples of the many out there, although only a single

one
> disproves your blanket statement.
>
> > You don't need C for that.
>
> True.  The language is not the issue as long as it's a truly compiled one
> intended for general purpose from the start.  As long as you understand
what
> goes on underneath and don't do something stupid, most truly compiled
> languages with modern compilers will give you about the same performance.


I originally wrote 'almost no-one', but changed it to see who'd bite.

'Blatantly' is a bit much, sure Eagle needs to run fast, but you're not the
one writing the auto-router.  Out of the thousand of Eagle users only one
needs C, and that's the author.  

It's also been true for a while that it's cheaper to buy more CPU power then
spend days fiddling with something to make it faster.  That offends people
too, but a new PC divided by your hourly rate is a small number.  Which is
better?

MS Office is a perfect example of utilising CPU power, rather than having
document saves being basically a memory dump with various abominations
tacked on over the years, now it's a bunch of XML files zipped up.  That's
better PCs, not so much better coding.

C is rarely needed these days.

PICs are the same, you have "slow cheap Pic + Assembler" vs "faster $ PIC +
compiler".  Not everyone needs assembler for PICs.

Tony

(and in reference to the subject line, BREAK is probably the dumbest idea
ever, every other language got switches right)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tony Smith-11]

> I still use TurboPascal when fiddling with TurboCNC.

Which probably doesn't make up a big chunk of your income.


Yeah, not a big earner  :)


> > That said, the differences are often just perception, BASIC is for
> > little kiddies, Pascal for quiche-eating professors, and 'Real Men'
> > (TM) use C.
>
> Not sure where the people are that perceive it like this, but not around
> where I make my money. VB /is/ a professional tool, so is Delphi. And
> nobody in his right mind would use C (or pay for someone using C) for
> something these two are usually used.


Oh, they're alive and well (and probably posting on the list).  The comment
made earlier when someone said a product sold by a list member should be
called !C instead of Basic shows it's still there.  Add the 'M$ windoze'
folk to the list.  We know it sucks so get a new joke (one you made yourself
would be better).  Then there's the 'dot net sucks' bandwagon crowd too.
Nothing changes.  


> > No-one needs the 'power' that C gives you these days, it's all
> > libraries, web apps and front-ends for SQL databases.  You don't need
> > C for that.
>
> Nobody really uses it (professionally) for that. But then, check out
> what the SQL databases are written in... Chances are it's not a BASIC or
> Pascal dialect. (Which again is not to say they couldn't be; just that
> they aren't.)


Sure, hands up all those here who write SQL databases.  Uh-huh.  Those
people might need C (or assembler) but not the rest of us.  I still come
across people developing applications in C++ because 'C is better'.  Never
mind you could probably replicate their app in a spreadsheet.

Tony

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist