«

On Nov 30, 1:15*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/ 1/11 10:12 AM, Joshua Maurice wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 30, 7:46 am, Markus Wichmann<nullp...@gmx.net> *wrote:
> >> On 28.11.2011 22:51, Joshua Maurice wrote:
>
> >>> First, political. If you call it pthreads, I suspect Microsoft will
> >>> have some additional bias against implementing it. That is bad.
>
> >> There's no need for M$ to implement pthreads, as there's already a
> >> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
> >> called pthreads-win32.
>
> > If we want to add pthreads, or a direct copy-paste of pthreads spec to
> > the C spec, then Microsoft has to implement it, or we bifurcate the
> > language, and I think we can all agree that would be bad, or at best
> > neutral to what we have now. (I argue worse because then they might
> > start ignoring other aspects of the C standard. Gives them precedent,
> > now that they can never be fully conforming.) I suspect there would be
> > political pushback from Microsoft because of the names. If we can
> > avoid that political mess by simply adopting new names, I'm all for
> > that.
>
> Haven't they already ignored C99?

I don't know. Have they? Then again, I think a lot of people have.
Still, I would think no reason to give them more excuses. So, maybe my
point is wrong in its supposed weight.

I'm still a very big fan of actual formal semantics, which is more or
less required when we start doing low level atomics. I'm specifically
a very big fan of how readable and understandable it is. (It's still
near impossible to reason about for anything but very small examples,
but I suspect it's a lot better than some of the hardware docs.)

Ian Collins <ian-> writes:
> On 12/ 1/11 10:12 AM, Joshua Maurice wrote:
> > On Nov 30, 7:46 am, Markus Wichmann<nullp...@gmx.net> wrote:
> >> On 28.11.2011 22:51, Joshua Maurice wrote:
> >>
> >>> First, political. If you call it pthreads, I suspect Microsoft will
> >>> have some additional bias against implementing it. That is bad.
> >>
> >> There's no need for M$ to implement pthreads, as there's already a
> >> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
> >> called pthreads-win32.
> >
> > If we want to add pthreads, or a direct copy-paste of pthreads spec to
> > the C spec, then Microsoft has to implement it, or we bifurcate the
> > language, and I think we can all agree that would be bad, or at best
> > neutral to what we have now. (I argue worse because then they might
> > start ignoring other aspects of the C standard. Gives them precedent,
> > now that they can never be fully conforming.) I suspect there would be
> > political pushback from Microsoft because of the names. If we can
> > avoid that political mess by simply adopting new names, I'm all for
> > that.
>
> Haven't they already ignored C99?

In totality, perhaps. However, reliance on subsets of C99 is far from
uncommon.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

On Sat, 26 Nov 2011 23:43:47 +0100, jacob navia wrote:
>> Embedded systems outnumber hosted systems by at least an order of
>> magnitude.
>
> So what?
>
> Should we eliminate file i/o because there are a lot of embedded systems
> without any files?

I think you have an insular view of the world.

For desktop computing, C is ancient history. Sure it'll be around for a
while for operating systems and basic command line utilities, but for
most programming it's just a relic - why would anyone use C for a serious
program when there's C++ and Java and .NET?

Embedded programming is the only growth area for C. Embedded IS the
mainstream for C nowadays. But you live in a world where "everything is
an x86 running Windows" and you can't see the big picture.

> Or should we eliminate math.h?
>
> What is the use of having a time.h if the toaster has no clock?

No, because these pieces of cruft are now too well established, going all
the way back to C89. It would have been better if they'd never been
included in the standard library, but that ship has long since sailed.

But there is no reason to add any more cruft to the standard library that
would be better being supplied by implementations (maybe through
standards like POSIX that build on C) WHERE THEY MAKE SENSE on those
implementations.

> I do not understand the philosophy:
>
> "*I* do not need it therefore feature XXX is useless, just 'cruft'."
>
> And if there are 1 million toasters around who cares?
>
> There is surely 1 dvelopment system and ONE developer for all those!

The C standard library doesn't need to do everything. Other libraries can
be used too. Something like the directory structure on native filesystems
is inherently system-specific and non-portable, it has NO PLACE in the C
standard.

My 2c.

On 2011-12-02, Quentin Pope <> wrote:
>
> For desktop computing, C is ancient history.

Seeing as more than 90% of the applications I use on my desktop are
written in C I can't see how you could possibly qualify that statement.

> Sure it'll be around for a
> while for operating systems and basic command line utilities, but for
> most programming it's just a relic - why would anyone use C for a serious
> program when there's C++ and Java and .NET?

Because those languages are terrible, especially the last two.
Also what's the definition of a "serious program"?

--
John Tsiombikas
http://nuclear.mutantstargoat.com/

Le 02/12/11 23:26, Quentin Pope a écrit :
> On Sat, 26 Nov 2011 23:43:47 +0100, jacob navia wrote:
>
> For desktop computing, C is ancient history. Sure it'll be around for a
> while for operating systems and basic command line utilities, but for
> most programming it's just a relic - why would anyone use C for a serious
> program when there's C++ and Java and .NET?
>

C is still very interesting language. Look at "Quentin Pope", the
anonymous troll in this group. He says:


> why would anyone use C for a serious
> program when there's C++ and Java and .NET?

But he does NOT go to a C# or .NET group. He comes to the
C group obviously, since he IS interested in C.

He says that he knows better how the C library should be.

Obviously.

Somebody that says C is "a relic" has surely the know
how and can be taken seriously as to what the future directions
of the language should be.