Porting C software

[Jean-Pierre Mestre]

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

[Richard Heathfield]

Jean-Pierre Mestre said:

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and
the other the safe String type.

C doesn't have either feature. These are extensions to the language,
provided by the implementor. You have just discovered why one should
think very seriously before taking advantage of extensions - they make
porting the code much more difficult.

Is there a compiler for Unix with
these advanced features, or what's the best way to port them across?

The best way to regain the portability you desire is to rewrite the
program in C.

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

[Ben Pfaff]

Jean-Pierre Mestre <a.*@c.comwrites:

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

No, these are lccwin32-specific features. You will have to
modify your software not to use them if you want to be able to
use it with any other C implementation.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[Ben Bacarisse]

Jean-Pierre Mestre <a.*@c.comwrites:

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler

<off topic>lcc-win32 is not FLOSS as far as I know. FLOSS (Free,
Libre, Open Source Software) is something of a catch-all but I don't
think the term extends to software that is simply free for
non-commercial use.</off topic>

lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

The cleanest solution would be replace the String objects with one of
the fine, freely-available string libraries (sorry I have no link for
you but at least two are written by regulars here) and to hand un-pick
the operator overloading.

If there is a lot if it, and the semantics of lcc-win32's overloading
is close match, there *may* be some mileage in targeting g++ (the C++
compile in the GNU family) since that has string objects in a standard
library and operator overloading in the language. Of course, the
details end up being off topic for this group -- as soon as your code
goes near a C++ compiler is becomes C++ and you need the expertise of
C++ people to guide you (news:comp.lang.c++).

[Obviously, avoid any gcc extensions as well -- the code is being
ported once, so it may have to be ported again.]

--
Ben.

[santosh]

Jean-Pierre Mestre wrote:

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32.

AFAIK, lcc-win32 is not FLOSS. It's Freeware.

I try gcc but now it doesn't work :(

That's because the code uses lcc-win32 specific extensions.

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

I may be wrong, but jacob mentioned sporadically that there exists, or that
he is working on, a port of his compiler for Linux. Maybe you should
contact him?

If you've used these extensions heavily, it may be very time consuming to
modify your source to compile under an ISO complaint compiler.

Also consider taking further queries about lcc-win32 code to
comp.compilers.lcc

[Keith Thompson]

santosh <sa*********@gmail.comwrites:

Jean-Pierre Mestre wrote:

>I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32.

AFAIK, lcc-win32 is not FLOSS. It's Freeware.

Different people will have different understandings of what the term
"Freeware" means. Rather than trying to resolve it, I'll just say
that it's possible to download and use lcc-win32 without paying any
money for it. Obtaining sources is a separate question.

[...]

Also consider taking further queries about lcc-win32 code to
comp.compilers.lcc

Indeed.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Jean-Pierre Mestre wrote:

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

Hi Jean Pierre

The best is to use lcc under linux red hat. Please contact me for that.

Sorry to not answering you before but I was in holidays.

jacob

[Jean-Pierre Mestre]

Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized by
lcc.

Is there a description anywhere of a "common subset" of C recognized by
all compilers?

J-P.
On 23 Aug 2007 at 21:41, jacob navia wrote:

Jean-Pierre Mestre wrote:

>Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

Hi Jean Pierre

The best is to use lcc under linux red hat. Please contact me for that.

Sorry to not answering you before but I was in holidays.

jacob

[Richard Heathfield]

Jean-Pierre Mestre said:

Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized
by lcc.

Is there a description anywhere of a "common subset" of C recognized
by all compilers?

Yes. It's called "the ISO C Standard" or, more formally, ISO/IEC 9899.
Just about any C compiler you are likely to come across conforms to the
1990 version of that Standard. (There is a later version, 9899:1999,
but it is not (yet) recognised by all, or indeed more than a handful
of, compilers.)

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

[cr88192]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:lc******************************@bt.com...

Jean-Pierre Mestre said:

>Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized
by lcc.

Is there a description anywhere of a "common subset" of C recognized
by all compilers?

Yes. It's called "the ISO C Standard" or, more formally, ISO/IEC 9899.
Just about any C compiler you are likely to come across conforms to the
1990 version of that Standard. (There is a later version, 9899:1999,
but it is not (yet) recognised by all, or indeed more than a handful
of, compilers.)

yes.

C90 is good, yes...

C99 contains a few features that look particularly problematic (dynamic
arrays and so on...).

still, should work pretty good as a reference for writing portable code (to
what extent what one writes can be made portable...).
the standard explains more than a few things, but stops well short of a
complete explanation (for example, of the exact calling conventions, data
representations, ... employed by an architecture, which may be particularly
relevant for more involved projects).

another approach (though better when combined with the standards, so one
knows more what is and is not standard) is to take some specific
implementation (say, gcc), and using this as a general reference
implementation ('how things work' and similar questions). this is generally
what I have done. how and what is done in gcc is something I personally find
particularly relevant to my own efforts.
my case, I have a compiler, it supports a subset of C (and also has a few
extensions). well, I don't have working static declarations and inline
functions as of yet, but I do have builtin geometric vectors and
quaternions, and other misc extension features...

note: the purpose of my compiler is not to compete with gcc, but to fill a
nice currently left void by gcc, that of being an at-runtime compiler (IMO,
a lot more powerful and useful than a typical script VM).
now, if in my compiler, I go and write code making use of a bunch of vector
and quaternion math using my extensions, well, then, it is not portable. I
still decided having them was worthwhile though.

also, apparently, unlike gcc I went and implemented imaginary types, having
failed to notice that gcc did not until generally afterwards. oh well...

or such...

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

[Richard Heathfield]

cr88192 said:

"Richard Heathfield" wrote...

>Jean-Pierre Mestre said:

>>>
Is there a description anywhere of a "common subset" of C recognized
by all compilers?

[Summary of my reply: "C90"]

yes.

C90 is good, yes...

C99 contains a few features that look particularly problematic
(dynamic arrays and so on...).

still, should work pretty good as a reference for writing portable
code

No, it doesn't work pretty good for that. It might do one day, but it
doesn't yet. And the OP asked for a description of C that is recognised
by all compilers. C99 doesn't come anywhere near achieving that.

(to what extent what one writes can be made portable...).

Some of us here in clc write portable code far more often than we write
non-portable code. It's certainly true of me, anyway.

<snip>

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

[Ian Collins]

Jean-Pierre Mestre wrote:

<top posting corrected>

On 23 Aug 2007 at 21:41, jacob navia wrote:

>Jean-Pierre Mestre wrote:

>>Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

Hi Jean Pierre

The best is to use lcc under linux red hat. Please contact me for that.

Sorry to not answering you before but I was in holidays.

Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized
by lcc.

That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++, so if
you want portability, port to that language.

--
Ian Collins.

[jacob navia]

Ian Collins wrote:

Jean-Pierre Mestre wrote:

<top posting corrected>

>On 23 Aug 2007 at 21:41, jacob navia wrote:

>>Jean-Pierre Mestre wrote:
Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

Hi Jean Pierre

The best is to use lcc under linux red hat. Please contact me for that.

Sorry to not answering you before but I was in holidays.

Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized
by lcc.

That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++, so if
you want portability, port to that language.

Most of the lcc-win32 extensions are very easily ported to C++

[Nick Keighley]

On 24 Aug, 11:50, "cr88192" <[e-mail]:

"Richard Heathfield" <[e-mail] in message
news:lc******************************@bt.com...

Jean-Pierre Mestre said:

Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized
by lcc.

Is there a description anywhere of a "common subset" of C recognized
by all compilers?

[C90]

<snip>

C90 is good, yes...

C99 contains a few features that look particularly problematic (dynamic
arrays and so on...).

and the rest

still, should work pretty good as a reference for writing portable code (to
what extent what one writes can be made portable...).

most of what I write is portable. And the non-portable bits can be put
in a separate module.

the standard explains more than a few things, but stops well short of a
complete explanation

that's what it's supposed to do...

(for example, of the exact calling conventions,

calling conventions!!! When do you need to know those? I've worked
on large systems (ok, lets just say fairly not-small). I've worked on
embedded systems. And I didn't need to know the calling conventions.
The last time I did was when there was no source code debugger so we
debugged the assembler. Great fun.

data representations,

how often do you need those? I like to have an "octet" (unsigned
8 bits) for external representation. But otherwise who cares?

... employed by an architecture, which may be particularly
relevant for more involved projects).

what are these "more involved projects"?

another approach (though better when combined with the standards, so one
knows more what is and is not standard) is to take some specific
implementation (say, gcc), and using this as a general reference
implementation ('how things work' and similar questions).

no no no!!!! Don't Do This!!! GCC is a particular implementation.
It can only tell you about GCC. Why not use the standard? You can
go a long way without getting implementation specific. I'm not
even sure what my current software is going to be targetted on
in the end. And mostly it doesn't matter.

this is generally
what I have done. how and what is done in gcc is something I personally find
particularly relevant to my own efforts.

my case, I have a compiler, it supports a subset of C (and also has a few
extensions). well, I don't have working static declarations and inline
functions as of yet, but I do have builtin geometric vectors and
quaternions, and other misc extension features...

games?

note: the purpose of my compiler is not to compete with gcc, but to fill a
nice currently left void by gcc, that of being an at-runtime compiler (IMO,
a lot more powerful and useful than a typical script VM).

an interpreter or maybe a JIT compiler. Sounds cool.

now, if in my compiler, I go and write code making use of a bunch of vector
and quaternion math using my extensions, well, then, it is not portable. I
still decided having them was worthwhile though.

it's your language. If it solves problems for you then it's good.
Though you might have looked at things like Python, Perl, Tcl etc.
which might have already solved your problem.

also, apparently, unlike gcc I went and implemented imaginary types, having
failed to notice that gcc did not until generally afterwards. oh well...

or such...

<shrugyou have quaternions so you aren't trying to be standard C;
why worry about imaginary types. Hmmm imaginary types. You only think
you've stored your data but behind your back it mysteriously vanishes.
Didn't <large software companyimplement that years ago?
--
Nick Keighley

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

[IRONY IMPAIRED NOTE: I put that in because I thought it was funny]

[Philip Potter]

jacob navia wrote:

Ian Collins wrote:

>That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++, so if
you want portability, port to that language.

Most of the lcc-win32 extensions are very easily ported to C++

Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.

Phil

--
Philip Potter pgp <atdoc.ic.ac.uk

[Ben Bacarisse]

Jean-Pierre Mestre <a.*@c.comwrites:

Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized by
lcc.

Is there a description anywhere of a "common subset" of C recognized by
all compilers?

As a practical matter, you don't need to convert everything to this
common subset right now. For example, if the language accepted by
lcc-win32 (I'll call it LC) allows // comments and mixed statements
and declarations, then you can leave these for the time being since
you are certain to find a compiler on Linux where these are
unproblematic. You may choose to change these later for maximum
portability, but they are not much of a problem right now.

The hardest problem may come from the fact that LC has a garbage
collector so, depending on how your program is written, it may not free
any of the storage it allocates. The quick solution to this is to use
a garbage collector on the new platform.

<OT>http://www.hpl.hp.com/personal/Hans_Boehm/gc/ is considered a good
one.</OT>

Garbage collected languages encourage a different style (at least as
far as storage management is concerned) from non-GC languages so you
will need to see how far that style has penetrated into the code.

--
Ben.

[cr88192]

"Nick Keighley" <ni******************@hotmail.comwrote in message
news:11**********************@l22g2000prc.googlegr oups.com...

On 24 Aug, 11:50, "cr88192" <[e-mail]:

>"Richard Heathfield" <[e-mail] in message
news:lc******************************@bt.com...

Jean-Pierre Mestre said:

>Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only recognized
by lcc.

>Is there a description anywhere of a "common subset" of C recognized
by all compilers?

[C90]

<snip>

>C90 is good, yes...

C99 contains a few features that look particularly problematic (dynamic
arrays and so on...).

and the rest

>still, should work pretty good as a reference for writing portable code
(to
what extent what one writes can be made portable...).

most of what I write is portable. And the non-portable bits can be put
in a separate module.

yes, a good practice.

I do similarly for the most part...

>

>the standard explains more than a few things, but stops well short of a
complete explanation

that's what it's supposed to do...

>(for example, of the exact calling conventions,

calling conventions!!! When do you need to know those? I've worked
on large systems (ok, lets just say fairly not-small). I've worked on
embedded systems. And I didn't need to know the calling conventions.
The last time I did was when there was no source code debugger so we
debugged the assembler. Great fun.

in what I do, this I need to know.

>

>data representations,

how often do you need those? I like to have an "octet" (unsigned
8 bits) for external representation. But otherwise who cares?

it matters...

>

>... employed by an architecture, which may be particularly
relevant for more involved projects).

what are these "more involved projects"?

lots of things...

>

>another approach (though better when combined with the standards, so one
knows more what is and is not standard) is to take some specific
implementation (say, gcc), and using this as a general reference
implementation ('how things work' and similar questions).

no no no!!!! Don't Do This!!! GCC is a particular implementation.
It can only tell you about GCC. Why not use the standard? You can
go a long way without getting implementation specific. I'm not
even sure what my current software is going to be targetted on
in the end. And mostly it doesn't matter.

gcc tells about gcc, and in many cases, very important pieces on info, like
the further specifics of the calling convention, the structure of the
generated code, ...

>

>this is generally
what I have done. how and what is done in gcc is something I personally
find
particularly relevant to my own efforts.

my case, I have a compiler, it supports a subset of C (and also has a few
extensions). well, I don't have working static declarations and inline
functions as of yet, but I do have builtin geometric vectors and
quaternions, and other misc extension features...

games?

well, I also wrote a 3D modeler and skeletal animation tools, a physics
engine, ...
vectors are pretty basic and useful.

>

>note: the purpose of my compiler is not to compete with gcc, but to fill
a
nice currently left void by gcc, that of being an at-runtime compiler
(IMO,
a lot more powerful and useful than a typical script VM).

an interpreter or maybe a JIT compiler. Sounds cool.

technically, it is neither.
my previous script langs were interpreters.
my last VM was JIT based.

my C compiler works much closer to a traditional compiler, but at runtime.

http://en.wikipedia.org/wiki/Incremental_compiler

>

>now, if in my compiler, I go and write code making use of a bunch of
vector
and quaternion math using my extensions, well, then, it is not portable.
I
still decided having them was worthwhile though.

it's your language. If it solves problems for you then it's good.
Though you might have looked at things like Python, Perl, Tcl etc.
which might have already solved your problem.

I have complaints, I no longer like interpreter or VM-based languages, for
some fundamental limitations in the existence of a VM.

a more 'involved' approach (a full-on compiler) can get around these
problems.
for example, almost no traditional VM around lets you be like:
well, here is some static library, and some header files, I feel like going
and merging these into the running process image and hacking them into the
running app's code...

but, now, I can...
instead, any such lib has to be linked with the host app, and one has to go
through the pain of getting some or another FFI interface to work.

in my case, there is no FFI, things work directly...

>

>also, apparently, unlike gcc I went and implemented imaginary types,
having
failed to notice that gcc did not until generally afterwards. oh well...

or such...

<shrugyou have quaternions so you aren't trying to be standard C;
why worry about imaginary types. Hmmm imaginary types. You only think
you've stored your data but behind your back it mysteriously vanishes.
Didn't <large software companyimplement that years ago?

well, I am working on getting it close, though yes, being a strictly
conformant implementation is not needed in my case.

well, they are extensions, they require a header (otherwise they have ugly
built-in names...).

>
--
Nick Keighley

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

[IRONY IMPAIRED NOTE: I put that in because I thought it was funny]

[santosh]

cr88192 wrote:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:QJ******************************@bt.com...

>cr88192 said:

>>"Richard Heathfield" wrote...
Jean-Pierre Mestre said:

>
Is there a description anywhere of a "common subset" of C recognized
by all compilers?

[Summary of my reply: "C90"]

>>yes.

C90 is good, yes...

C99 contains a few features that look particularly problematic
(dynamic arrays and so on...).

still, should work pretty good as a reference for writing portable
code

No, it doesn't work pretty good for that. It might do one day, but it
doesn't yet. And the OP asked for a description of C that is recognised
by all compilers. C99 doesn't come anywhere near achieving that.

yes, well then one has to ask, where to find the C90 spec?...
I failed before I think, so I use the C99 spec.

<http://flash-gordon.me.uk/ansi.c.txt>

<snip>

[Flash Gordon]

santosh wrote, On 24/08/07 18:22:

cr88192 wrote:

<snip>

>yes, well then one has to ask, where to find the C90 spec?...
I failed before I think, so I use the C99 spec.

<http://flash-gordon.me.uk/ansi.c.txt>

Please refer people to the CLC Wiki http://clc-wiki.net/wiki/c_standard
instead of directly to my site just in case I move it when I get things
organised. This also give credit to Dan Pop who used to provide this
download before he disappeared.
--
Flash Gordon

[jacob navia]

Philip Potter wrote:

jacob navia wrote:

>Ian Collins wrote:

>>That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++, so if
you want portability, port to that language.

Most of the lcc-win32 extensions are very easily ported to C++

Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.

Phil

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

jacob

[Philip Potter]

jacob navia wrote:

Philip Potter wrote:

>jacob navia wrote:

>>Ian Collins wrote:
That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++,
so if
you want portability, port to that language.

Most of the lcc-win32 extensions are very easily ported to C++

Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly
idea.

Phil

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

C++ is complex; but there is no problem with a programmer simply using
the subset of the language that he knows well and disregarding the rest.
At least you're still using a standard language.

There is no Pareto-efficient way to improve the C language. This is
because for every new feature you add, you reduce the portability of
programs using that feature. One of your users has just found this out
the hard way.

And what's the point in complaining about C++'s complexity when programs
written for lcc-win32's extensions need to be compiled in C++ to be
ported to any other platform?

I don't restrict my complaints about this to you and your compiler. I
don't think I'll ever understand why pretty much every compiler out
there compiles in nonstandard-bells-and-whistles mode by default. But
lesser extensions, such as // comments, mid-block declarations (in "C90"
compilers), or the #warning preprocessor directive are much easier to
edit out of an application than, say, operator overloading.

Phil

--
Philip Potter pgp <atdoc.ic.ac.uk

[Ian Collins]

jacob navia wrote:

Philip Potter wrote:

>jacob navia wrote:

>>Ian Collins wrote:
That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++,
so if
you want portability, port to that language.

Most of the lcc-win32 extensions are very easily ported to C++

Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly
idea.

Phil

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

This is a really dangerous thing to do, as this case shows. Someone has
been suckered into using a non-portable extension when they should have
used the language that portably supports what they are tying to do.

Such extensions don't do anyone any favors. I could understand them if
the compiler was the only option on some obscure platform, but not for
one targeted at two common hosted environments.

--
Ian Collins.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Philip Potter wrote:

>>jacob navia wrote:
Ian Collins wrote:
That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++,
so if
you want portability, port to that language.
Most of the lcc-win32 extensions are very easily ported to C++
Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly
idea.

Phil

My objective is to improve the C language retaining its simplicity.
The problem of C++ is its incredible complexity. I want to avoid that.

Therefore I have added some features I consider useful without
many others that make the language too complex.

This is a really dangerous thing to do, as this case shows. Someone has
been suckered into using a non-portable extension when they should have
used the language that portably supports what they are tying to do.

Such extensions don't do anyone any favors. I could understand them if
the compiler was the only option on some obscure platform, but not for
one targeted at two common hosted environments.

I do provide implementations of the compiler under linux and windows.
If the original poster doesn't want to use them its his choice. I can't
do anything else.

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

jacob

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>This is a really dangerous thing to do, as this case shows. Someone has
been suckered into using a non-portable extension when they should have
used the language that portably supports what they are tying to do.

Such extensions don't do anyone any favors. I could understand them if
the compiler was the only option on some obscure platform, but not for
one targeted at two common hosted environments.

I do provide implementations of the compiler under linux and windows.
If the original poster doesn't want to use them its his choice. I can't
do anything else.

The problem is he appears to think they are C, rather than an lcc
specific extension. I've wasted way too many days porting gcc code to C
or C++, that's why I get so stroppy about compiler extensions,
especially those that are enabled by default.

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

But it doesn't, if he wanted operator overloading or a string class he
should have used C++, where they are standard and portable.

Everywhere your compiler is available, C++ compilers are available, so
what's the point?

--
Ian Collins.

[Philip Potter]

jacob navia wrote:
[Compiler extensions]

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines that
these extensions can be useful. Not that they are needed. If every
compiler extension that was used and found useful made it into the
standard we'd have a language several times larger than C++ by now.

Phil

--
Philip Potter pgp <atdoc.ic.ac.uk

[jacob navia]

Philip Potter wrote:

jacob navia wrote:
[Compiler extensions]

>The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines that
these extensions can be useful. Not that they are needed. If every
compiler extension that was used and found useful made it into the
standard we'd have a language several times larger than C++ by now.

Phil

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.
For instance, to cite one among many, a certain Richard Heathfield said
in a discussion in comp.std.c:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>
Message id: <f_*********************@bt.com>

He is not the only one.

Since C is not an object oriented language, and the C implementation
can build upon the C++ experience, (no overloading of the ",", "&&" or
"||" operators for instance) the end result is cleaner than the
C++ counterpart, and very easy to implement.

[Spiros Bousbouras]

On Aug 25, 10:21 am, jacob navia <[e-mail]:

Philip Potter wrote:

jacob navia wrote:
[Compiler extensions]

The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines that
these extensions can be useful. Not that they are needed. If every
compiler extension that was used and found useful made it into the
standard we'd have a language several times larger than C++ by now.

Phil

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.

If you want extra numeric types what's wrong with having
functions add() , subtr() etc. to handle those types ? Why
overload the already existing operators ?

[CBFalconer]

Jean-Pierre Mestre wrote:

>
Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only
recognized by lcc.

Is there a description anywhere of a "common subset" of C
recognized by all compilers?

As far as we can tell lcc-win32 is highly non-standard. Standard
C90 is accepted by virtually all C compilers (with some exceptions,
largely in the embedded world), and is the form of C discussed
here. The standard is easily available, in draft form as N869 or
N1124. A version of N869 slightly modified for easy reference and
quoting is available, bzip2 compressed, at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)
--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Nick Keighley wrote:

>

.... snip ...

>
We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

[IRONY IMPAIRED NOTE: I put that in because I thought it was funny]

Actually, it is rather sad. GCC should be compilable with
absolutely pure C90 (or C99) code (i.e. the common subset), for
maximum portability. Also, IMO, it should default to "-ansi
-pedantic -W -Wall".

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

cr88192 wrote:

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

>Jean-Pierre Mestre said:

.... snip ...

>>>
Is there a description anywhere of a "common subset" of C
recognized by all compilers?

.... snip ...

>
the standard explains more than a few things, but stops well short
of a complete explanation (for example, of the exact calling
conventions, data representations, ... employed by an architecture,
which may be particularly relevant for more involved projects).

Bad idea. That immediately makes your code non-portable.

another approach (though better when combined with the standards,
so one knows more what is and is not standard) is to take some
specific implementation (say, gcc), and using this as a general
reference implementation ('how things work' and similar questions).
this is generally what I have done. how and what is done in gcc is
something I personally find particularly relevant to my own efforts.

Another bad idea, again leading to non-portable code. Isolate
anything that really has to be non-portable in a separate file, so
as to limit the rework needed during a port.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

Ian Collins wrote:

>Everywhere your compiler is available, C++ compilers are available,
so what's the point?

The point is, I believe C is a good language, much simpler to use
and implement than its C++ counterpart.

The problem with C++, as I have stated elsewhere in this discussion,
is its complexity, that is impossible to avoid even if you use your
own subset. You get constructors/destructors even if you do not want
them, you can't turn that off.

You get all the complexities of templates if you want to use the
library, even if you do not use them yourself.

I am convinced that 90% of the functionality of the STL can be
reproduced in C with operator overloading, since the overloading
of the [] operators give you a standard container access.

The problem with your approach, to my mind, is that your system
does not normally compile purely standard C. I may be in error
here. However, I believe that the system should process only
standard C and point out any variations from that. There can be
provisions to enable and disable extensions, as in GCC (which
doesn't compile standard C by default, but can be so configured).

To achieve this the developer must be familiar with standard C and
the appropriate C std. As you have demonstrated time after time in
this newsgroup, you do not have that familiarity. You are
surprised by well known C peculiarities, for example.

>
As the development of Java proves, the complexity of C++ made simpler
languages a really needed alternative. Java (and lately C#) are just
reactions to a language whose development went too far in the direction
of complexity.

C# is really just another Microsoft attempt to foul existing
standards and get ignorant users totally dependant on them.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
Why is operator overloading needed?

Operator overloading is needed for creating at the user's
discretion new kind of numbers.

This is completely impossible in current C, and it is needed for
a wide variety of usages, from extra precision floating point,
bignumbers, rationals, and many other usages.

It isn't needed. It may be a convenience.

What is needed, and is currently impossible in the language, is the
definition of subrange types a la Pascal. This one addition
enables good control at compile time, but is still fouled by the
loose treatment of pointers.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Ian Collins wrote:

Jean-Pierre Mestre wrote:

.... snip about compiled under lcc-win32 and non-portable ...

>>
Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only
recognized by lcc.

That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++,
so if you want portability, port to that language.

Ugh - what an ugly idea. C and C++ are different languages, with
lots of snazzy incompatabilities. Better to fix the source
properly, after which you will have something generally useful.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Ian Collins wrote:

>Jean-Pierre Mestre wrote:

... snip about compiled under lcc-win32 and non-portable ...

>>>
Well, I'm not sure. As others say it may need to be ported again
therefore perhaps it's better to remove some features only
recognized by lcc.

That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++,
so if you want portability, port to that language.

Ugh - what an ugly idea. C and C++ are different languages, with
lots of snazzy incompatabilities. Better to fix the source
properly, after which you will have something generally useful.

Maybe. But without knowing much about the appication, it's possible
that it really depends on some of those extensions. Perhaps it should
have been written in C++ in the first place.

Of course it's also entirely possible that you're right and that it
would be better to write it in portable C.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Philip Potter wrote:

>jacob navia wrote:
[Compiler extensions]

>>The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.

No, the fact that he did use them and found them useful underlines
that these extensions can be useful. Not that they are needed. If
every compiler extension that was used and found useful made it into
the standard we'd have a language several times larger than C++ by
now.

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.

[...]

Operator overloading is never actually *needed*. It's syntactic
sugar; any program written to use operator overloading can be
equivalently written without it. In fact, a tool that parses source
code with overloaded operators (using some extension with well-defined
syntax and semantics) and translates it to standard C using function
calls would probably be much easier to write than a full compiler. I
mention that merely to demonstrate that operator overloading doesn't
add anything fundamental to the language.

It certainly can be convenient, and I've used it in languages that
support it.

Ok, you don't like C++ because it's too big and complex, and you don't
like C as it's currently defined because it lacks some features that
you think are important. That's fine. So why not invent a new
language? Your compiler already supports a language that's neither C
nor C++; just give it a name and don't claim that it's C. Of course
your compiler can still continue to support standard C; multi-language
compilers aren't a new idea. You can then stop worrying about whether
your extensions violate the C standard; they're not extensions,
they're language features. (As far as I can tell, the name "C+"
hasn't been used, but of course you can use any name you like.)

I don't believe this would have any effect on the likelihood of your
features being adopted in a future C standard, if that's still your
goal. C has borrowed existing features from other languages before
(e.g., prototypes from C++).

Just to be clear, this is a completely serious suggestion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Spiros Bousbouras wrote:

>
If you want extra numeric types what's wrong with having
functions add() , subtr() etc. to handle those types ? Why
overload the already existing operators ?

OK. You have a extended precision float and you want
to do:

qfloat a,b,c;

// ...
a = (a+b)/(5+sqrt(c)-b);

You get:

tmp1 = add(a,b);
tmp2 = subtr(Convert(5),b);
tmp3 = SQRT(c);
tmp4 = add(tmp2,tmp3);
a = divide(tmp1,tmp4);

You see now?

jacob

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Philip Potter wrote:

>>jacob navia wrote:
[Compiler extensions]
The fact that he did use them and found them useful underlines that this
extensions are needed. I just do not have the money and political clout
to make them into the standard.
No, the fact that he did use them and found them useful underlines
that these extensions can be useful. Not that they are needed. If
every compiler extension that was used and found useful made it into
the standard we'd have a language several times larger than C++ by
now.

Why is operator overloading needed?

Operator overloading is needed for creating at the user's discretion
new kind of numbers.

This is completely impossible in current C, and it is needed for a wide
variety of usages, from extra precision floating point, bignumbers,
rationals, and many other usages.

[...]

Operator overloading is never actually *needed*. It's syntactic
sugar; any program written to use operator overloading can be
equivalently written without it. In fact, a tool that parses source
code with overloaded operators (using some extension with well-defined
syntax and semantics) and translates it to standard C using function
calls would probably be much easier to write than a full compiler. I
mention that merely to demonstrate that operator overloading doesn't
add anything fundamental to the language.

It certainly can be convenient, and I've used it in languages that
support it.

Yes, I agree with all that. It is not different than:
qfloat a,b,c;

// ...
a = (a+b)/(5+sqrt(c)-b); // Clear code

Instead you should write in current C:

tmp1 = add(a,b);
tmp2 = subtr(Convert(5),b);
tmp3 = SQRT(c); // No generic functions
tmp4 = add(tmp2,tmp3);
a = divide(tmp1,tmp4);

OR, even worst:

a = divide(add(a,b),add(subtr(Convert(5),b),SQRT(c));

Syntactic sugar is useful, as sugar itself is useful. I do take *some*
sugar with my coffee. But not like C++ where you take some
coffee with your sugar! :-)

Ok, you don't like C++ because it's too big and complex, and you don't
like C as it's currently defined because it lacks some features that
you think are important. That's fine.

Thanks. At least you do not get so upset!

So why not invent a new language?

Because I am interested in the development of C. Not some other
language. That is why I try to propagate my ideas in this
forum and that is why I write a compiler for a version of C that
features some enhancements I consider useful!

Your compiler already supports a language that's neither C
nor C++; just give it a name and don't claim that it's C.

I am not claiming that my enhancements are standard C.

Of course
your compiler can still continue to support standard C; multi-language
compilers aren't a new idea. You can then stop worrying about whether
your extensions violate the C standard; they're not extensions,
they're language features. (As far as I can tell, the name "C+"
hasn't been used, but of course you can use any name you like.)

I don't believe this would have any effect on the likelihood of your
features being adopted in a future C standard, if that's still your
goal. C has borrowed existing features from other languages before
(e.g., prototypes from C++).

Just to be clear, this is a completely serious suggestion.

I think that the difference between C and C++ at the semantic level is
object oriented programming.

C has no preconceived "frame of reference" like object oriented
programming in C++. I like this feature and want to keep it. There
is no need to invent another language. The extensions I am proposing
are useful, but clearly very minimal.

[Ian Collins]

Keith Thompson wrote:

>
Operator overloading is never actually *needed*. It's syntactic
sugar; any program written to use operator overloading can be
equivalently written without it. In fact, a tool that parses source
code with overloaded operators (using some extension with well-defined
syntax and semantics) and translates it to standard C using function
calls would probably be much easier to write than a full compiler. I
mention that merely to demonstrate that operator overloading doesn't
add anything fundamental to the language.

You describe an early cfront C++ compiler! Early C++ compilers
generated C source as an intermediate language. One of (if not the)
most respected C++ compilers currently available (Comeau) still does.

--
Ian Collins.

[Philip Potter]

jacob navia wrote:

Keith Thompson wrote:

>Of course
your compiler can still continue to support standard C; multi-language
compilers aren't a new idea. You can then stop worrying about whether
your extensions violate the C standard; they're not extensions,
they're language features. (As far as I can tell, the name "C+"
hasn't been used, but of course you can use any name you like.)

I don't believe this would have any effect on the likelihood of your
features being adopted in a future C standard, if that's still your
goal. C has borrowed existing features from other languages before
(e.g., prototypes from C++).

Just to be clear, this is a completely serious suggestion.

I second this suggestion. If the language became popular enough to have more
than one compiler, I would seriously consider using it too.

I think that the difference between C and C++ at the semantic level is
object oriented programming.

C has no preconceived "frame of reference" like object oriented
programming in C++.

Bjarne Stroustrup seems to think C++ has no preconceived "frame of reference"
either:
http://www.research.att.com/~bs/bs_f...ented-language

I agree with him. There's no need to program in objects if your problem is an
algorithmic problem. I have done this in C++ before.

Phil

--
Philip Potter pgp <atdoc.ic.ac.uk

[Ian Collins]

jacob navia wrote:

>
I think that the difference between C and C++ at the semantic level is
object oriented programming.

Nonsense, C++ is designed as a multi-paradigm language.

C has no preconceived "frame of reference" like object oriented
programming in C++. I like this feature and want to keep it. There
is no need to invent another language. The extensions I am proposing
are useful, but clearly very minimal.

Tell me what C++ nasties this valid C++ code invokes?

struct X { int a,b; };

X operator+( X lhs, X rhs ) {
X tmp;
tmp.a = lhs.a+rhs.a;
tmp.b = lhs.b+rhs.b;
return tmp;
}

Is this how you propose to add operator overloading?

--
Ian Collins.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>I think that the difference between C and C++ at the semantic level is
object oriented programming.

Nonsense, C++ is designed as a multi-paradigm language.

Yes, now Bjarne has changed his mind... but just a few years ago...

>C has no preconceived "frame of reference" like object oriented
programming in C++. I like this feature and want to keep it. There
is no need to invent another language. The extensions I am proposing
are useful, but clearly very minimal.

Tell me what C++ nasties this valid C++ code invokes?

struct X { int a,b; };

X operator+( X lhs, X rhs ) {
X tmp;
tmp.a = lhs.a+rhs.a;
tmp.b = lhs.b+rhs.b;
return tmp;
}

Is this how you propose to add operator overloading?

Exactly. That code would compile in lcc-win32.

The advantage of 20/20 hindsight is that some operators
can't be overloaded ("&&" or "||") what simplifies
everything since it is no longer necessary to explain
to beginners why overloading those is not a good idea.

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Yet another feature (this is planned only, I haven't implemented it
yet) is the operator [ ][ ] for two dimensional array access.

jacob

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>>
Tell me what C++ nasties this valid C++ code invokes?

struct X { int a,b; };

X operator+( X lhs, X rhs ) {
X tmp;
tmp.a = lhs.a+rhs.a;
tmp.b = lhs.b+rhs.b;
return tmp;
}

Is this how you propose to add operator overloading?

Exactly. That code would compile in lcc-win32.

It also compiles with any C++ compiler. It can be made more efficient
in C++ by using pass by reference and (shock horror) more concise by
adding a constructor to X.

So there is little point compiling it as an extension to C.

I think people tend to forget that the "how do we extend C" argument in
one form or another happened 20 odd years ago, resulting a new language
called C++.

The most useful way to add such an extension is in the form of a
pre-compiler, generating standard C code. Then it is clear that you are
using something other than C.

Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.

You see what I'm saying? You are going down the path of those before
you who wanted a "cleaner" C++, bit by bit you end up adding most of the
features you set out to avoid, or pay a high price in efficiency by
leaving them out.

--
Ian Collins.

[Ed Jensen]

Philip Potter <pg*@see.sig.invalidwrote:

C++ is complex; but there is no problem with a programmer simply using
the subset of the language that he knows well and disregarding the rest.

Most developers work on a team comprised of many developers. It's
unlikely any two C++ developers will be comfortable with the same
subset. And, eventually, you end up having to maintain someone else's
code.

Using a subset of C++ is not a solution to C++'s incredibly radical
complexity.

[cr88192]

"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...

cr88192 wrote:

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

>>Jean-Pierre Mestre said:

... snip ...

>>>>
Is there a description anywhere of a "common subset" of C
recognized by all compilers?

... snip ...

>>
the standard explains more than a few things, but stops well short
of a complete explanation (for example, of the exact calling
conventions, data representations, ... employed by an architecture,
which may be particularly relevant for more involved projects).

Bad idea. That immediately makes your code non-portable.

not desirable, but often required...

>another approach (though better when combined with the standards,
so one knows more what is and is not standard) is to take some
specific implementation (say, gcc), and using this as a general
reference implementation ('how things work' and similar questions).
this is generally what I have done. how and what is done in gcc is
something I personally find particularly relevant to my own efforts.

Another bad idea, again leading to non-portable code. Isolate
anything that really has to be non-portable in a separate file, so
as to limit the rework needed during a port.

works much of the time, but is a problem if something non-trivial is done,
which ends up making some large and non-trivial part of the codebase
non-portable.

the ideal is, that everything is portable everywhere.
the truth is: this doesn't scale well, and if the code is not going to be
very portable anyways, pick well, and exploit the system for what it is
worth...

so, one needs more and further reaching standards, and the hope that ones'
trradeoffs are worthwhile. one can hope for an ideal world, but just yet, it
does not exist...
for example, note that although I developon windows, and do some very
non-portable things, I still refrain from DirectX or the Win32 API (instead
choosing OpenGL and maintaining an overall minimalistic dependency on most
OS-dependent features).

I at least try for compatibility between the major OS's (that I use), namely
windows and linux, and the major architectures (that I also use), namely x86
and x86-64.

so, mac and ppc are not supported, nor arm or any of the other more esoteric
architectures, sad truth, but still truth.

apart from consoles and embedded, x86 is king.
apart from embedded, x86 and ppc are kings.

embedded is too constrained and diverse to really target in any general way,
and not for the kinds of code I write, there is, for the most part, no good
reason. most of my projects have almost no way to even hope of fitting in
the memory of most of these devices...
so, how big are ones projects?...

for a 300 kloc mostly 3D-tool beast (including an approx 70 kloc incremental
C compiler + assembler + linker), maintaining all that much portability is a
challenge...

for a 3 kloc command-line tool, it is a lot easier to be portable, but not
something 100x larger and inherently tied to non-portable technologies...

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

Ian Collins wrote:

>>>Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.

Also covered by C++.

This is just not true. C++ has now way within the [ ] operator
to know if its called for reading or for writing.

Oh yes it does, if you want to know how, ask on c.l.c++ or google for
proxy objects.

OK, google gives:
http://www.thescripts.com/forum/thread59882.html

<quote>
It is possible. You need some kind of proxy object[s] that will
help to get to the element. Usually, N dimensions need N-1 proxy
objects. First [] will return proxy_1. The proxy_1 class should
have [] overloaded too, to return proxy_2, etc., until proxy_Nm1's
overloaded operator[] will return a reference.
<end quote>

This is pure C++. Complexity and complexity and complexity.

Still, how can the proxy objects know if they are in an assignment
situation or in a just read situation?

HINT: THEY CAN'T!!!

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>>>>Another feature is that we have the operator [ ] for
*read* access to an array, and the operator [ ]= for *write*
access to an array/container. This distinction between read
and write access makes easier a lot of things, like
read only objects, for instance.
>
Also covered by C++.
This is just not true. C++ has now way within the [ ] operator
to know if its called for reading or for writing.

Oh yes it does, if you want to know how, ask on c.l.c++ or google for
proxy objects.

Still, how can the proxy objects know if they are in an assignment
situation or in a just read situation?

HINT: THEY CAN'T!!!

Hint - ask on c.l.c++, or find a copy of "More Effective C++" and read
Item 30.

--
Ian Collins.

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Philip Potter wrote:

jacob navia wrote:

Ian Collins wrote:
That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++, so if
you want portability, port to that language.

Most of the lcc-win32 extensions are very easily ported to C++

Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.

My objective is to improve the C language retaining its simplicity.

Since you have already introduced a secondary string type and a large
over-complication in the operator system, I'd say that, whatever anyone
may think about your first aim, you have already failed the second.

Richard

[jacob navia]

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>Philip Potter wrote:

>>jacob navia wrote:
Ian Collins wrote:
That's the problem when you fall into the trap of using compiler
extensions. In this case the extensions in question exist in C++, so if
you want portability, port to that language.
Most of the lcc-win32 extensions are very easily ported to C++
Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.

My objective is to improve the C language retaining its simplicity.

Since you have already introduced a secondary string type and a large
over-complication in the operator system, I'd say that, whatever anyone
may think about your first aim, you have already failed the second.

Richard

1) The string type uses operator overloading, and it is a demonstration
of what can be done just with operator overloading and generic
functions.

2) "Over complication of the operator system" is just an empty sentence
unless you fill it with some meaning. Care to explain what you
understand by that?

jacob

[¬a\\/b]

On Sun, 26 Aug 2007 10:16:45 +0200, jacob navia wrote:

>Constructors are an idea that looks great at first sight, but leads
to problems later.

Constructors are an idea that looks great at first sight, but is more
good later too

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

Philip Potter wrote:
jacob navia wrote:
Most of the lcc-win32 extensions are very easily ported to C++
Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.
My objective is to improve the C language retaining its simplicity.

Since you have already introduced a secondary string type and a large
over-complication in the operator system, I'd say that, whatever anyone
may think about your first aim, you have already failed the second.

1) The string type uses operator overloading, and it is a demonstration
of what can be done just with operator overloading and generic
functions.

So... yet more needless complication.

2) "Over complication of the operator system" is just an empty sentence
unless you fill it with some meaning.

No, if you don't mangle the grammar by removing the hyphen, it means
exactly what it says. Operator overloading makes the operator system
more complicated than it needs or should be. Hence, over-complication of
the operator system. That, in my book, is not simple.

Richard