c#
tesco
c#
Keith Thompson
> c#
d-
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
mackrune
|| c#
please spare us the profanity.
mackrune
jacob navia
"tesco" <998...@students.emu.edu.tr> wrote in message
news:agheqh$upb$1...@list.ege.edu.tr...
>
> c#
Microsoft announced the C# language as being "in the C tradition". I hope it
is not off-topic here.
Looking back to the announcement time, one of the bright ideas in C# was the
garbage collector. By coincidence, just 2 months before that announcement, I
had incorporated the Boehm's garbage collector system into lcc-win32.
Even if this means "accepting chairman Bill Gates ideas", I still think that
this is a bright idea. Since then, I have seen myself the big time savings
you can obtain by just forgetting about that awful accounting of each and
every byte in your application.
That accounting is very error prone, and better done by a machine than by
you personally. True, something of the "efficiency" of C gets maybe lost,
but how nicer is to program in a system where you do not have to hunt down
malloc bugs for ages before your are up and running!
In this times where memory sizes of 512MB are common, and 1GB memory sizes
are already around, risking a bug to avoid some few kilobytes of memory loss
using a conservative garbage collector is no longuer an issue.
The gc-time is almost nil. I incorporated the garbage collector into the
debugger, and tested it in that environment. I programmed the debugger to
allocate each time a string is displayed in the "watchs" window, and to just
forget that RAM to the GC. Then I put the debugger in single step, making it
allocate 500 byte strings for each symbol it is displaying at each step. GC
time was almost unnoticable. Yes, you "felt" that after a few thousands of
lines a small stop happened, but if you weren't expecting it you would never
have noticed it.
Yes, if you are programming real-time or in environments where each byte
counts this is an issue. But if you are programming in a normal PC the
effort of using bare malloc/free is no longuer justified.
The changes necessary to the language are NIL. The GC is just a DLL/Library
that gets dynamically linked to your application, and all you have to do is
to replace malloc by GC_malloc, and erase all calls to "free". Not very
difficult, in most cases you just do:
#define malloc(a) GC_malloc(a)
#define free(a)
After a while you get bored of trying to really verify if your free cals are
OK, and just erase them. Your program leaks memory to the GC, and so what?
Of course C# is not just a GC, but that was a good point in it. As a
language it seems not very difficult to master, specially if you use the
Microsoft tool chain. I wrote my first windows C# application in it in a few
minutes.
And then I closed the window, and went on. I still think that the best
language in the C tradition is C itself.
jacob
Francis Glassborow
<ja...@jacob.remcomp.fr> writes
>And then I closed the window, and went on. I still think that the best
>language in the C tradition is C itself.
So why do you want to change it in a way that makes it less useful for a
large part of its constituency? I think GC runs completely counter to
the C philosophy (but to be honest, I think several of the things
brought in with C99 are also subject to the same criticism)
If you want GC because you write for large, resource rich platforms,
pick another language that already provides it. The 'me too' philosophy
fails wherever it is applied.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
jacob navia
From: "Francis Glassborow" <francis.g...@ntlworld.com>
Newsgroups: comp.std.c
Sent: Sunday, July 14, 2002 12:27 PM
Subject: Re: c#
> In article <agrhsc$733$1...@wanadoo.fr>, jacob navia
> <ja...@jacob.remcomp.fr> writes
> >And then I closed the window, and went on. I still think that the best
> >language in the C tradition is C itself.
>
> So why do you want to change it in a way that makes it less useful for a
> large part of its constituency? I think GC runs completely counter to
> the C philosophy
I do not know about any C "philosophy" that would impose a boring accounting
when not needed.
The gc is written in C, and it interfaces smoothly with C. Besides:
>>>>> it is 100% optional!!! <<<<<<
You do not want the GC and you love to debug malloc/free problems?
No problems. Just use malloc and free! They are part of the standard library
provided with lcc-win32. They are declared in <stdlib.h>.
What bothers me from your message is that you want to impose your point of
view of C philosophy to everyone. Nobody is *forcing* anyone to use the GC.
>
> If you want GC because you write for large, resource rich platforms,
> pick another language that already provides it. The 'me too' philosophy
> fails wherever it is applied.
Every PC is today an incredible resource rich platform. There are almost no
PCs today with less than 64MB of memory, what was the highest high end just
a few years ago.
The C language is not designed for old fashioned micro-controllers either.
Most C applications today run in PCs either under Unix or windows. Since the
hardware environment has changed, new developments and new objectives are
possible and necessary.
But this is an evergreen. Since I read this group you are always from the
side of the "8051"...
"If it doesn't fit in an 8051 it is not C".
"Down with waste. Let's force 99.999% of the users to use a language
designed for the 8051, the 0.0001% of users that counts."
John
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:agrum8$fdv$1...@wanadoo.fr...
>
> > In article <agrhsc$733$1...@wanadoo.fr>, jacob navia
> > <ja...@jacob.remcomp.fr> writes
> > >And then I closed the window, and went on. I still think that the best
> > >language in the C tradition is C itself.
> >
> > So why do you want to change it in a way that makes it less useful for a
> > large part of its constituency? I think GC runs completely counter to
> > the C philosophy
>
> I do not know about any C "philosophy" that would impose a boring
accounting
> when not needed.
> The gc is written in C, and it interfaces smoothly with C. Besides:
>
> >>>>> it is 100% optional!!! <<<<<<
>
> You do not want the GC and you love to debug malloc/free problems?
Of course there are tools that will check that each malloc-ed block
is free-ed - which makes working with these two calls easy enough.
What is the 'C philosophy' then?
John
Francis Glassborow
<ja...@jacob.remcomp.fr> writes
>
>But this is an evergreen. Since I read this group you are always from the
>side of the "8051"...
I think you confuse me with someone else :-)
Francis Glassborow
<inv...@invalid.invalid> writes
>"jacob navia" <ja...@jacob.remcomp.fr> writes:
>> What bothers me from your message is that you want to impose your
>> point of view of C philosophy to everyone. Nobody is *forcing*
>> anyone to use the GC.
>
>libraries that expect to be able to rely on GC; if you dislike GC, or
>can't use it for some reason, then you either have to do without that
>library, modify it to call free() when appropriate, or put up with
>memory leaks.
That is part of it, but you also force every compiler implmentor to
support GC. In practice, the biggest market for C is elsewhere than on
Wintel platforms. The other big market for C is as an intermediate
language and here simplicity and cleanness of implementation is of prime
importance. I do not see GC as something that greatly adds to C's
attractiveness for either of these markets.
jacob navia
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
news:iOQdXqDS...@robinton.demon.co.uk...
> In article <agrum8$fdv$1...@wanadoo.fr>, jacob navia
> <ja...@jacob.remcomp.fr> writes
> >
> >But this is an evergreen. Since I read this group you are always from the
> >side of the "8051"...
>
> I think you confuse me with someone else :-)
OOps!!!
Sorry then. No ofense intended :-)
Chris Hills
>In article <agrum8$fdv$1...@wanadoo.fr>, jacob navia
><ja...@jacob.remcomp.fr> writes
>>
>>But this is an evergreen. Since I read this group you are always from the
>>side of the "8051"...
>
>I think you confuse me with someone else :-)
>
Did you have any one in mind :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
jacob navia
"Chris Hills" <ch...@phaedsys.org> wrote in message
news:DYtylNAF...@phaedsys.demon.co.uk...
> Francis Glassborow <francis.g...@ntlworld.com> writes
> >In article <agrum8$fdv$1...@wanadoo.fr>, jacob navia
> ><ja...@jacob.remcomp.fr> writes
> >>
> >>But this is an evergreen. Since I read this group you are always from
the
> >>side of the "8051"...
> >
> >I think you confuse me with someone else :-)
> >
>
> Did you have any one in mind :-)
No... not really. 8051 forever.
Can't we start real discussions?
I mean, most PCs today are using C in a way that is no longuer justified.
Incorporating hardware simplifies the language. An example is a GC, but
other advances like the decreasing time needed to make a function call are
important too.
Look at this:
We needed (and still do) a good string library. When a friend started
writing it, he proposed that we call a function at each character. That way
we keep flexibility to handle any character sets independent from the
algorithmical part of the string procedure.
Impossible, I thought. That is way too slow.
We measured it, and we would need to handle 20MB strings for this function
call to make a difference of 1 second...
Designing software must be designing for today's machines, and (hopefully)
for the few years to come. Not for yesterday's...
In a PC environment we are no longuer in the conditions of the 8051. A
complex processor, patched and repatched over the eyars, supports an
incredible performance standard undreamt of a few years ago.
Designing software differently would mean emphasizing flexibility,
maintenance, clearness, and easy of adaptation rather than mere machine
cycles. Because in most cases the machine is spending 99.999999% of the time
idling around waiting for something to happen.
Optimizing a program means optimizing the few spots where most of the time
is spent. In other cases, where the difference will never matter, safety,
reliability are much more important.
Most C strings are well under 1 MB, and most would be under a few K!!!
This means that the overhead of a function call is just negligable...
Software can be designed around this fact.
I see an automaton that takes care of garbage collection as a useful tool. I
do not know if this contradicts "the spirit of C" but I am sure there are no
"spirits" that would keep me from using a tool.
jacob
Douglas A. Gwyn
> That accounting is very error prone, and better done by a machine
> than by you personally.
Yes, that is a major role for destructors in C++.
> ... how nicer is to program in a system where you do not have to
> hunt down malloc bugs for ages before your are up and running!
I don't have to hunt down malloc bugs for ages.
Also, there are many debugging versions of malloc around, including
one I've recently developed, that aggressively analyze malloc's data
structures, check for overruns of allocated storage areas, etc. that
can significantly facilitate finding the culprit when some piece of
code is misusing the malloc facility.
> In this times where memory sizes of 512MB are common, ...
And memory sizes of 32KB are common also.
> ... Your program leaks memory to the GC, and so what?
So you may have a bug that you're not tracking down.
It happens that Rob Pike made heavy use of gcalloc() in his Blit code.
There are some real advantages when linked object usage doesn't follow
a simple thread, so the program would have a hard time deciding when a
node could actually be freed. However, use of GC allocation simply
because one is too lazy to get malloc/free right is unprofessional.
Alexander Terekhov
Francis Glassborow wrote:
>
> In article <wwvwury...@rjk.greenend.org.uk>, Richard Kettlewell
> <inv...@invalid.invalid> writes
> >"jacob navia" <ja...@jacob.remcomp.fr> writes:
> >> What bothers me from your message is that you want to impose your
> >> point of view of C philosophy to everyone. Nobody is *forcing*
> >> anyone to use the GC.
> >
> >That's only true up until the point where people starting writing
> >libraries that expect to be able to rely on GC;
That's nothing but "unfounded" FUD, IMHO.
> >if you dislike GC, or
> >can't use it for some reason, then you either have to do without that
> >library, modify it to call free() when appropriate, or put up with
> >memory leaks.
>
> That is part of it, but you also force every compiler implmentor to
> support GC.
So what? Make it *optional* [just like *C++ threads* ;-)].
> In practice, the biggest market for C is elsewhere than on
> Wintel platforms.
That has nothing to do with Wintel platforms.
> The other big market for C is as an intermediate
> language and here simplicity and cleanness of implementation is of prime
> importance. I do not see GC as something that greatly adds to C's
> attractiveness for either of these markets.
Really? Do you really think that "simple" ref.counting-all-over-again,
strong/weak pointers-all-over-again, etc. is really [*universally*]
better than some "reasonable" and *standard* C/C++ GC support [with
post-constructors/resurrectors and pre-destructors/finalizers, of
course ;-)]? And, please, don't tell me some horror stories about
"non-deterministic" behavior and "problems" with resurrection. ;-) ;-)
regards,
alexander.
James Kuyper
>
> In article <wwvwury...@rjk.greenend.org.uk>, Richard Kettlewell
> <inv...@invalid.invalid> writes
> >That's only true up until the point where people starting writing
> >libraries that expect to be able to rely on GC; if you dislike GC, or
> >can't use it for some reason, then you either have to do without that
> >library, modify it to call free() when appropriate, or put up with
> >memory leaks.
>
> That is part of it, but you also force every compiler implmentor to
I'm not sure that's true. After all, we have a specification for
malloc() that fails to specify any situation in which it's required to
return a non-null value. That's even reasonable - you might launch your
program at a time when the system has just barely enough spare memory to
run the program, with none left over for dynamic allocations.
Couldn't we, in the same spirit, put together a specification of GC that
fails to specify any situation in which garbage collection must actually
occur? :-)
Chris Hills
>
>"Chris Hills" <ch...@phaedsys.org> wrote in message
>news:DYtylNAF...@phaedsys.demon.co.uk...
>> Francis Glassborow <francis.g...@ntlworld.com> writes
>> >In article <agrum8$fdv$1...@wanadoo.fr>, jacob navia
>> ><ja...@jacob.remcomp.fr> writes
>> >>
>> >>But this is an evergreen. Since I read this group you are always from
>the
>> >>side of the "8051"...
>> >I think you confuse me with someone else :-)
> Did you have any one in mind :-)
>No... not really. 8051 forever.
last count!)
>Can't we start real discussions?
YEs.
>I mean, most PCs today are using C in a way that is no longuer justified.
??? I thought most PC programming uses C++...
>In a PC environment we are no longuer in the conditions of the 8051.
That is why the (minority) PC programming fraternity tends to use C++
and the much larger embedded programming world still uses c. (BTW the
8051 family is still the largest single CPU type on the planet.)
>A
>complex processor, patched and repatched over the eyars, supports an
>incredible performance standard undreamt of a few years ago.
No. Only un-dreamt of on a PC... PC's are now at workstation
performance,. (at a fraction of the price)
Francis Glassborow
<tere...@web.de> writes
>Really? Do you really think that "simple" ref.counting-all-over-again,
>strong/weak pointers-all-over-again, etc. is really [*universally*]
>better than some "reasonable" and *standard* C/C++ GC support [with
>post-constructors/resurrectors and pre-destructors/finalizers, of
>course ;-)]? And, please, don't tell me some horror stories about
>"non-deterministic" behavior and "problems" with resurrection. ;-) ;-)
We are discussing C here. The issues for C++ are entirely different.
Witless
> Do you really think that "simple" ref.counting-all-over-again,
> strong/weak pointers-all-over-again, etc. is really [*universally*]
> better than some "reasonable" and *standard* C/C++ GC support [with
> post-constructors/resurrectors and pre-destructors/finalizers, of
> course ;-)]?
The implicit assumption that a reasonable GC standard is possible much less
feasible is questionable. The discussions on the topic demonstrate the
unreasonableness of that assumption.
Alexander Terekhov
Francis Glassborow wrote:
>
> In article <3D32C7B2...@web.de>, Alexander Terekhov
> <tere...@web.de> writes
> >Really? Do you really think that "simple" ref.counting-all-over-again,
> >strong/weak pointers-all-over-again, etc. is really [*universally*]
> >better than some "reasonable" and *standard* C/C++ GC support [with
> >post-constructors/resurrectors and pre-destructors/finalizers, of
> >course ;-)]? And, please, don't tell me some horror stories about
> >"non-deterministic" behavior and "problems" with resurrection. ;-) ;-)
>
> We are discussing C here.
That's nothing but >>the subset of C++<<; well, currently,
[and hopefully, that will be fixed rather soon] with just-
a-few *unwarranted* incompatibilities [on both sides, I'd
say] injected probably due to quite popular >>misconception<<
which was actually expressed rather *perfectly* in your
following statement:
> The issues for C++ are entirely different.
regards,
alexander. < dreaming of POSIX.1++ ["right c#"] absorbing
both C and C++; pure "++" as optional "core" >
Francis Glassborow
<tere...@web.de> writes
>> We are discussing C here.
>
>That's nothing but >>the subset of C++<<; well, currently,
>[and hopefully, that will be fixed rather soon] with just-
>a-few *unwarranted* incompatibilities [on both sides, I'd
>say] injected probably due to quite popular >>misconception<<
>which was actually expressed rather *perfectly* in your
>following statement:
If you wish to be taken seriously in this newsgroup I think you will
need to adopt a somewhat different view. I guess your name has already
got into quite a few kill lists and the only reason your posts get seen
is because this group is unmoderated.
James Kuyper
>
> Francis Glassborow wrote:
...
> > We are discussing C here.
>
> That's nothing but >>the subset of C++<<; well, currently,
C is an independent language from C++. It has never been, and was never
intended to be, an exact subset of standard C++. There is a goal to have
a common subset of the two languages which is as large as possible, to
support both shared code and backwards compatibility. It's an explicit
goal for both the C and the C++ committees that neither language should
introduce any gratuitous incompatibilities with the other. However, each
language has it's own distinct mission, and incompatibilities that
further those distinct missions are perfectly acceptable.
Alexander Terekhov
Francis Glassborow wrote:
[...]
> If you wish to be taken seriously in this newsgroup...
Uhmm. "this newsgroup", "quite a few kill lists", etc.
Speak for yourself.
regards,
alexander.
Alexander Terekhov
Francis G... [Reply-To: fran...@robinton.demon.co.uk] wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
> the only reason your posts get seen is because this group
> is unmoderated.
Funny. Just a moment ago my newsreader received a message of
mine approved by some fellow also named Francis... and he is
also @robinton.demon.co.uk [but with ".moderator" instead of
humble "G" ;-) ;-) ].
From: Alexander Terekhov <tere...@web.de>
Newsgroups: comp.lang.c++.moderated
Subject: Re: A comment on Herb Sutter's "Toward
a Standard C++0x Library, Part 1"
Date: 16 Jul 2002 05:45:24 -0400
Sender: cpp...@netlab.cs.rpi.edu
Message-ID: 3D32CD86...@web.de
X-Original-Date: Mon, 15 Jul 2002 15:26:30 +0200
Approved: francis....@robinton.demon.co.uk
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
regards,
alexander.
Alexander Terekhov
James Kuyper wrote:
[...]
> C is an independent language from C++. It has never been, and was never
> intended to be, an exact subset of standard C++. There is a goal to have
> a common subset of the two languages which is as large as possible, to
> support both shared code and backwards compatibility. It's an explicit
> goal for both the C and the C++ committees that neither language should
> introduce any gratuitous incompatibilities with the other. However, each
> language has it's own distinct mission, and incompatibilities that
> further those distinct missions are perfectly acceptable.
I disagree. As for "distinct missions"...
http://www.cuj.com/articles/2002/0208/0208c/0208c.htm?topic=reference
(C and C++: A Case for Compatibility, Bjarne Stroustrup)
I like this:
"....
6. C and C++ are fundamentally different languages. This argument
is either a troll or a statement from someone with a very narrow
notion of ``fundamentally different.'' The differences in the parts
of the languages supporting traditional C programming are minor
and arose from historical accident [4, 5]. For a really different
language, have a look at just about any language that isn't C or
C++, such as ML, Python, Smalltalk, Ada, Prolog, or Scheme.
...."
regards,
alexander.
Dan Pop
If you were not the idiot you seem to be, you would be able to distinguish
between comp.std.c and comp.lang.c++.moderated. The difference is not
that subtle...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Sam Reynolds
I think one needs the other side of the argument to demonstrate
that they really are on different missions. I am in the process of reading
TC++PL, and there as well as in this article you pointed out,
Mr. Stroustrup has plugged compatability between the two languages.
However, it seems to me that to demonstrate that compatability is
genuinely a goal in both camps, we'd need some information from
the other side.
As for there being a C/C++ community (as that article and many
people state) I really disagree. I have mentioned before that the
so-called "C/C++ community" is really just a bunch of C++ people
in my experience. Generally they are lopped together because of
the IMO false idea that C is a subset of C++.
Also IMO, I think any compatability goes only 1 way. Some C++
users may use C code, but I've never seen a C user use C++ code,
especially since to get it to compile, it probably wouldn't be very
good C++ code.
I love C alot, and am working on C++. But I think the two languages
have very different uses, and I don't think I'm a troll, YMMV :)
--
Sam Reynolds
cl...@chool.com
Francis Glassborow
<tere...@web.de> writes
>I disagree. As for "distinct missions"...
>
>http://www.cuj.com/articles/2002/0208/0208c/0208c.htm?topic=reference
>(C and C++: A Case for Compatibility, Bjarne Stroustrup)
and most people round here do not agree with him, some of us politely
and some less so.
Francis Glassborow
<tere...@web.de> writes
>
>Francis G... [Reply-To: fran...@robinton.demon.co.uk] wrote:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>[...]
>> the only reason your posts get seen is because this group
>> is unmoderated.
>
>Funny. Just a moment ago my newsreader received a message of
>mine approved by some fellow also named Francis... and he is
>also @robinton.demon.co.uk [but with ".moderator" instead of
>humble "G" ;-) ;-) ].
>
> From: Alexander Terekhov <tere...@web.de>
> Newsgroups: comp.lang.c++.moderated
LEARN to note where you are. That is comp.lang.c++.moderated, you posted
this to comp.std.c
> Subject: Re: A comment on Herb Sutter's "Toward
> a Standard C++0x Library, Part 1"
> Date: 16 Jul 2002 05:45:24 -0400
> Sender: cpp...@netlab.cs.rpi.edu
> Message-ID: 3D32CD86...@web.de
> X-Original-Date: Mon, 15 Jul 2002 15:26:30 +0200
> Approved: francis....@robinton.demon.co.uk
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>regards,
>alexander.
--
Douglas A. Gwyn
> The implicit assumption that a reasonable GC standard is possible
> much less feasible is questionable. The discussions on the topic
> demonstrate the unreasonableness of that assumption.
To the contrary, a standard for gcalloc() would be nearly trivial:
Where p has type void*volatile and n has type size_t,
gcalloc(&p,n) is equivalent to p=malloc(n), gcrealloc(&p,n)
is equivalent to p=realloc(p,n) when it succeeds (returns
non-zero) or is a no-op when it fails, and gcfree(&p) is
equivalent to free(p); any value of p set by gcalloc or
gcrealloc may change during any later call to any of these
functions.
The issue isn't whether a reasonable standard specification could
be devised; it's about the advisability of requiring and/or
providing such functionality.
Alexander Terekhov
Dan Pop wrote:
[...]
> If you were not the idiot you seem to be, you would be able to distinguish
> between comp.std.c and comp.lang.c++.moderated. The difference is not
> that subtle...
...and your point being?
regards,
alexander.
Alexander Terekhov
Francis Glassborow wrote:
>
> In article <3D3436CD...@web.de>, Alexander Terekhov
> <tere...@web.de> writes
> >
> >Francis G... [Reply-To: fran...@robinton.demon.co.uk] wrote:
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >[...]
> >> the only reason your posts get seen is because this group
> >> is unmoderated.
> >
> >Funny. Just a moment ago my newsreader received a message of
> >mine approved by some fellow also named Francis... and he is
> >also @robinton.demon.co.uk [but with ".moderator" instead of
> >humble "G" ;-) ;-) ].
> >
> > From: Alexander Terekhov <tere...@web.de>
> > Newsgroups: comp.lang.c++.moderated
>
> LEARN to note where you are. That is comp.lang.c++.moderated, you posted
> this to comp.std.c
So what?
regards,
alexander.
James Kuyper
...
> "....
> 6. C and C++ are fundamentally different languages. This argument
> is either a troll or a statement from someone with a very narrow
> notion of ``fundamentally different.'' The differences in the parts
> of the languages supporting traditional C programming are minor
> and arose from historical accident [4, 5]. For a really different
> language, have a look at just about any language that isn't C or
> C++, such as ML, Python, Smalltalk, Ada, Prolog, or Scheme.
> ...."
I did not suggest that C and C++ are fundamentally different. They have
a very deep similarity do to their historical connections. However, with
C++ now widely available, the only people still using C are people who
don't want to use C++, for one reason or another. The people still using
C are the people who will, and should, decide where C should go in the
future; by definition, they want to take it somewhere different from
where C++ is headed.
Chris Hills
Chris Hills
>
>James Kuyper wrote:
>[...]
>> C is an independent language from C++. It has never been, and was never
>> intended to be, an exact subset of standard C++. There is a goal to have
>
>
>http://www.cuj.com/articles/2002/0208/0208c/0208c.htm?topic=reference
>(C and C++: A Case for Compatibility, Bjarne Stroustrup)
AFAIK Bjarnes call for compatibility was thrown out.
James Kuyper
...
> interpreted in that manner? Unless I'm missing something, once a
> program no longer contains any pointers into a region of memory
> allocated with malloc/realloc/calloc there's no way to access that
> memory again, or to detect that the memory is being re-used without a
> call to free(), without invoking at least implementation-defined
> behaviour.
No, as far as the C standard is concerned, a valid pointer to
dynamically allocated memory becomes invalid only when it's actually
free()d, and not before; it doesn't matter whether you've removed all
in-memory copies of the pointer. A program could store a pointer in a
file or have a human memorize it. The program could then erase every
copy it contains of that pointer in memory. At this point a GC system
might choose to collect the memory. Then the program could read the
pointer back in from the file, or have the human type it back in. At
that point, a conforming C implementation has to allow continued use of
that dynamically allocated memory, with it's original values. A GC
implmentation might not be able to.
--
James Kuyper
MODIS Level 1 Lead
Science Data Support Team
(301) 352-2150
Chris Hills
I agree completely. Also the requirements of those using C are usually
very different to those using C++
Witless
You have an interesting definition of "reasonable". One I find more or
less identical to "trivial" rather than "optimum".
Of course it is easy to devise a trivial GC spec, and it would be unwise
to standardize it. It is considerably harder to devise an optimum GC
spec, although if one were available, it might be wise to standardize
it.
Francis Glassborow
<ch...@phaedsys.org> writes
>AFAIK Bjarnes call for compatibility was thrown out.
No, it is an on going topic.
Douglas A. Gwyn
> Of course it is easy to devise a trivial GC spec, and it would be unwise
> to standardize it. It is considerably harder to devise an optimum GC
Actually I already did that for you. At the level of the *general* C
standard, it would be important to not overspecify the implementation.
Obviously, as would be noted in the Rationale document, there are a
wide variety of implementation methods for such a facility, and there
is no evident reason for constraining them any further. No strictly
conforming program could tell the difference, except perhaps by how
soon the allocation subsystem runs out of allocatable space.
David Hopwood
Richard Kettlewell wrote:
> James Kuyper <kuy...@gscmail.gsfc.nasa.gov> writes:
> > I'm not sure that's true. After all, we have a specification for
> > malloc() that fails to specify any situation in which it's required
> > to return a non-null value. That's even reasonable - you might
> > launch your program at a time when the system has just barely enough
> > spare memory to run the program, with none left over for dynamic
> > allocations.
> >
> > Couldn't we, in the same spirit, put together a specification of GC
> > that fails to specify any situation in which garbage collection must
> > actually occur? :-)
>
> Is there anything that explicitly prevents the current standard being
> interpreted in that manner? Unless I'm missing something, once a
> program no longer contains any pointers into a region of memory
> allocated with malloc/realloc/calloc there's no way to access that
> memory again, or to detect that the memory is being re-used without a
> call to free(), without invoking at least implementation-defined
> behaviour.
Not true. Consider casting a pointer to [u]intptr_t, performing some
arithmetic operation(s) to hide it from a conservative GC, and then
casting it back:
char * ptr = malloc(...);
uintptr_t hidden;
if (ptr == NULL) abort();
hidden = (uintptr_t)((uintptr_t)ptr ^ 1);
/* later... */
char * ptr2 = (char *)(uintptr_t)(hidden ^ 1);
Were it not for the fact that [u]intptr_t is not required to be supported,
the above would be strictly conforming code (when included in an otherwise
strictly conforming program, with <stdlib.h> and <stdint.h> included, and
assuming that ptr is not free()'d).
(The two casts of values that are already integers to uintptr_t are to
cover the possibility that uintptr_t could be smaller than unsigned int,
so that "^ 1" causes a promotion.)
It could be argued that this isn't much of a problem because an
implementation that supports GC would not support [u]intptr_t. However,
a similar problem may still arise if you copy the representation of a
pointer:
char * ptr = malloc(...);
unsigned char hidden[sizeof(ptr)];
if (ptr == NULL) abort();
memcpy((unsigned char *) &ptr, hidden, sizeof(ptr));
hidden[0] ^= 1;
/* later... */
char * ptr2;
hidden[0] ^= 1;
memcpy(hidden, (unsigned char *) &ptr2, sizeof(ptr2));
I think this is also strictly conforming (same caveats as before).
The two "hidden[0] ^= 1;" calls are clearly a no-op taken together,
and copying objects that may include pointers using memcpy is explicitly
permitted.
There are additional problems in supporting exact GC; I'm not sure that
would be feasible even if the spec were changed to make the behaviour
of the above code undefined.
- --
David Hopwood <david....@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPTUYTTkCAxeYt5gVAQE2bQgApLrwVMQMPJoJEEQjFD+CDkMc+twd4q6O
/PnaNm9XnaFf0QwzLdT1SZXEYmFIfO5lSZWe558+r3+FIGX4puey4XsH/BoznPra
pUjIS4O8MWBS+hQX3I2oHA2wF5UZGrwx82hhfVYcRiLd88GO5iAN0bhS/sL+rjfQ
NolusqsQZg4Iib36Tr9n1z/yyvl3O9QgwhjmQijgXJ1YrpMM0RtQ+cj6U4gqEl78
j6RsfROYsM9cpXxHQvFJWK6DGrRPS6DbxErte2tApsf7GCd9/oNiC/FJmvXxv6WT
8db2/MuCRAzSMD9ugPN0zA7qXpwM/umGFMx0H1/1hs2cgAgQU300uA==
=DHlk
-----END PGP SIGNATURE-----
Alexander Terekhov
Chris Hills wrote:
>
> Alexander Terekhov <tere...@web.de> writes
> >
> >Dan Pop wrote:
> >[...]
> >> If you were not the idiot you seem to be, you would be able to distinguish
> >> between comp.std.c and comp.lang.c++.moderated. The difference is not
> >> that subtle...
> >
> >...and your point being?
>
> This discussion is on the unmoderated comp.std.c
My, I know. Heck, go up the thread, reread and try to comprehend
[NOT that subtle] point of mine [presuming that I KNOW that this
IS the non-moderated >>comp.std.c<< newsgroup].
regards,
alexander.
-- [the previous C/C++ >>stupidity<< contest; netnews; *WINNER*]
"BTW, I find it strange that you, at the age of 14, are paying
taxes. Is the Belgian state exploiting child labour or what?"
--Stupidity Hall of Fame,[OT] July 4,Dan...@ifh.de
Alexander Terekhov
James Kuyper wrote:
[...]
> I did not suggest that C and C++ are fundamentally different. They have
> a very deep similarity do to their historical connections. However, with
> C++ now widely available, the only people still using C are people who
> don't want to use C++, for one reason or another.
I use both C and C++; for various reasons, on various platforms,
from different vendors... and I just hate, for example, this
[various "unofficial" WEB pages on C99/C++ incompatibilities aside]:
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CBCLR110/A.0?SHELF=CBCBS120
(Title: C/C++ Language Reference|A.0 Appendix A. C and C++ Compatibility
on the z/OS Platform)
> The people still using
> C are the people who will, and should, decide where C should go in the
> future; by definition, they want to take it somewhere different from
> where C++ is headed.
http://www.cuj.com/articles/2002/0208/0208c/0208c.htm?topic=reference
(C and C++: A Case for Compatibility, Bjarne Stroustrup)
"....
There are some good (though, ultimately, answerable) arguments for
incompatibility (see sidebar),
...."
http://www.cuj.com/articles/2002/0208/0208c/0208cs1.htm?topic=reference
(Benefits of Incompatibility?, Sidebar)
< should I really copy&paste to this NG [sidebar included] that entire
(C)-CUJ article? [I have NO problems doing it, BTW]... with the intent
to make it somewhat easier for you to explain your disagreements that
would allow me-stupid to fully comprehend *WHY you oppose the merger*.
Emotions, playing-politics [and things like (emphasis added) "...I
followed the link, and, probably because of my _advanced_age_induced
_stupidity_, am still..." --Francis Glassborow/see c.l.c++.mod] aside,
please. >
regards,
alexander.
Casper H.S. Dik
>Is there anything that explicitly prevents the current standard being
>interpreted in that manner? Unless I'm missing something, once a
>program no longer contains any pointers into a region of memory
>allocated with malloc/realloc/calloc there's no way to access that
>memory again, or to detect that the memory is being re-used without a
>call to free(), without invoking at least implementation-defined
>behaviour.
object *p = malloc(sizeof(object) * NOBJECTS);
/* Legal, pointing one past an array */
p += NOBJECTS;
/* Do I have a reference now? */
p -= NOBJECTS;
/* Now I do */
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Dan Pop
>Richard Kettlewell <inv...@invalid.invalid> writes:
>
>>Is there anything that explicitly prevents the current standard being
>>interpreted in that manner? Unless I'm missing something, once a
>>program no longer contains any pointers into a region of memory
>>allocated with malloc/realloc/calloc there's no way to access that
>>memory again, or to detect that the memory is being re-used without a
>>call to free(), without invoking at least implementation-defined
>>behaviour.
>
>
> object *p = malloc(sizeof(object) * NOBJECTS);
>
> /* Legal, pointing one past an array */
> p += NOBJECTS;
>
> /* Do I have a reference now? */
>
>
> p -= NOBJECTS;
> /* Now I do */
An even more convincing example:
uintptr_t addr = (uintptr_t) malloc(sizeof(object) * NOBJECTS);
No reference at all has been created to the allocated block but we can
have one anytime we want, by converting addr back to a void pointer:
object *p = (void *) addr;
Tony Finch
>
>I liked the other answers better; a garbage collector would presumably
>take into account the fact that you can have a pointer to one past the
>end of a malloc'd region.
The Boehm GC handles such things anyway, as well as simple instances
of casting pointers to uintptr_t. But it places much more stringent
restrictions on an implementation than the standard.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
SOUTH FITZROY: NORTHEASTERLY 5 OR 6 BECOMING VARIABLE 4. FAIR. GOOD.
Douglas A. Gwyn
> /* Legal, pointing one past an array */
> p += NOBJECTS;
> /* Do I have a reference now? */
What you have is a valid pointer value that is "based on" one
obtained from malloc. (The "based on" notion is like that of
restrict qualification.) This is something a compiler could
keep track of (in many common cases).
Chris Hills
>In article <RCLWDYAZ...@phaedsys.demon.co.uk>, Chris Hills
><ch...@phaedsys.org> writes
>>AFAIK Bjarnes call for compatibility was thrown out.
>
>No, it is an on going topic.
>
Not as far as one panel is concerned :-)
Several (who were not at the last meeting) said C++ could do what it
liked as long as it did not touch C. I think that was the majority
position and is not likely to change.
Francis Glassborow
>Francis Glassborow <francis.g...@ntlworld.com> writes
>>In article <RCLWDYAZ...@phaedsys.demon.co.uk>, Chris Hills
>><ch...@phaedsys.org> writes
>>>AFAIK Bjarnes call for compatibility was thrown out.
>>
>>No, it is an on going topic.
>>
>
>Not as far as one panel is concerned :-)
>
>Several (who were not at the last meeting) said C++ could do what it
>liked as long as it did not touch C. I think that was the majority
>position and is not likely to change.
The UK Panel can take any view it likes but it is merely a 'committee'
of one NB and is not empowered to make decisions for WG14. Certainly
WG14 is not minded to take Bjarne's position but nor is it minded to
just ignore it as we would not get away with that in so far as SC22 and
JTC1 are concerned. If we want to retain independence we have to argue
our corner and not just decide to ignore the other side.
James Kuyper
...
> My, I know. Heck, go up the thread, reread and try to comprehend
> [NOT that subtle] point of mine [presuming that I KNOW that this
> IS the non-moderated >>comp.std.c<< newsgroup].
It is subtle enough that several different people have reached the
conclusion that the only explanation for your statement is a lack of
such awareness. Therefore, I recommend re-stating it in a less subtle
way.
Alexander Terekhov
Nah, sorry James, that's way too boring and {usually} results in much
less FUN [I really enjoy netnews replies like "I realise that you are
not a native English speaker but that does not excuse your repeated
failure to understand what you are commenting on", and, BTW, I also
like "Pop" music: din-don-Dan, din-don-Dan, etc./whatever ;-)].
regards,
alexander.
jacob navia
> No, as far as the C standard is concerned, a valid pointer to
> dynamically allocated memory becomes invalid only when it's actually
> free()d, and not before; it doesn't matter whether you've removed all
> in-memory copies of the pointer.
Yes. Do not use a GC in this case please.
> A program could store a pointer in a
> file or have a human memorize it.
Hey James, this is too much really!
> The program could then erase every
> copy it contains of that pointer in memory. At this point a GC system
> might choose to collect the memory. Then the program could read the
> pointer back in from the file, or have the human type it back in. At
> that point, a conforming C implementation has to allow continued use of
> that dynamically allocated memory, with it's original values. A GC
> implmentation might not be able to.
>
It is really incredible how twisted argumentations against a GC can become.
Your message is very interesting because it confirms that there is no worst
blind as the man that doesn't want to see.
In the documentation of lcc-win32 is explicitly stated that the GC assumes
that pointers will NOT be taken to inaccessible locations where the GC can't
see them, including but not limited to:
1) Storing your pointers in the windows extra bytes of each window data
structure. The GC will not look there.
2) Storing your pointers in the hard disk.
3) Storing your pointers in the back of the envelope with your
girlfriend's last love letter. The GC would blush at having to read that
stuff... :-)
jacob navia
"Witless" <wit...@attbi.com> wrote in message
news:3D335BB6...@attbi.com...
> Alexander Terekhov wrote:
>
> > Do you really think that "simple" ref.counting-all-over-again,
> > strong/weak pointers-all-over-again, etc. is really [*universally*]
> > better than some "reasonable" and *standard* C/C++ GC support [with
> > post-constructors/resurrectors and pre-destructors/finalizers, of
> > course ;-)]?
>
> The implicit assumption that a reasonable GC standard is possible much
less
> feasible is questionable.
I think the work of Mr Boehm can't be ignored. He has been a pioneer of
this, and he has established a standard of quality and audace of
implementation that stands above any discussion.
It runs in many OS from windows to linux. It is quite a standard for a GC
implementation for the C language.
The discussions on the topic demonstrate the
> unreasonableness of that assumption.
For a demonstation of the uses of the GC just use it. Then you will se how
nice it is to FORGET ABOUT THAT ERROR PRONE ACCOUNTING!!
Not a demonstration for you?
The discussions about this topic are words. The demonstration is in the
pudding. Use the GC and you will be able to forget about free()...
Where should this object be freed?
Why should I determine where is that place risking an error? Better let the
automaton determine that that memory is nowhere referenced by looking at all
memory that can contain pointers.
The less things I have to keep in mind, the less chance I have to do errors,
and the more effort I can use to bear in the programming problem and not
memory allocation.
jacob navia
The documentation of lcc-win32 explicitely states that if you hide your
pointers from the GC the GC will assume that the pointers do not exist.
Do not use a GC in this situation. The specifications of the GC suppose a
collaborating user. If you do not want the GC (I repeat) just do not use it.
It is an optional feature.
Use malloc/free and support the consequences.
For all others, the GC is then a very useful tool.
jacob navia
>
> /* Legal, pointing one past an array */
> p += NOBJECTS;
>
> /* Do I have a reference now? */
>
>
> p -= NOBJECTS;
> /* Now I do */
>
Yes, this legal code should NOT be translated to:
object *p = GC_malloc(sizeof(object) * NOBJECTS);
If a GC happens at the moment you have no longuer a reference to this
object, the GC could assume that the object can be reclaimed.
Actually, maybe not, since the GC looks at ranges of addresses, and it could
(by chance) be that the GC does not reclaim the corresponding area. I would
NOT rely on this, and do not use the GC.
Use malloc/free and bear the consequences. All others can do:
object *base = p = GC_malloc(sizeof(object) * NOBJECTS);
p += NOBJECTS;
/* Since the pointer "base" still points to the object, the GC will not
reclaim it. */
jacob navia
> An even more convincing example:
>
> uintptr_t addr = (uintptr_t) malloc(sizeof(object) * NOBJECTS);
>
> No reference at all has been created to the allocated block but we can
> have one anytime we want, by converting addr back to a void pointer:
>
> object *p = (void *) addr;
>
And so what? The GC doesn't look at any declarations you do in your C
program. It looks at the stack, so if your "addr" variable is in the stack,
it will see it.
If your "addr" is a global variable it will be seen too since it must be in
the data segment of the program.
jacob navia
> C is nothing but >>the subset of C++<<;
We were talking about C#, not C++ but anyway, it is a related discussion,
since both languages are "supersets" (extensions) of C.
C has been, and will be "extended". Many languages have their origins in C.
C++ is not an exception of course, since at its beginning it was just "C
with objects".
But in the long way from C with objects to the current standard, they got
lost, eaten away by complexity.
C++ got destroyed by complexity, that swallowed our intrepid explorers alive
with their computers and all their templates.
With the advantage of 100% hindsight, obviously that could have been
avoided, and leaves a beacon to the next adventurers. AVOID COMPLEXITY.
Remember C++.
The GC simplifies programming. The programmer is freed from low level and
error-prone tasks to concentrate in the programming task at hand. It avoids
complexity by making free() decisions automatic.
It is interesting that in C++, with all the billion features that were
added, nobody saw this. The trees hid the forest.
jacob navia
> a very deep similarity do to their historical connections. However, with
> C++ now widely available, the only people still using C are people who
> don't want to use C++, for one reason or another. The people still using
> C are the people who will, and should, decide where C should go in the
> future; by definition, they want to take it somewhere different from
> where C++ is headed.
Avoid complexity.
This golden rule was broken by C++ with disastrous consequences. I quote
from:
C/C++ Users Journal, 20(4), April 2002.
One of the things I've noticed that makes Loki so interesting is that "can
compiler XYZ compile Loki?" is becoming something of an unofficial benchmark
in compiler-writer circles. Don't get me wrong, Loki is written entirely in
normal standard-conforming C++-only more standard and more conforming, it
turns out, than some compilers are yet quite ready to digest. [snip] In
fact, at the time the book was released, no commercially available compiler
could compile all of Loki correctly, despite notes to the contrary in the
book's Preface about compilers which could compile most of Loki.
The complexity of C++ is so big that there is no currently available
compiler for the whole language.
jacob navia
> There are some real advantages when linked object usage doesn't follow
> a simple thread, so the program would have a hard time deciding when a
> node could actually be freed. However, use of GC allocation simply
> because one is too lazy to get malloc/free right is unprofessional.
I am not "lazy". I am practical. I do want to do as less boring work as
possible. I got bored tracking those malloc/free bugs.
Yes, there are a lot of tools for malloc/free. I think yours could be quite
good. It can be worthwhile to devise your own malloc/free schema in certain
applications. Your approach is quite justified in big applications for
instance, that want to do specific malloc/free patterns (like deallocating
in a manner similar to the pascal language, where all allocations since a
mark are freed in a single place. That can be really efficient).
But in many applications I have been doing lately, the GC has been a big
help. I do not care for the few ms of GC. I want to concentrate in writing
the application and not in GC.
Tzvetan Mikov
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:ah72vj$skh$1...@wanadoo.fr...
> >
> > An even more convincing example:
> >
> > uintptr_t addr = (uintptr_t) malloc(sizeof(object) * NOBJECTS);
> >
> > No reference at all has been created to the allocated block but we can
> > have one anytime we want, by converting addr back to a void pointer:
> >
> > object *p = (void *) addr;
> >
>
> And so what? The GC doesn't look at any declarations you do in your C
> program. It looks at the stack, so if your "addr" variable is in the
stack,
> it will see it.
Only a conservative collector would do that. A conservative collector is
never 100% reliable, unfortunately. It is true that statistically it might
improve the quality of an average program by eliminating malloc()/free()
bugs, but ultimately I wouldn't use it for a critical application.
-tzvetan
James Kuyper
...
> We were talking about C#, not C++ but anyway, it is a related discussion,
C++ isn't a strict superset of C; however, they do have a common subset.
I've no idea where C# fits in.
...
> The GC simplifies programming. The programmer is freed from low level and
> error-prone tasks to concentrate in the programming task at hand. It avoids
> complexity by making free() decisions automatic.
>
> It is interesting that in C++, with all the billion features that were
> added, nobody saw this. The trees hid the forest.
C++ added a great many features that significantly reduced the need to
explicitly deallocate memeory, and made explicit deallocation much safer
by tying it to destructors and greater type-safety. Implicit
deallocation occurs automatically at the end of an appropriate scope,
which is a reasonable place for it to occur, more often than not. Those
features reduced the incentive for comping up with an alternative way of
doing deallocation.
James Kuyper
...
> It is really incredible how twisted argumentations against a GC can become.
I'm not arguing against GC; I'm arguing about the possibility that it
can be added as an invisible extra feature of a conforming
implementation of C.
I'll grant you, I don't like the loss of control involved in GC, but
I've never argued against on that account. Some people like giving up
control - otherwise automatic transmissions would never have become
popular. Some of us prefer manual tranmissions.
> Your message is very interesting because it confirms that there is no worst
> blind as the man that doesn't want to see.
>
> In the documentation of lcc-win32 is explicitly stated that the GC assumes
> that pointers will NOT be taken to inaccessible locations where the GC can't
> see them, including but not limited to:
>
> 1) Storing your pointers in the windows extra bytes of each window data
> structure. The GC will not look there.
> 2) Storing your pointers in the hard disk.
> 3) Storing your pointers in the back of the envelope with your
> girlfriend's last love letter. The GC would blush at having to read that
> stuff... :-)
Precisely; code violating those limitations is perfectly legal under the
C standard. Therefore, GC with those limitations can't be made as an
invisible addition to a conforming implemenation of C. It can only be
added as an optional feature that is turned off in fully-conforming
mode, or by using some feature (such as #include "GC.h", or allocating
the memory by a call to gcmalloc()) that allows for undefined behavior.
jacob navia
> Only a conservative collector would do that. A conservative collector is
> never 100% reliable, unfortunately. It is true that statistically it might
> improve the quality of an average program by eliminating malloc()/free()
> bugs, but ultimately I wouldn't use it for a critical application.
Mmm it depends... In a critical application any bug in malloc/free can be
quite bad too. There is no silver bullet.
Mr Boehm's collector is conservative. It works for 99% of the normal PC type
applications I would say.
To use it, you have to
#include <gc.h>
It does NOT interfere with the language, nor it forces any specific syntax.
A standard for garbage collectors could be just the name of the gc_malloc
primitive, this way the code would remain portable acros GC implementations.
We would add to stdlib.h:
void *malloc(size_t);
void free(void *);
#ifdef __USE_GC__
void *gc_malloc(size_t);
#define malloc(a) gc_malloc(a)
#define free(a)
#endif
The user would turn on/off this feature with
#define __USE_GC__
Any implementation is free NOT to provide this feature, that should remain
strictly optional.
Tzvetan Mikov
> >
> > Only a conservative collector would do that. A conservative collector is
> > never 100% reliable, unfortunately. It is true that statistically it
might
> > improve the quality of an average program by eliminating malloc()/free()
> > bugs, but ultimately I wouldn't use it for a critical application.
>
> Mmm it depends... In a critical application any bug in malloc/free can be
> quite bad too. There is no silver bullet.
> Mr Boehm's collector is conservative. It works for 99% of the normal PC
type
> applications I would say.
Of course. But how many of them would you define as "critical" ? :-)
-tzvetan
Douglas A. Gwyn
> Actually, maybe not, since the GC looks at ranges of addresses, ...
The address could be punned into an integer and complemented,
for example. The reference is reconstructable by reversing
that transformation, yet it is unlikely that a GC would detect
that the integer value has anything to do with the storage.
A better example was the pointer that was written to a file
and later read back into the same instance of the program.
Naive GC should not be implemented by default, as there are
too many ways existing C programs could be bitten by the GC.
To avoid such problems, the program needs to *cooperate* with
GC by imposing a certain amount of discipline on how it uses
pointer values.
David Hopwood
jacob navia wrote:
> This discussion is superfluous.
>
> The documentation of lcc-win32 explicitely states that if you hide your
> pointers from the GC the GC will assume that the pointers do not exist.
You're missing the point. I like GC (as an optional feature), and I agree
that pointer hiding is not a reason for not using it in practice. My point
was that the existance of strictly conforming C89/99 programs, *no matter
how contrived*, that fail on an implementation with GC, means that it's not
sufficient to just leave the C Standard as it is and use a conservative
GC implementation, as Doug Gwyn and Richard Kettlewell suggested. Such an
implementation would not be conformant to C89 or C99, no matter how much
of a practical improvement it might be.
I think the C0x Standard (or an optional amendment to C99) should be
written so that an implementation that supports GC can conform to it.
I'm not sure how to do that while still giving GC-safe uses of memcpy()
(at least) well-defined and useful behaviour.
Incidentally, this problem is basically the same for C and C++, and it
would be sensible to apply any solution to both languages.
- --
David Hopwood <david....@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPTdhTjkCAxeYt5gVAQGbmwf/SaSD0MJBnw7ZEC3z1LhK0SQMofJDBPnc
QFLGzSYsSKfIrYOuuUZraRlBiyzdemunfvshMA0DOuUkyOx2nmecUf+5EmMYbCKS
Nr8IBDFeLMxNqZwfFNqu8ipAXfLv90IdXHDGF0A6Jmrqf5WIbe8OqfcqGYp0rjZa
sUiSXVz5Hr5i5yefXBdmZ3K1BKUt9iJGZ3AeKNIRirIKmQHl4gQfUKWOpxSiCqVn
9CoTEL27Io7oie3iNE9SRivCaDKvdUuUDwZATXbdeiIMQZfPQbMoKsj8q2nsU+df
D8jw8LpoU/Xq9r4IyRXPSNcbIAyxdlTosrve05d3R9tmFA1dMs5Fmg==
=NeU7
-----END PGP SIGNATURE-----
Douglas A. Gwyn
> ... as Doug Gwyn and Richard Kettlewell suggested.
Actually I pointed out that GC can't be forced upon existing code
but has to have the code work with it. I suggested explicit
gc{whatever}() functions be used, with a specification that says
that the pointer contained in the handle can change whenever a gc
function is called.
Francis Glassborow
<david....@zetnet.co.uk> writes
>I think the C0x Standard (or an optional amendment to C99) should be
>written so that an implementation that supports GC can conform to it.
>I'm not sure how to do that while still giving GC-safe uses of memcpy()
>(at least) well-defined and useful behaviour.
But almost any solution will break existing code. In the case of C++ the
issues are much more complicated because of destructors. However please
note that it is perfectly possible to write destruction functions for
dynamic resources in C.
Alexander Terekhov
jacob navia wrote:
>
> > C is nothing but >>the subset of C++<<;
>
> We were talking about C#,
C# is nothing but MS-visual-basic killer. Java is "brain-dead" too.
[...]
> It is interesting that in C++, with all the billion features that were
> added, nobody saw this. The trees hid the forest.
Read this:
http://www.research.att.com/~bs/dne.html
regards,
alexander.
Alexander Terekhov
Francis Glassborow wrote:
>
> In article <3D378996...@zetnet.co.uk>, David Hopwood
> <david....@zetnet.co.uk> writes
> >I think the C0x Standard (or an optional amendment to C99) should be
> >written so that an implementation that supports GC can conform to it.
> >I'm not sure how to do that while still giving GC-safe uses of memcpy()
> >(at least) well-defined and useful behaviour.
>
> But almost any solution will break existing code.
Uhmm. What exactly do you mean? To me, it would simply "constrain"
existing code w.r.t. doing some rather silly things with GC pointers.
Heck, adding threads could also "break" quite a few lines of existing
code, so what?
> In the case of C++ the
> issues are much more complicated because of destructors.
You mean "non-trivial" destructors, I guess. ;-) Yeah, and one could
even argue that C-GC [not C++-GC] should also support {"optionally"}
the notion of cleanup [pre-destruction and destruction calls] and
resurrection [that would be "post-constructor"/resurrector invocation],
I guess.
regards,
alexander.
David R Tribble
> c#
C# is Microsoft's offering of the Java language. It is to C what Java is to
C, i.e., it is based on a subset of C syntax extended with object-oriented
features. Microsoft claims that C# was derived from C and C++, but it was
really derived (some would say stolen) from Java.
C# is essentially Java with function pointers (called 'delegates') and
broadcast callbacks (called 'events') added. (Both of these features can
be done in Java using interfaces and listener objects.)
One of the more annoying things about C# is that it is so close to Java, yet
Microsoft chose to rename practically everything; type names are lower case
instead of capitalized, variables and methods are capitalized instead of
lower case, and the names in the entire standard library are different (even
down to the base class for all class types, named 'Object' in Java and
'object' in C#). Sheesh.
Comparing C# to C (to bring this thread back onto something relevant for
this newsgroup) is a lot like comparing Java to C. C# has a basic syntax
similar to C, but has enough additions to qualify it as a truly different
language.
C#, like Java, can be compiled into native code, but most applications run
it in 'bytecode' or 'IL' form, which is an interpreted intermediate code.
(Some just-in-time (JIT) execution engines compile portions of the bytecode
dynamically at runtime, and can approach the theoretical speed of pure
native code.) This is the heart and soul of the .NET framework. So while
there is nothing the specification of the C# (or Java) language that
prevents it from being compiled into native code, the most prevalent use of
C# (and Java) programs will be as interpreted IL code.
Saying that C# will replace C is a lot like saying Java or C++ will replace
C. There are simply too many applications, existing and future, that make
this extremely unlikely. Nor will C# make much of a dent in the COBOL, RPG,
and [Visual]Basic arenas, just as C didn't make much of a dent there either.
C# is probably easier to learn than C, because it doesn't have pointers and
provides free garbage collection. On the other hand, it is object-oriented,
which may make it a little harder to learn. And the library for C# (Java)
is much, much larger than the standard library for C (or even C plus Unix).
-- David R Tribble, david @tribble,com --
Chris Hills
>>>No, it is an on going topic.
>>Not as far as one panel is concerned :-)
>>Several (who were not at the last meeting) said C++ could do what it
>>liked as long as it did not touch C. I think that was the majority
>>position and is not likely to change.
>
>The UK Panel can take any view it likes but it is merely a 'committee'
>of one NB and is not empowered to make decisions for WG14. Certainly
>WG14 is not minded to take Bjarne's position but nor is it minded to
>just ignore it as we would not get away with that in so far as SC22 and
Who is "We" ? You are not WG14... you are a member (one of 20) of the
UK panel. As you will recall the majority of the UK panel was against
the proposals by BS.
jacob navia
> UK panel. As you will recall the majority of the UK panel was against
> the proposals by BS.
It would be interesting to have more data here.
Did the UK panel explain their decision? Is there a document that states why
this decision?
Thanks
Francis Glassborow
<ch...@phaedsys.org> writes
>Francis Glassborow <francis.g...@ntlworld.com> writes
>>>>No, it is an on going topic.
>>>Not as far as one panel is concerned :-)
>>>Several (who were not at the last meeting) said C++ could do what it
>>>liked as long as it did not touch C. I think that was the majority
>>>position and is not likely to change.
>>
>>The UK Panel can take any view it likes but it is merely a 'committee'
>>of one NB and is not empowered to make decisions for WG14. Certainly
>
>>WG14 is not minded to take Bjarne's position but nor is it minded to
>>just ignore it as we would not get away with that in so far as SC22 and
>
>Who is "We" ? You are not WG14... you are a member (one of 20) of the
>UK panel. As you will recall the majority of the UK panel was against
>the proposals by BS.
However as well as being a member of the UK Panel, I am also one of
those selected by both WG14 & WG21 to be a member of the liaison group
between those two Committees and designated as being the spokesperson
for that liaison group to WG21 from WG14.
Now I believe that allows me to speak just a little more authoritatively
than as a simple member of the BSI C Panel. And the 'we' in question is
WG14.
If I speak out of turn with regard to WG14 the convenor of WG14 will
tell me, just as if I speak out of turn with regard to the UK their
convenor will say.
Francis Glassborow
Tribble <drt...@yahoo.com> writes
>C, i.e., it is based on a subset of C syntax extended with object-oriented
>features. Microsoft claims that C# was derived from C and C++, but it was
>really derived (some would say stolen) from Java.
Sorry, but I really cannot let that one go by. The original design work
on C# was done in the 1980's and then shelved. Granted that extras were
added when it was reworked at the end of the 90's but that does not
justify the claim that it was derived from Java.
jacob navia
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
news:bdNjDJBu...@robinton.demon.co.uk...
> In article <552e862a.02071...@posting.google.com>, David R
> Tribble <drt...@yahoo.com> writes
> >C, i.e., it is based on a subset of C syntax extended with
object-oriented
> >features. Microsoft claims that C# was derived from C and C++, but it
was
> >really derived (some would say stolen) from Java.
>
> Sorry, but I really cannot let that one go by. The original design work
> on C# was done in the 1980's and then shelved.
Interesting, very interesting. Is there any document that would substantiate
this?
Thanks
Fergus Henderson
>Witless wrote:
>> The implicit assumption that a reasonable GC standard is possible
>> much less feasible is questionable. The discussions on the topic
>> demonstrate the unreasonableness of that assumption.
>
>To the contrary, a standard for gcalloc() would be nearly trivial:
> Where p has type void*volatile and n has type size_t,
> gcalloc(&p,n) is equivalent to p=malloc(n), gcrealloc(&p,n)
> is equivalent to p=realloc(p,n) when it succeeds (returns
> non-zero) or is a no-op when it fails, and gcfree(&p) is
> equivalent to free(p); any value of p set by gcalloc or
> gcrealloc may change during any later call to any of these
> functions.
That wording is not really sufficient.
Consider a simple example:
void *p, *q, *r;
gcalloc(&p,sizeof(int));
q = p;
gcalloc(&r,sizeof(int)); /* can this modify q? */
Is the second call to gcalloc() permitted to modify `q'?
Your wording doesn't really make it clear.
Note that the value of `q' is set by an assignment,
not by gcalloc() or gcrealloc().
To get the wording right, you'd also need to consider unions.
But more importantly, you appear to be designing the wording for a
copying collector, rather than for a conservative collector. Existing
practice for C is to use conservative collectors, not copying
collectors. If we wish to make changes to the C standard to support
GC, I think it would be best at this point to just make the small
changes needed to bless the use of a conservative collector for
malloc(), rather than trying to support copying collection, which
would require adding new interfaces.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Peter S. Shenkin
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message news:ah74g2$lml$1...@wanadoo.fr...
> The complexity of C++ is so big that there is no currently available
> compiler for the whole language.
Whereas for C99 on the other hand.... :-)
--
work: she...@schrodinger.com = 100%
play: she...@mindspring.com = 0%
Peter S. Shenkin = Dull boy
--
Francis Glassborow
<ja...@jacob.remcomp.fr> writes
>> Sorry, but I really cannot let that one go by. The original design work
>> on C# was done in the 1980's and then shelved.
>
>Interesting, very interesting. Is there any document that would substantiate
>this?
some of the original design documents and frequently speak with the
person principally responsible for shelving the project in 1988/89 (IIRC
the dates correctly)
t...@cs.ucr.edu
[...]
: The C language is not designed for old fashioned micro-controllers either.
AFAIK, the C languages was designed (or redesigned) to be applicable
to a large spectrum of computers, micro-controllers among them.
: Most C applications today run in PCs either under Unix or windows.
I don't think so. Embedded processors outnumber desktops, servers and
mainframes by a hundred-to-one margin. AFAIK, most of thos processors
have been programmed in C. So at any given moment the vast majority
of C programs that are running are running on embedded processors.
Tom Payne
t...@cs.ucr.edu
: However, use of GC allocation simply
: because one is too lazy to get malloc/free right is unprofessional.
Why?
Tom Payne
Francis Glassborow
>I don't think so. Embedded processors outnumber desktops, servers and
>mainframes by a hundred-to-one margin. AFAIK, most of thos processors
>have been programmed in C. So at any given moment the vast majority
>of C programs that are running are running on embedded processors.
I agree but with the caveat that in many cases C has been extended to
handle such things as bit variables (found, for example, on the many
derivatives of the 8051/2)
t...@cs.ucr.edu
[... from a priorr posting ...]
: The original design work
: on C# was done in the 1980's and then shelved. Granted that extras were
: added when it was reworked at the end of the 90's but that does not
: justify the claim that it was derived from Java.
: I have seen
: person principally responsible for shelving the project in 1988/89 (IIRC
: the dates correctly)
Can you say which of C#'s features were present in "the original
design work [that] was done in the 80's" and which were "added when it
was reworked at the end of the 90's"?
Tom Payne
Chris Hills
>In article <ahbgkm$ivs$2...@glue.ucr.edu>, t...@cs.ucr.edu writes
>>I don't think so. Embedded processors outnumber desktops, servers and
>>mainframes by a hundred-to-one margin. AFAIK, most of thos processors
>>have been programmed in C. So at any given moment the vast majority
>>of C programs that are running are running on embedded processors.
>
>I agree but with the caveat that in many cases C has been extended to
>handle such things as bit variables (found, for example, on the many
>derivatives of the 8051/2)
This applies to virtually all C compilers not just the embedded ones. If
you look at the Gimpel web site for PC-Lint you will find that they have
over 70 different config files to support the C dialects for compilers
that use extensions etc to ISO
The majority are not cross compilers..... MS compilers are also about as
standard as the average 8051 compiler.
Let him who is without extensions cast the first type :-)
Francis Glassborow
<ch...@phaedsys.org> writes
>>I agree but with the caveat that in many cases C has been extended to
>>handle such things as bit variables (found, for example, on the many
>>derivatives of the 8051/2)
>
>This applies to virtually all C compilers not just the embedded ones.
>If you look at the Gimpel web site for PC-Lint you will find that they
>have over 70 different config files to support the C dialects for
>compilers that use extensions etc to ISO
True, but some compilers have modes that conform to the standard and
some do not. And some extensions are more extreme than others. I would
hazard a guess that a compiler for an 8051 derivative would be little
use if it conformed.
>
>
>The majority are not cross compilers..... MS compilers are also about
>as standard as the average 8051 compiler.
--
Francis Glassborow
>Can you say which of C#'s features were present in "the original
>design work [that] was done in the 80's" and which were "added when it
>was reworked at the end of the 90's"?
Sorry, but I have better things to do and this topic is really far away
from what comp.std.c is intended for.
t...@cs.ucr.edu
: In article <ahedid$ij9$1...@glue.ucr.edu>, t...@cs.ucr.edu writes
:>Can you say which of C#'s features were present in "the original
:>design work [that] was done in the 80's" and which were "added when it
:>was reworked at the end of the 90's"?
: Sorry, but I have better things to do and this topic is really far away
: from what comp.std.c is intended for.
Hmmmmm. So, after eighty-five postings and your astounding claim that
C# has been around since the 80's, you "have better things to do" and
find this thread inappropriate for this group.
Tom Payne
Ross Ridge
>Can you say which of C#'s features were present in "the original
>design work [that] was done in the 80's" and which were "added when it
>was reworked at the end of the 90's"?
Francis Glassborow <fran...@robinton.demon.co.uk> wrote:
>Sorry, but I have better things to do and this topic is really far away
>from what comp.std.c is intended for.
*laughs* We're just supposed to believe your vague hearsay from some
anonymous person? Man, you must really think everyone here is stupid.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/
db //
Mike Schilling
news:3D344023...@web.de...
> I disagree. As for "distinct missions"...
>
> http://www.cuj.com/articles/2002/0208/0208c/0208c.htm?topic=reference
> (C and C++: A Case for Compatibility, Bjarne Stroustrup)
>
> I like this:
>
> "....
> 6. C and C++ are fundamentally different languages. This argument
> is either a troll or a statement from someone with a very narrow
> notion of ``fundamentally different.'' The differences in the parts
> of the languages supporting traditional C programming are minor
> and arose from historical accident [4, 5]. For a really different
> language, have a look at just about any language that isn't C or
> C++, such as ML, Python, Smalltalk, Ada, Prolog, or Scheme.
> ...."
Stroustrup is not a disinterested party in that debate.
Mike Schilling
news:bdNjDJBu...@robinton.demon.co.uk...
> Tribble <drt...@yahoo.com> writes
> >C, i.e., it is based on a subset of C syntax extended with
object-oriented
> >features. Microsoft claims that C# was derived from C and C++, but it
was
> >really derived (some would say stolen) from Java.
>
> Sorry, but I really cannot let that one go by. The original design work
> on C# was done in the 1980's and then shelved. Granted that extras were
> added when it was reworked at the end of the 90's but that does not
> justify the claim that it was derived from Java.
A point-by-point analysis of the two languages completely justifies that
claim.
Francis Glassborow
<rri...@calum.csclub.uwaterloo.ca> writes
>Francis Glassborow <fran...@robinton.demon.co.uk> wrote:
>>Sorry, but I have better things to do and this topic is really far away
>>from what comp.std.c is intended for.
>
>*laughs* We're just supposed to believe your vague hearsay from some
>anonymous person? Man, you must really think everyone here is stupid.
No, but what difference would it make if I gave you an itemised list of
what was in the shelved project and what was latter added? And how is
this anything to do with C? Some people round here do know the kind of
sources I am likely to have and may choose to believe me. But I really
do not care. You just might remember that journalists are supposed to
protect their sources.
t...@cs.ucr.edu
: "Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
As does the timing of C#'s introduction relative to MS's legal
setbacks against Sun. It's possible, neverthless, that MS temporarily
had an effort to graft OO features onto C. I'd be interested to know
how far they got toward what is now known as C#.
Tom Payne
Francis Glassborow
>: A point-by-point analysis of the two languages completely justifies that
>: claim.
>
>As does the timing of C#'s introduction relative to MS's legal
>setbacks against Sun. It's possible, neverthless, that MS temporarily
>had an effort to graft OO features onto C. I'd be interested to know
>how far they got toward what is now known as C#.
If you think about it you will realise that C# was originally MS's in
house replacement for C++ (even the # gives it away, two +'s
superimposed) It is also worth noting that MS was using bytecode in its
C and C++ compilers a long way back as a mechanism for producing small
code when timing was not critical.
Douglas A. Gwyn
> That wording is not really sufficient.
But it's close, for a quick first sketch.
> gcalloc(&r,sizeof(int)); /* can this modify q? */
No. The implication is that GC-controlled pointers have to be
reloaded from the handles after any gc*() function has been called.
This is pretty much the model Apple used for the IIGS and, I think,
Macintosh toolbox.
> But more importantly, you appear to be designing the wording for a
> copying collector, rather than for a conservative collector.
I don't think it is feasible to implement GC for C except with the
aid of some such new interface, with GC restricted to the objects
allocated using that interface; there are simply too many ways for
a s.c. program to hide pointer values so that the GC algorithm
cannot see that there is still a valid reference lurkng somewhere.
Douglas A. Gwyn
Because it means that the developer prefers to produce a bloated
product (since it can never be as memory efficient to use GC as
to explicitly free as soon as possible) rather than think.
jacob navia
"Douglas A. Gwyn" <DAG...@null.net> wrote in message
news:3D3B7568...@null.net...
Think a little then.
1) When one module allocates memory that is shared between several modules,
when will that object be freed?
When are you *certain* that no module references it? How many hours of
debugging you have spent trying to fix this problems?
2) When you write a library, how to ensure that the user will free the
allocated memory? If he forgets about it, he/she will blame you since he/she
is using your library.
3) If you do not use the GC YOU will have a bloated product since it will
contain a memory allocator/deallocator, full of bugs rather than a GC.
4) Your own allocator will add complexity and code to each of your programs
and must be written from scratch at each application. How much human time
does this use? Is human time free? If yes, just waste it. If no, concentrate
on other things rather in rewriting a memory allocator again!
Alexander Terekhov
But he's "right" [in that debate]. I'd personally go even further -- merge
WG14, WG15 and WG21 because I think that [C/C++/POSIX.1] is exactly what
*most* of C/C++ folks use almost every day out there... "memory locations"
and lack of standard [pure but *optional*] >>C++<< Portable Operating System
Interface [POSIX] >>bindings<< aside. ;-)
regards,
alexander.
Alexander Terekhov
Francis Glassborow wrote:
>
> In article <ahfb59$rlh$1...@glue.ucr.edu>, t...@cs.ucr.edu writes
> >: A point-by-point analysis of the two languages completely justifies that
> >: claim.
> >
> >As does the timing of C#'s introduction relative to MS's legal
> >setbacks against Sun. It's possible, neverthless, that MS temporarily
> >had an effort to graft OO features onto C. I'd be interested to know
> >how far they got toward what is now known as C#.
>
> If you think about it you will realise that C# was originally MS's in
> house replacement for C++ (even the # gives it away, two +'s
> superimposed)
http://www.theregister.co.uk/content/28/26042.html
(Why Microsoft makes a complete hash out of C#)
I like this:
"And now Microsoft has appropriated the hash sign for its new software
dev tool C#, supposedly pronounced C Sharp (as in the black key after
C on the piano # denotes 'sharp'in musical notation) but which looks
to many of us as C Hash. And to reader John Timaeus, a "reluctant MCSE"
from Arkansas(we infer from his email addy) it looks even worse...."
http://www.theregister.co.uk/content/28/26108.html
(Why Microsoft C# is 'paralysed or dead')
I like this:
"Sorry, you can't rename C hash as D flat, attractive as the proposition
reads. This name is already taken. Back in 1991-1992 Al Stevens who wrote
(maybe still writes) the "C Programming" column in Dr Dobbs Journal invented
D Flat, an OO C-ish language for the C purists who disliked C++ (and there's
a hash of a language!)."
> It is also worth noting that MS was using bytecode ....
Do you mean MS basic?
regards,
alexander.
Francis Glassborow
<tere...@web.de> writes
>But he's "right" [in that debate]. I'd personally go even further -- merge
>WG14, WG15 and WG21 because I think that [C/C++/POSIX.1] is exactly what
>*most* of C/C++ folks use almost every day out there... "memory locations"
>and lack of standard [pure but *optional*] >>C++<< Portable Operating System
>Interface [POSIX] >>bindings<< aside. ;-)
Note your repeated use of C/C++. Many C++ programmers chose to use C to
complement certain parts of the C++ usage. They also like to access C
libraries that have been shipped in binary. That may or may not work
depending on whether the ABIs are compatible. In fact what most C++
programmers need is compatible header files and ABI.
Now suppose that we forced complete compatibility between C and C++.
I.e. made C a strict subset of C++. Those many programmers who only
require (a perhaps extended) C compiler would now be forced to
communicate their needs to this new combined work group. As they would
now be the minority their wishes would almost certainly go to the back
of the queue and when finally considered, would likely be told that they
were not necessary as there was a complete satisfactory library
solution.
If they had any sense they would band together and create under the
auspices of some standards organisation (necessary to avoid laws
concerning restrictive trade practices) to create a StrictC standard
which they could then develop and extend without regard to the needs of
C++. As C would already be part of C++, the C/C++ work group would
ignore this organisation and real compatibility would get worse.
Standards bodies need to respond to real commercial needs not those
perceived by someone with a specific viewpoint. I have immense respect
for BS and consider him a friend (a view that I have every reason to
believe is reciprocated) however in developing C++ he had a vision of
creating the next version of C. That vision was not and is not shared by
the whole C community.
Note that almost all people who primarily use C++ also use C and almost
all people who primarily use C do NOT use C++. Not all of them make that
choice through ignorance of what C++ is and can do.
Wasting time and energy defending ones corner actually damages
co-operation. I want more co-operation between the pure C and the so
called C/C++ communities. I am convinced that making C a pure subset of
C++ would damage both languages and serve both communities badly.
However working to ensure a compatible common kernel makes sense but
will not happen while the pure C community feels that C++ is attempting
to take them over.
Francis Glassborow
<tere...@web.de> writes
>> It is also worth noting that MS was using bytecode ....
>
>Do you mean MS basic?
NO.
Alexander Terekhov
Francis Glassborow wrote:
>
> In article <3D3BD75A...@web.de>, Alexander Terekhov
> <tere...@web.de> writes
> >> It is also worth noting that MS was using bytecode ....
> >
> >Do you mean MS basic?
>
> NO.
OKAY.
regards,
alexander.