C needs a URL*

[Keith Thompson]

You need to pull your head out of your ass. Java manages it. The MS CLI
languages manage it. C should manage it too, or get left behind on the
DeskTop.

You haven't paid attention to any of the responses in this thread, have
you?

 

[Ian Collins]

You haven't paid attention to any of the responses in this thread, have
you?

Of course not, it's a troll!

 

[Nick]

You need to pull your head out of your ass. Java manages it. The MS CLI
languages manage it. C should manage it too, or get left behind on the
DeskTop.

Still feels the wrong way to do it to me. Instead of building it into
every language in a separate (and probably slightly different) way, this
is something for the operating system.

Just like all the "magic" files under /dev and /proc in Unixy systems.

If fopen("http://example.com/something.prog?id=18","r") is to work, then
all it needs is for the OS to cope with it. I have a vague feeling
that plan9 does something like this.

 

[Malcolm McLean]

Still feels the wrong way to do it to me.  Instead of building it into
every language in a separate (and probably slightly different) way, this
is something for the operating system.

Just like all the "magic" files under /dev and /proc in Unixy systems.

The problem is that internet access files aren't "just" files which
happen to be accessible over the web.

For instance if you load a file from disk then, 90% of the time, you
can ignore the chance of a read error. If the file fails to parse, you
can throw it out.

That's not so easy for an internet file. Connections break, they stall
for periods of time too long to busy-idle but too short to give up,
the data is much more likely to be maliciously tampered with, often
there are serious costs involved in stressing the network by
downloading many gigabytes of garbage. many things are subtly
different. Whilst a transparent "socket == FILE *" approach will work,
a lot of code will still have to be specially written for remote
files.

 

[Felix Palmen]

Still feels the wrong way to do it to me. Instead of building it into
every language in a separate (and probably slightly different) way, this
is something for the operating system.

It /does/ feel wrong, but I'd argue a little differently. I think
there's nothing wrong with a portable "web access" library, but it would
be very wrong to include it in the standard lib.

Java and .NET aren't languages, they are platforms including a defined
virtual machine, one (or several) programming language, and a huge class
library. That's ok for such an integrated platform. It's IMHO nonsense
for a portable¹ language like C, that's intended to work on any platform
solving any kind of problem there. For such a language, the standard
library should be kept reasonably small. You can always use other
libraries as needed.

Regards,
Felix

¹ to make this absolutely clear: With .NET and Java, the /platform/ is
portable while the language works just with exactly that plaform. With
C, it is the /language/ itself that is portable.

 

[Keith Thompson]

Java and .NET aren't languages, they are platforms including a defined
virtual machine, one (or several) programming language, and a huge class
library.

[...]

No, Java is a language. There are implementations of other languages
that use the same platform that was originally implemented for Java.

 

[Felix Palmen]

Java and .NET aren't languages, they are platforms including a defined
virtual machine, one (or several) programming language, and a huge class
library.

[...]

No, Java is a language. There are implementations of other languages
that use the same platform that was originally implemented for Java.

Right. The platform is widely called Java virtual machine. But i bet you
understood very well what I meant.

 

[Nobody]

Still feels the wrong way to do it to me. Instead of building it into
every language in a separate (and probably slightly different) way, this
is something for the operating system.

Just like all the "magic" files under /dev and /proc in Unixy systems.

If fopen("http://example.com/something.prog?id=18","r") is to work, then
all it needs is for the OS to cope with it. I have a vague feeling
that plan9 does something like this.

Interfaces designed for opening files are far too simplistic for URLs.
E.g. for an HTTP URL, whether the request succeeds or fails and the
precise content returned may depend upon various headers (Accept-*,
Cookie, Authorization, Cache-Control). HTTPS has all of the options of
HTTP then a load more options related to SSL.

URL-retrieval libraries typically deal with requests in multiple steps:
create a request, configure any options, initiate the request, monitor the
the request until retrieval commences, determine the status (success or
failure) and discover what is being sent (content-type, encoding, ...),
retrieve the data, clean-up.

 

[Malcolm McLean]

No, Java is a language.  There are implementations of other languages
that use the same platform that was originally implemented for Java.

Presumably someone has written a C to Java-bytecode compiler.

This would be very useful where you need the identical output for
every target machine, and where you want undefined behaviour (by the C
standard) to have a known behaviour (defined by the Java virtual
machine).

 

[Seebs]

Presumably someone has written a C to Java-bytecode compiler.

Not one that makes much sense.

This would be very useful where you need the identical output for
every target machine, and where you want undefined behaviour (by the C
standard) to have a known behaviour (defined by the Java virtual
machine).

It's not all that useful, because you can't really USE the jvm very
well with C, so you have to do horrible things like making huge arrays
and doing all the object manipulation by hand within them to fake
up pointers.

MHO. The people who've done it (several implementations exist) may feel
it's more useful. I think that's solving entirely the wrong problem,
though. If you want predictable behavior, write code portably so it
doesn't depend on implementation-specific behaviors, and you're done,
no special interpreter needed.

-s

 

[Malcolm McLean]

MHO.  The people who've done it (several implementations exist) may feel
it's more useful.  I think that's solving entirely the wrong problem,
though.  If you want predictable behavior, write code portably so it
doesn't depend on implementation-specific behaviors, and you're done,
no special interpreter needed.

The problem is that code like

x = x0 * cos(theta) + y0 * sin(theta);
y = x0 *-sin(theta) + y0 * cos(theta);
drawpixel( (int) x, (int) y);

will always give you a rotation of x0, y0 about the orgin by theta.
But on some machines you might be a pixel out. This can matter,
because if graphics don't match perfectly then you get "stitching".

Solving the problem by writing special maths routines is difficult and
shouldn't be necessary.

 

[Ben Bacarisse]

The problem is that code like

x = x0 * cos(theta) + y0 * sin(theta);
y = x0 *-sin(theta) + y0 * cos(theta);
drawpixel( (int) x, (int) y);

will always give you a rotation of x0, y0 about the orgin by theta.
But on some machines you might be a pixel out. This can matter,
because if graphics don't match perfectly then you get "stitching".

Solving the problem by writing special maths routines is difficult and
shouldn't be necessary.

Java's Math class does not guarantee exactly portable results. Only
SrictMath does that and it prescribes the use of the algorithms
implemented by the netlib fdlibm library. I suspect that linking
against fdlibm would give a program that produces the same result on
nearly as wide a range of systems as Java would.

StrictMath does requires that the algorithms be executed using Java's
floating point semantics but since that is basically IEEE semantics the
C implementation is likely to be doing the same anyway.

I am not saying that there is no advantage to the Java VM approach, just
that a trigonometric example is not a good one since Java defines the
semantics by reference to a widely available C library so there would be
no need to "write special maths routines".

 

[Seebs]

The problem is that code like

x = x0 * cos(theta) + y0 * sin(theta);
y = x0 *-sin(theta) + y0 * cos(theta);
drawpixel( (int) x, (int) y);

will always give you a rotation of x0, y0 about the orgin by theta.
But on some machines you might be a pixel out. This can matter,
because if graphics don't match perfectly then you get "stitching".

But on any given machine, you ought to get the same result on multiple
tries, so you shouldn't see mismatching -- you might have a line be a pixel
different on one machine and on another, but both of the things following
that line will likely match on either machine.

And seriously, if you're looking for an example that affects most people,
you've gotta be able to find something better than floating point -- most
desktop machines have IEEE floating point and will behave identically under
reasonably normal circumstances.

Solving the problem by writing special maths routines is difficult and
shouldn't be necessary.

Fundamentally, I think the problem here is not C, but people not
understanding what C is and what it isn't.

If you want to write code which relies on functionality which
varies from one processor to another, and get the same results everywhere,
C is not the right language to use, *nor should it be*. The cost of making
that "work" would cripple C for the things it does well, and that languages
like Java do poorly.

-s

 

[Default User]

Though if someone with the authority to make a standard stick had just

How long is a standard stick? And what goes into making one?




Brian (requiring minds want to know!)

 

[Nobody]

But on any given machine, you ought to get the same result on multiple
tries, so you shouldn't see mismatching -- you might have a line be a pixel
different on one machine and on another, but both of the things following
that line will likely match on either machine.

And seriously, if you're looking for an example that affects most people,
you've gotta be able to find something better than floating point -- most
desktop machines have IEEE floating point and will behave identically under
reasonably normal circumstances.

Except ... the x87 FPU uses 80-bit precision by default, which means that
"double" calculations have either 64 or 80 bits of precision depending
upon whether intermediate values are stored to memory.

It's entirely possible to end up with e.g. a line's endpoints variying by
one pixel depending upon the direction (i.e. the ordering of the endpoints).

With gcc, you can avoid this by using -ffloat-store, but that carries a
performance penalty.

 

[Malcolm McLean]

But on any given machine, you ought to get the same result on multiple
tries, so you shouldn't see mismatching -- you might have a line be a pixel
different on one machine and on another, but both of the things following
that line will likely match on either machine.

The problem is that absence of stitching on the development machine
doesn't necessarily mean absence of stitching on the target machine.
So you've got, potentially, a very uncomfortable situation.