 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] dev null> wrote in message
news:48cb8745$1@news.povray.org...
> However, people quite often do think in set-based terms. Most people don't
> have too much of a problem learning SQL, for example.
I beg to differ.
> (Although having said that, some people insist on processing tasks row by
> row rather than using a set-based solution...)
Because they don't understand the set-based way of thinking
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Sep-08 11:47, Gail wrote:
>
> "Orchid XP v8" <voi### [at] devnull> wrote in message
> news:48cb8646$1@news.povray.org...
>>
>> Maybe that's part of the problem - I don't have any C programming
>> resources where I can actually look things up. So if something doesn't
>> work, there's the Borland C++ help file, or there's experimentation.
>> Neither of these things help terribly much.
>>
>
> Such a pity that no free C/C++ language guide exists...
>
> http://www.google.com/search?hl=en&q=C+language+guide
> http://www.google.com/search?q=C%2B%2B+language+guide
>
> Please note the deliberate sarcasm in the above statement.
<slighly worried>
That's the second day in a row. I hope all goes well with you and your
new job.
</slighly worried>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > So let me get this straight: You are comparing C in a 10+ years old MS-DOS
> > system to higher-level programming languages (such as Java and Haskell) in
> > modern systems with modern OSes and modern compilers, and based on this you
> > have decided that C sucks?
> As far as I'm aware, C hasn't changed in 20 years, never mind 10.
Compilers, tools and operating systems have. Besides, C itself has changed
as well (the latest standard is from 1999).
Or are you telling me this isn't happening with haskell either? If I'm
not mistaken, haskell didn't even have a debugger until recently.
> Really? I had assumed that after you read past the end of the file, it's
> behaviour is simply undefined. I wasn't expecting the C standard to
> actually bother to define the result of an operation you're not supposed
> to perform.
How are you supposed to detect the end of file if you are not supposed
to ever reach the end of the file? That's kind of contradictory.
> > Besides, reaching the end of file (and getting that -1) is *not* an error.
> No, reaching EOF is not an error - failing to check for EOF is an error.
Since reaching EOF is completely valid, how is the compiler supposed to
make sure that you write a conditional which takes it into account? It can't
do this at runtime because returning EOF is completely valid and not an
error, and thus it cannot raise any exceptions at runtime because EOF was
returned. In fact, returning EOF multiple times is not an error either
(it can be perfectly possible for different parts of the program to read
the same file, and all of them get an EOF when there's nothing more to
read, and all of them still work properly).
So how is the compiler supposed to make sure that you do the "correct"
thing when EOF is returned? What *is* the "correct" thing to do?
> >> I've never seen a C debugger.
> >
> > Thus you base all your prejudices on non-knowledge.
> Yes - because having a debugger would make function names easier to
> remember and pointer syntax less baffling and printf() would work
> right... oh, wait...
Now you are twisting the argument, and arguing for the sake of arguing.
The above context had nothing to do with printf or function names.
> > Luckily haskell doesn't have any arbitrarily selected features in it
> > which you need to memorize (such as for example some function names).
> Well at least you can easily look up Haskell function names.
Yes, that's something not possible with C.
> Maybe that's part of the problem - I don't have any C programming
> resources where I can actually look things up.
Well, I don't have any haskell programming resources where I can
look things up.
(Before you write an answer to that, think about it for a second.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As far as I'm aware, C hasn't changed in 20 years, never mind 10.
>
> Compilers, tools and operating systems have. Besides, C itself has changed
> as well (the latest standard is from 1999).
My main problem with C is it's design. It isn't *designed* to be "safe"
or "easy", it's designed to be efficient. The result is a language which
offers really minimal assistance to programmers. Crawling through a
program with a debugger hardly compares to having a problem detected at
compile-time before the program even runs.
I'm sure compilers and debuggers have got better over time. But that
doesn't change the fundamental design of the language. It's unsafe by
design, and that causes me endless difficulties.
> Or are you telling me this isn't happening with haskell either? If I'm
> not mistaken, haskell didn't even have a debugger until recently.
(And FWIW, the debugger really isn't that good.)
>> Really? I had assumed that after you read past the end of the file, it's
>> behaviour is simply undefined. I wasn't expecting the C standard to
>> actually bother to define the result of an operation you're not supposed
>> to perform.
>
> How are you supposed to detect the end of file if you are not supposed
> to ever reach the end of the file? That's kind of contradictory.
It's different in every language of course, but what typically happens
is that you have a function that says "is this EOF yet?", and if it is,
you stop reading. And if you don't stop, that's a program bug, and
should be signalled as one.
Apparently in C it's arranged differently.
>>>> I've never seen a C debugger.
>>> Thus you base all your prejudices on non-knowledge.
>
>> Yes - because having a debugger would make function names easier to
>> remember and pointer syntax less baffling and printf() would work
>> right... oh, wait...
>
> Now you are twisting the argument, and arguing for the sake of arguing.
> The above context had nothing to do with printf or function names.
My point is that having a debugger doesn't magically solve all the problems.
>>> Luckily haskell doesn't have any arbitrarily selected features in it
>>> which you need to memorize (such as for example some function names).
>
>> Well at least you can easily look up Haskell function names.
>
> Yes, that's something not possible with C.
It wasn't when I was trying to learn it, no. Today, we have the Internet.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> > How are you supposed to detect the end of file if you are not supposed
> > to ever reach the end of the file? That's kind of contradictory.
> It's different in every language of course, but what typically happens
> is that you have a function that says "is this EOF yet?", and if it is,
> you stop reading. And if you don't stop, that's a program bug, and
> should be signalled as one.
I fail to see how that's different from how C does it. You read a value
and check if it was EOF. What's the fundamental difference?
> > Now you are twisting the argument, and arguing for the sake of arguing.
> > The above context had nothing to do with printf or function names.
> My point is that having a debugger doesn't magically solve all the problems.
But it solves many of the problems you are complaining about.
> >> Well at least you can easily look up Haskell function names.
> >
> > Yes, that's something not possible with C.
> It wasn't when I was trying to learn it, no. Today, we have the Internet.
Exactly how is that different from haskell?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mueen Nawaz <m.n### [at] ieeeorg> wrote:
>> And besides, in C you have the STL which makes such operations somewhat
>> easier. Not as nice as C++, perhaps, but more manageable.
>
> How can you have a standard template library in C, given that C has
> absolutely no support for templates?
Good point. But don't they have something similar in function as the
C++ standard library?
--
When you die, you lose a very important part of your life.
-- Brooke Shields
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Good point. But don't they have something similar in function as the
> C++ standard library?
In the standard C library? Nope. The standard C library offers *nothing*
to help the programmer with handling dynamic data (except a few unsafe
string manipulation functions). It also offers no algorithms whatsoever
(except that horrid qsort() function).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous illumina en ce 2008-09-13 03:36 -->
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Orchid XP v8 wrote:
>>> I guess it works differently with a real OS. I've only ever compiled C
>>> code under MS-DOS, and there you don't get "segfaults"
>
>> MS-DOS has no memory protection at all. If you write into address 0x0000,
>> you might overwrite the operating system.
>
> What operating system?
>
MS-DOS, from before Windows 95. You know, a black screen with white text, no
graphical user interface. Everything done from the command prompt.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you see something in the real
world and you think, "Hey! How did they get that effect?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> In the standard C library? Nope. The standard C library offers *nothing*
> to help the programmer with handling dynamic data (except a few unsafe
> string manipulation functions). It also offers no algorithms whatsoever
> (except that horrid qsort() function).
Wow. Crappy.
--
"Cashew?" "Gesundheit!"
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Warp nous illumina en ce 2008-09-13 03:36 -->
>> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>>> MS-DOS has no memory protection at all. If you write into address
>>> 0x0000, you might overwrite the operating system.
>>
>> What operating system?
>>
> MS-DOS, from before Windows 95. You know, a black screen with white text,
> no graphical user interface. Everything done from the command prompt.
I think he's saying MS-DOS doesn't deserve being called an operating
system :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
