 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 17:20, Invisible wrote:
> andrel wrote:
>
>> Yes indeed, and if you look at what he writes about C it is not that
>> he has problems with imperative languages in general but with this one
>> for particular reasons.
>
> I can write you programs in BASIC, Pascal, SDL, Tcl, Java, JavaScript,
> PostScript, or even assembly if I have to. (Depends which processor.
> Obviously.) But C and a few other highly complex and messy languages are
> more than even I can cope with.
I find the 'even I' amusing.
>
>> For fun I tried babelfish:
>> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren.
[snip]
>> dingen als daar te begrijpen terwijl (*v++ = *s++); Wat is het probleem?
>
> My God... It's... It's like... [I'm searching for the HGTTG quote]...
> It's like a psuedo-random assortment of letters!
Is that the quote? From which book?
> Mind you, I would think _every_ language looks like that until you
> understand the rules. ;-)
even more so if the language uses a foreign alphabet or worse.
>
>> Even after adjusting the grammar (Ik begrijp werkelijk niet waarom u
>> het zo hard/moeilijk vindt om C. te leren...) it will still be on the
>> edge of comprehensible and not something any Dutchman would write.
>
> For fun, I tried translating from and then to English with various
> phrases on Google Translate.
Didn't know google had also a translator. Well, not better than
babelfish. Different, but not better.
> This yielded such gems as
>
> "Leave the impact price-increase your body."
>
> I cannot even begin to imagine how the hell it arrived at that... ;-)
>
> With experimentation, it seems that the translation FROM English to
> German significantly breaks sentences,
how would you know?
> while the translation the other way is moderately reliable.
I can not imagine that it will translate the archetypal German sentences
with the verb that closes the sentence 5 lines below the subject in a
readable way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The difference is that it will use a hash table rather than a binary tree.
I mistakenly thought the current map already did that...
> In most cases it considerably reduces memory usage and can potentially be
> much faster. (On the downside you have to be able to come up with a
> high-quality hash function for your elements. A poorly designed function
> can make the hash map very slow.)
So the onus of coming up with a function will be on the user? Will it
provide some defaults?
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I can write you programs in BASIC, Pascal, SDL, Tcl, Java, JavaScript,
>> PostScript, or even assembly if I have to. (Depends which processor.
>> Obviously.) But C and a few other highly complex and messy languages
>> are more than even I can cope with.
> I find the 'even I' amusing.
Do you know how many people can code directly in PostScript? (Small
hint: not many.)
Do you know how many people can code in assembly? (Hint: even fewer.)
>> My God... It's... It's like... [I'm searching for the HGTTG quote]...
>> It's like a psuedo-random assortment of letters!
>
> Is that the quote?
Er, no.
>> With experimentation, it seems that the translation FROM English to
>> German significantly breaks sentences,
>
> how would you know?
Some of the Germans in this forum said so.
>> while the translation the other way is moderately reliable.
>
> I can not imagine that it will translate the archetypal German sentences
> with the verb that closes the sentence 5 lines below the subject in a
> readable way.
Search me.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 19:15, Orchid XP v8 wrote:
>>> I can write you programs in BASIC, Pascal, SDL, Tcl, Java,
>>> JavaScript, PostScript, or even assembly if I have to. (Depends which
>>> processor. Obviously.) But C and a few other highly complex and messy
>>> languages are more than even I can cope with.
>
>> I find the 'even I' amusing.
>
> Do you know how many people can code directly in PostScript? (Small
> hint: not many.)
been there, done that
>
> Do you know how many people can code in assembly? (Hint: even fewer.)
been there, done that (for at least 3-5 processors and the one I built
myself ;) )
I think less people coded postscript than assembly, at least when I was
young (it was part of our university course)
>
>>> My God... It's... It's like... [I'm searching for the HGTTG quote]...
>>> It's like a psuedo-random assortment of letters!
>>
>> Is that the quote?
>
> Er, no.
Ok, what were you looking for, what scene. I don't know which you mean
and I though I knew his material rather well.
>
>>> With experimentation, it seems that the translation FROM English to
>>> German significantly breaks sentences,
>>
>> how would you know?
>
> Some of the Germans in this forum said so.
Ah, ok. So you trust non-native speakers to judge how broken english is.
Makes sense.
>
>>> while the translation the other way is moderately reliable.
>>
>> I can not imagine that it will translate the archetypal German
>> sentences with the verb that closes the sentence 5 lines below the
>> subject in a readable way.
>
> Search me.
>
... Milton Keynes , am I close?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca7536$1@news.povray.org...
>
> I guess it depends what you're trying to do. SQL certainly has a few known
> flaws (default column orderings, anyone?), but in general it makes it
> quite simple and easy to do most things.
What column orderings?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail wrote:
>
> "Invisible" <voi### [at] devnull> wrote in message
> news:48ca7536$1@news.povray.org...
>>
>> I guess it depends what you're trying to do. SQL certainly has a few
>> known flaws (default column orderings, anyone?), but in general it
>> makes it quite simple and easy to do most things.
>
> What column orderings?
Apparently some people consider it a bug that you can write queries that
depend on the order in which columns are returned (rather than by
explicit column names). Since relations are supposed to be sets, that
shouldn't be the case.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca7de8@news.povray.org...
>
> I spent about 3 days trying to figure out the syntax for making function
> pointers work. After endless segfaults, I just gave up. It was too hard.
How often does a C/C++ programmer really need a function pointer? It's one
of those advanced features that 99% of the time isn't needed at all.
> Which one is FALSE? Is that 0 or 1? I know it's one or the other, but I
> can never ever remember which - and it's kind of important!
0. Any other value is true.
> What insane nutcase thought that making assignment an expression as a good
> idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..." then
> my program will silently fail to work correctly, and I'll probably spend
> hours if not days trying to figure out why.
Most compilers will warn about that these days.
It's the same in Java, the same in C#
> Pointers in general usually result in disaster. I constantly get the
> syntax wrong for pointer types, pointer dereferencing, and pointer
> creation.
So don't use them. As Warp and others have shown, it's not necessary in any
way to use pointers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"andrel" <a_l### [at] hotmailcom> wrote in message
news:48C### [at] hotmailcom...
> At times like this I wish for a time machine and go back and shoot the
> moron that first used the 'short-circuit Boolean operators' expression.
> Mind you I am normally not an aggressive person.
I'll help you.
I'm currently having a 'discussion' with an 'enlightened individual' who's
trying to tell me that T-SQL (as in the implementation in MS SQL Server)
does the same short-circuit evaluation that C++ and C# (and probably others)
do.
Please note the deliberate sarcasm in the above statement.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail wrote:
> How often does a C/C++ programmer really need a function pointer?
Hopefully very rarely...
>> Which one is FALSE? Is that 0 or 1? I know it's one or the other, but
>> I can never ever remember which - and it's kind of important!
>
> 0. Any other value is true.
I remember that 0 is one thing and everything else is the opposite. But
I can never remember which is which.
>> What insane nutcase thought that making assignment an expression as a
>> good idea? Seriously, WTF? That's excellent. So if I say "if (x =
>> 5)..." then my program will silently fail to work correctly, and I'll
>> probably spend hours if not days trying to figure out why.
>
> Most compilers will warn about that these days.
> It's the same in Java, the same in C#
In Java, unless x happens to be a bool, you'll get a compile-time error.
In C it's a perfectly valid construct.
>> Pointers in general usually result in disaster. I constantly get the
>> syntax wrong for pointer types, pointer dereferencing, and pointer
>> creation.
>
> So don't use them. As Warp and others have shown, it's not necessary in
> any way to use pointers.
It is in C. If you want printf() to print a string for you, you must
pass a pointer to a string.
Maybe this is one of the things they actually fixed in C++...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> At times like this I wish for a time machine and go back and shoot the
>> moron that first used the 'short-circuit Boolean operators'
>> expression. Mind you I am normally not an aggressive person.
>
> I'll help you.
> I'm currently having a 'discussion' with an 'enlightened individual'
> who's trying to tell me that T-SQL (as in the implementation in MS SQL
> Server) does the same short-circuit evaluation that C++ and C# (and
> probably others) do.
>
> Please note the deliberate sarcasm in the above statement.
...so, an "enlightened individual" is telling an MSVP how her product
speciality works?
That's interesting...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca88be$1@news.povray.org...
>> For fun I tried babelfish:
>> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren. Er
>> is slechts een uiterst klein aantal kernverklaringen (als als, terwijl,
>> terugkeer enz.) en de syntaxis van hen allen is zeer gelijkaardig. Hoe te
>> om functies te schrijven moet u enkel leren, maar dat is het zelfde voor
>> om het even welke taal. Schrijven van wiskundige formules is ook zeer
>> gemakkelijk en gelijkaardig aan bijna elke andere taal die (+ -/* enz.
>> gebruikt). Als u geavanceerder wilt worden, dan leer om series te
>> behandelen en welke & en * (vrij gemakkelijke dingen zich te herinneren,
>> niet bij allen complex), en u bent vrij veel plaatst om 99.999% van de
>> code van C - met inbegrip van dingen als daar te begrijpen terwijl (*v++
>> = *s++); Wat is het probleem?
>
> My God... It's... It's like... [I'm searching for the HGTTG quote]... It's
> like a psuedo-random assortment of letters!
Dis nie soo erg nie. Dis amper die selfte as Afrikaans, behlawe van die 'ij'
konstruk. Die taal is maklik vergelyk its soos Zoeloe.
Wat is jou probleem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48caaeeb$1@news.povray.org...
> ...so, an "enlightened individual" is telling an MSVP how her product
> speciality works?
(MVP)
> That's interesting...
That's one way of putting it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> wrote in message
news:48caab2e$1@news.povray.org...
> Gail wrote:
>>
>> "Invisible" <voi### [at] devnull> wrote in message
>> news:48ca7536$1@news.povray.org...
>>>
>>> I guess it depends what you're trying to do. SQL certainly has a few
>>> known flaws (default column orderings, anyone?), but in general it makes
>>> it quite simple and easy to do most things.
>>
>> What column orderings?
>
> Apparently some people consider it a bug that you can write queries that
> depend on the order in which columns are returned (rather than by explicit
> column names). Since relations are supposed to be sets, that shouldn't be
> the case.
Some people consider it a bug that the order of rows is undefined without an
order by statement.
Fortunatly for my sanity (and that of a few other people) in T-SQL columns
are always returned in the same order if SELECT * is specified. It's the
order of the column in the system tables.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 20:02, Orchid XP v8 wrote:
> Gail wrote:
>
>> How often does a C/C++ programmer really need a function pointer?
>
> Hopefully very rarely...
>
>>> Which one is FALSE? Is that 0 or 1? I know it's one or the other, but
>>> I can never ever remember which - and it's kind of important!
>>
>> 0. Any other value is true.
>
> I remember that 0 is one thing and everything else is the opposite. But
> I can never remember which is which.
It's easy, booleans are a sort of integers following the normal
convention that 0 is false and 1 is true. That any other value also
works comes from the fact that most processors have a zero flag that you
can conditionally jump on. Another example of hardware influencing the
language.
AFAIK the only place where this convention is not used is in shell
scripts in UN*X. Here the reason is that they are originally not
booleans but error codes.
At least that is how I think where the conventions come from. Anyone
more knowledgeable can correct me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 20:10, Gail wrote:
>
> "Invisible" <voi### [at] devnull> wrote in message
> news:48ca88be$1@news.povray.org...
>
>>> For fun I tried babelfish:
>>> Ik werkelijk begrijp niet waarom u het zo vindt hard om C. te leren.
>>> Er is slechts een uiterst klein aantal kernverklaringen (als als,
>>> terwijl, terugkeer enz.) en de syntaxis van hen allen is zeer
>>> gelijkaardig. Hoe te om functies te schrijven moet u enkel leren,
>>> maar dat is het zelfde voor om het even welke taal. Schrijven van
>>> wiskundige formules is ook zeer gemakkelijk en gelijkaardig aan bijna
>>> elke andere taal die (+ -/* enz. gebruikt). Als u geavanceerder wilt
>>> worden, dan leer om series te behandelen en welke & en * (vrij
>>> gemakkelijke dingen zich te herinneren, niet bij allen complex), en u
>>> bent vrij veel plaatst om 99.999% van de code van C - met inbegrip
>>> van dingen als daar te begrijpen terwijl (*v++ = *s++); Wat is het
>>> probleem?
>>
>> My God... It's... It's like... [I'm searching for the HGTTG quote]...
>> It's like a psuedo-random assortment of letters!
>
> Dis nie soo erg nie. Dis amper die selfte as Afrikaans, behlawe van die
> 'ij' konstruk.
The ij is originally 'ii' with the second 'i' notifying that it is a
long vowel. Nowadays it is a single glyph (unless you are using American
software). The sound changed in the area where the official dutch
originates to be the same as the 'ei' 'vowel'.
> Die taal is maklik vergelyk its soos Zoeloe.
Het blijft leuk om een taal van de andere kant van de wereld te zien die
je gewoon kan lezen. Al moet ik zeggen dat als iemand het spreekt het
meer dan een paar seconden kost om het te vertalen en ik dus elke keer
de draad kwijtraak.
> Wat is jou probleem?
Ask Andy, not me ;)
BTW Gail, somewhere in october I will hear if there is a change to visit
SA in 2015. There is also a change that we will be involved in
preparations for that and be there in februari or so...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel a écrit :
>>>> Which one is FALSE? Is that 0 or 1? I know it's one or the other,
>>>> but I can never ever remember which - and it's kind of important!
>>>
>>> 0. Any other value is true.
>>
>> I remember that 0 is one thing and everything else is the opposite.
>> But I can never remember which is which.
>
> It's easy, booleans are a sort of integers following the normal
> convention that 0 is false and 1 is true. That any other value also
> works comes from the fact that most processors have a zero flag that you
> can conditionally jump on. Another example of hardware influencing the
> language.
There is also a similarity between the behaviours of positive integers,
multiplication and addition, and booleans, AND and OR. That is:
Integers Booleans
a*(b+c) = a*b + a*c a AND (b OR c) = (a AND b) OR (a AND c)
0 + a = a false OR a = a
0 * a = 0 false AND a = false
if a>0, a+b>0 for all b if a is true, a OR b is true for all b
And so on...
It does not work out that well if you set true <-> 0.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 21:14, Vincent Le Chevalier wrote:
> andrel a écrit :
>>>>> Which one is FALSE? Is that 0 or 1? I know it's one or the other,
>>>>> but I can never ever remember which - and it's kind of important!
>>>>
>>>> 0. Any other value is true.
>>>
>>> I remember that 0 is one thing and everything else is the opposite.
>>> But I can never remember which is which.
>>
>> It's easy, booleans are a sort of integers following the normal
>> convention that 0 is false and 1 is true. That any other value also
>> works comes from the fact that most processors have a zero flag that
>> you can conditionally jump on. Another example of hardware influencing
>> the language.
>
> There is also a similarity between the behaviours of positive integers,
> multiplication and addition, and booleans, AND and OR. That is:
>
> Integers Booleans
> a*(b+c) = a*b + a*c a AND (b OR c) = (a AND b) OR (a AND c)
> 0 + a = a false OR a = a
> 0 * a = 0 false AND a = false
> if a>0, a+b>0 for all b if a is true, a OR b is true for all b
> And so on...
>
> It does not work out that well if you set true <-> 0.
>
If you take
true <-> 0
false <-> 1
OR <-> *
AND <-> +
it works again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Warp wrote:
> > The difference is that it will use a hash table rather than a binary tree.
> I mistakenly thought the current map already did that...
It's impossible to use a hash table and get the elements in increasing
order with a linear traversal. (Ok, it *is* possible, but then you get an
extremely inefficient hash table.)
> So the onus of coming up with a function will be on the user?
It's impossible to provide good (or even working) hash functions for
all possible user-defined types.
> Will it provide some defaults?
I don't know.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> Method overrides that don't actually override unless you insert special
>> code?
>
> I'm with Warp on this one: what?
I think he means "method overrides that don't actually override unless you
go through the enormous effort of typing the 'virtual' keyword in the
declaration" :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> I believe
> you can insert an element in the middle of a vector.
You can. It's O(n) where n is the number of elements between the insertion
point and the end; but you can.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Alternatively,
>
> while(*v++ = *s++);
>
> I mean, what THE HELL...?
I think it was Linus Torvalds who said:
"It's like that while(*p++ = *q++) strcpy code. It works, sure, but it's the
worst code in the world."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> I really don't understand why you find it so hard to learn C.
> There are only a tiny number of core statements (like if, while, return etc)
> and the syntax of them all is very similar. How to write functions you just
> have to learn, but that's the same for any language. Writing mathematical
> formulae is also very easy and similar to almost every other language (using
> + - / * etc).
Yet there are things in C which even expert C programmers have hard time
understanding. One good example: What does this mean (and why):
(******************putchar) (4 ["Hello"]);
(Yes, that's completely valid standard C.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> You know what? In Java, if you reference a null pointer, a little
> message pops up that says "hey, you just dereferenced a null pointer".
> And it even tells you where it happened. In C, your program just behaves
> bizarely.
Actually no. IIRC the C standard defines that accessing the null pointer
is illegal (and will usually cause a segmentation fault). If you are running
a proper debugger, it will tell you the exact line where the null pointer
was accessed.
> Ditto for EOF
You mean reaching the end of the file is such a fatal error, that the
program must be terminated with an exception?
> array index out of bounds
Unless you use a proper debugger.
> out of memory...
Causes a null pointer access in C.
> (And you don't have to memorise whether 0 is true or false.
I see how that's such a hard thing to memorize.
> Memory leaks? What memory leaks?
Yeah. Java leaks memory constantly. In fact, *everything* is leaked.
> No dangling pointers here either.
Except for the null references.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel a écrit :
> On 12-Sep-08 21:14, Vincent Le Chevalier wrote:
>> There is also a similarity between the behaviours of positive
>> integers, multiplication and addition, and booleans, AND and OR. That is:
>>
>> Integers Booleans
>> a*(b+c) = a*b + a*c a AND (b OR c) = (a AND b) OR (a AND c)
>> 0 + a = a false OR a = a
>> 0 * a = 0 false AND a = false
>> if a>0, a+b>0 for all b if a is true, a OR b is true for all b
>> And so on...
>>
>> It does not work out that well if you set true <-> 0.
>>
> If you take
> true <-> 0
> false <-> 1
> OR <-> *
> AND <-> +
> it works again.
No, it's not as perfect. For example the equality:
(a AND b) OR (a AND c) = a AND (b OR c)
would translate as:
(a+b) * (a+c) = a*a + a*b + a*c + b*c
= a * (1+b+c) + b*c
!= a + b*c
because 1+b+c is not equal to 1 in all cases.
I agree it works in the boolean sense, that is if one side is zero, the
other is too. But you do not have the equality that you have in the
other approach.
I'm nearly sure there is a deeper reason for that but I can't think of
it right now.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> You know what? In Java, if you reference a null pointer, a little
> message pops up that says "hey, you just dereferenced a null pointer".
> And it even tells you where it happened. In C, your program just behaves
> bizarely.
In Java, if you deference a null pointer, it throws a NullPointerException
which basically kills your program if you don't catch it anywhere (and
usually you shouldn't).
In C, your program immediately segfaults, and if it was running under a
debugger you get the line of code where it did. Or at least the address of
the code it was executing.
> Java has a seperate Boolean type, so you can tell when a function
> returns a numer and when it returns a Boolean. (And you don't have to
> memorise whether 0 is true or false. And if you accidentally try to use
> a number where a Boolean is expected, the compiler *tells* you about
> this. And...)
C++ has a bool type. Although it's easy to accidentally convert it to a
number (true + true isn't a compiler error).
> Memory leaks? What memory leaks? No dangling pointers here either.
In Java, you're leaking memory all the time (quote from Warp), and the
runtime environment is trying to clean up the mess behind you. Forgetting
to set a reference to null when you don't plan to use it anymore would keep
it from being cleaned up, and would cause the same effect as not freeing
memory in C/C++.
C++ doesn't need garbage garbage collection because it generates so little
garbage (quote from Bjarne Stroustrup).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> scott wrote:
> > I really don't understand why you find it so hard to learn C.
> (I really don't understand why everybody else finds it so hard to learn
> Haskell, but there we are.)
Because Haskell is not imperative and doesn't use modules. Haskell uses
a paradigm which does not correspond to how normal people think.
(Of course it doesn't help that 90% of the keywords and standard library
function names are obfuscated. Sometimes the names are obscure because the
concept behind them is so obscure. Other times it's simply this weird
obsession Haskell people have with writing code which is as short as
possible, even at the cost of clarity.)
> Any operation involving strings seems to require you to use functions
> with names like "strnmsx" or something. (What, you couldn't afford a few
> more octets for some extra letters?)
Have you looked at the standard library function names in haskell
recently?
(Besides, if you want easy string manipulation, use C++, not C.)
> I spent about 3 days trying to figure out the syntax for making function
> pointers work.
I can't even begin to imagine what do you need function pointers for,
as a C beginner programmer.
I have programmed C/C++ for over 10 years, over half of that
professionally, and I have used function pointers probably less than
a dozen times.
> Which one is FALSE? Is that 0 or 1? I know it's one or the other, but I
> can never ever remember which - and it's kind of important!
You have a ridiculously bad memory if you can't remember such a trivial
thing.
> What insane nutcase thought that making assignment an expression as a
> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..."
> then my program will silently fail to work correctly, and I'll probably
> spend hours if not days trying to figure out why.
Use a proper compiler.
> Boolean operators and bitwise operators. Which is which? Which ones are
> the short-circuit ones, and which aren't? I can never remember.
Says the person who has probably memorized over half of the most
obscure functions and tricks in haskell.
> What's the difference between #include "" and include <>?
Does it matter?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> I think it was Linus Torvalds who said:
> "It's like that while(*p++ = *q++) strcpy code. It works, sure, but it's the
> worst code in the world."
I wouldn't put too much weight on what Torvalds thinks is good code and
bad code. Sure, he developed the linux kernel, but his views of programming
and programming paradigms are just nuts.
(I'm not saying he is wrong in this particular case, just that I don't
consider him any kind of authority or expert on programming and programming
practices.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You know what? In Java, if you reference a null pointer, a little
>> message pops up that says "hey, you just dereferenced a null pointer".
>> And it even tells you where it happened. In C, your program just behaves
>> bizarely.
>
> Actually no. IIRC the C standard defines that accessing the null pointer
> is illegal (and will usually cause a segmentation fault). If you are running
> a proper debugger, it will tell you the exact line where the null pointer
> was accessed.
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", you get "my
program does something really weird which may even require me to reboot
the whole PC to fix". Pascal programs never, ever did that.
>> Ditto for EOF
>
> You mean reaching the end of the file is such a fatal error, that the
> program must be terminated with an exception?
Well, it beats producing random garbage, surely?
>> array index out of bounds
>
> Unless you use a proper debugger.
I've never seen a C debugger. Nor would I know where to find one.
(Although presumably it's a standard tool that a real C programmer would
know how to find and use.)
>> (And you don't have to memorise whether 0 is true or false.
>
> I see how that's such a hard thing to memorize.
There are two possibilities which are apparently equally valid. It's
very difficult to remember which one of them was arbitrarily selected by
the language designers.
>> Memory leaks? What memory leaks?
>
> Yeah. Java leaks memory constantly. In fact, *everything* is leaked.
I was waiting for that one... ;-)
>> No dangling pointers here either.
>
> Except for the null references.
You can still forget to make a pointer point to something, but you can't
accidentally delete a chunk of memory that's still in use.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"andrel" <a_l### [at] hotmailcom> wrote in message
news:48C### [at] hotmailcom...
>
> The ij is originally 'ii' with the second 'i' notifying that it is a long
> vowel. Nowadays it is a single glyph (unless you are using American
> software). The sound changed in the area where the official dutch
> originates to be the same as the 'ei' 'vowel'.
Afrikaans has the 'ji' construct, usually as part of the diminutive suffix
'tjie', but in other places too
>> Die taal is maklik vergelyk its soos Zoeloe.
>
> Het blijft leuk om een taal van de andere kant van de wereld te zien die
> je gewoon kan lezen. Al moet ik zeggen dat als iemand het spreekt het meer
> dan een paar seconden kost om het te vertalen en ik dus elke keer de draad
> kwijtraak.
I'm gonna have to ask for a translation of that. Lost in the 2nd sentance.
My afrikaans isn't as good as I made it out to be.
>
> BTW Gail, somewhere in october I will hear if there is a change to visit
> SA in 2015. There is also a change that we will be involved in
> preparations for that and be there in februari or so...
Feb next year? Cool. It's a good time of the year to visit, if you like hot
weather.
Joburg, Cape
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I really don't understand why you find it so hard to learn C.
>
>> (I really don't understand why everybody else finds it so hard to learn
>> Haskell, but there we are.)
>
> Because Haskell is not imperative and doesn't use modules. Haskell uses
> a paradigm which does not correspond to how normal people think.
Doesn't use modules? What on earth do you mean by that?
> (Of course it doesn't help that 90% of the keywords and standard library
> function names are obfuscated.
I would suggest that 90% is an exaggeration. Truly, there *are* some
pretty dumb name choices in there. (What the hell is "Ix" supposed to
mean? Would an extra 3 characters really kill you?) Some of the
heavily-used string functions have less-than-helpful names. (You called
it "nub"? Is that even in the dictionary? What's wrong with "unique"?)
But mostly it's actually not too bad.
> Sometimes the names are obscure because the
> concept behind them is so obscure.
The only example that springs to bind is "fold". Oh, or perhaps the
wonderfully-named ">>=" operator...
> Other times it's simply this weird
> obsession Haskell people have with writing code which is as short as
> possible, even at the cost of clarity.)
Now if this isn't pure trolling, I don't know what is. :-P
> Have you looked at the standard library function names in haskell
> recently?
Actually, no. I don't know what's in the Haskell standard libraries. I
just type stuff at random, and it somehow works. ;-)
> (Besides, if you want easy string manipulation, use C++, not C.)
Right. I think we've established that this works better in C++ (which,
you'll remember, I've never tried using).
>> I spent about 3 days trying to figure out the syntax for making function
>> pointers work.
>
> I can't even begin to imagine what do you need function pointers for,
> as a C beginner programmer.
FRACTINT uses them fairly heavily. (It's basically OOP, without the
language support.) I guess if you wrote FRACTINT today, you'd use C++
and it would be way easier...
>> Which one is FALSE? Is that 0 or 1? I know it's one or the other, but I
>> can never ever remember which - and it's kind of important!
>
> You have a ridiculously bad memory if you can't remember such a trivial
> thing.
Did you know I also sometimes get left and right mixed up?
>> What insane nutcase thought that making assignment an expression as a
>> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..."
>> then my program will silently fail to work correctly, and I'll probably
>> spend hours if not days trying to figure out why.
>
> Use a proper compiler.
How does that help?
>> Boolean operators and bitwise operators. Which is which? Which ones are
>> the short-circuit ones, and which aren't? I can never remember.
>
> Says the person who has probably memorized over half of the most
> obscure functions and tricks in haskell.
In Haskell, 1) you don't need the non-shortcut versions at all, and 2)
if you use a bitwise operator where a Boolean operator is expected (or
vice versa), you'll get a compile-time error telling you of your
mistake. (But then, the bitwise operators are in a special library that
you have to manually import, whereas the logic ops are imported by
default...)
>> What's the difference between #include "" and include <>?
>
> Does it matter?
I don't know - that would depend on what this answer is, wouldn't it? ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> printf() - obviously.
>
> Any operation involving strings seems to require you to use functions
> with names like "strnmsx" or something. (What, you couldn't afford a few
> more octets for some extra letters?)
When C just started, function names were actually quite limited.
Nowadays, we just abbreviate for the hell of it :P
> Manual memory management is tricky in any language, but at least in
> (say) Pascal, strings are managed for you. And let's face it, strings
> are *the* most common reason for using variable-sized arrays.
In C++, there is a string class that manages most stuff for you.
string a = "foo", b = "bar";
string c = a + b;
> I spent about 3 days trying to figure out the syntax for making function
> pointers work. After endless segfaults, I just gave up. It was too hard.
Function pointers are far from an easy feature.
> What insane nutcase thought that making assignment an expression as a
> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..."
> then my program will silently fail to work correctly, and I'll probably
> spend hours if not days trying to figure out why.
Any good compiler will warn about it; at least if you explicitly ask for it
(it's annoying when the if(x=5) is intentional and you can't make the
compiler shut up about it, a common workaround is if ((x = 5)) which looks
kind of ugly)
> Boolean operators and bitwise operators. Which is which? Which ones are
> the short-circuit ones, and which aren't? I can never remember.
Think of bitwise operators as arithmetic operations.
int foo = 0 * func()
Would it be sane not to execute func() for its side effects just because the
expression is already 0 and it wouldn't change anything? I don't think so.
So the same happens for bitwise operators, they don't short-circuit.
if (foo != NULL && !foo->items.empty() && foo->items[0].isValid())
If foo is null, the first part of the expression is false. If the second
part is ran anyway, your program crashes (null pointer deference).
If foo->items is empty, the second part of the expression is false. If the
third part is ran anyway, your program may crash, or read random data from
memory, or behave unexpectedly (reading off bounds of a standard container
without bounds-checking is the same as reading off array bounds).
You *want* short-circuiting :)
> What's the difference between #include "" and include <>?
I'm not *completely* sure. I think "" searches in the current directory and
other directories listed in the compiler's include path (-I in Unix), while
<> searches in the system include path (/usr/include). So you'd use "" for
your own headers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> I think it was Linus Torvalds who said:
>
>> "It's like that while(*p++ = *q++) strcpy code. It works, sure, but it's
>> the worst code in the world."
>
> I wouldn't put too much weight on what Torvalds thinks is good code and
> bad code.
Neither me, but that quote was amusing.
And I might be wrong and it wasn't him who said it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 23:32, Gail wrote:
>
> "andrel" <a_l### [at] hotmailcom> wrote in message
> news:48C### [at] hotmailcom...
>
>>
>> The ij is originally 'ii' with the second 'i' notifying that it is a
>> long vowel. Nowadays it is a single glyph (unless you are using
>> American software). The sound changed in the area where the official
>> dutch originates to be the same as the 'ei' 'vowel'.
>
> Afrikaans has the 'ji' construct, usually as part of the diminutive
> suffix 'tjie', but in other places too
we have 'je' or 'ie' as diminutibe also but the latter is spoken
language. I never realized that the 'ij' combined vowel would surprise
other people. You would than probably find the translation of '*you*'
even more strange: 'jij'. I immediately parse it as j-ij but if you see
it as j-i-j it may look strange.
>
>>> Die taal is maklik vergelyk its soos Zoeloe.
>>
>> Het blijft leuk om een taal van de andere kant van de wereld te zien
>> die je gewoon kan lezen. Al moet ik zeggen dat als iemand het spreekt
>> het meer dan een paar seconden kost om het te vertalen en ik dus elke
>> keer de draad kwijtraak.
>
> I'm gonna have to ask for a translation of that. Lost in the 2nd sentance.
> My afrikaans isn't as good as I made it out to be.
"I still find it interesting (lit. 'fun' but that does not cover the
meaning) to see a language from the other side of the world and still
being able to read it. I'll have to say that when somebody speaks it it
takes more than a few seconds to translate so I loose it (the thread?)
every time."
>>
>> BTW Gail, somewhere in october I will hear if there is a change to
>> visit SA in 2015. There is also a change that we will be involved in
>> preparations for that and be there in februari or so...
>
> Feb next year? Cool. It's a good time of the year to visit, if you like
> hot weather.
I absolutely hate it. I really do. Everything over 24 Celsius makes me
feel bad. At least here, in Brazil I managed, to my own great surprise.
> Joburg, Cape
both
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 23:01, Vincent Le Chevalier wrote:
> andrel a écrit :
>> On 12-Sep-08 21:14, Vincent Le Chevalier wrote:
>>> There is also a similarity between the behaviours of positive
>>> integers, multiplication and addition, and booleans, AND and OR. That
>>> is:
>>>
>>> Integers Booleans
>>> a*(b+c) = a*b + a*c a AND (b OR c) = (a AND b) OR (a AND c)
>>> 0 + a = a false OR a = a
>>> 0 * a = 0 false AND a = false
>>> if a>0, a+b>0 for all b if a is true, a OR b is true for all b
>>> And so on...
>>>
>>> It does not work out that well if you set true <-> 0.
>>>
>> If you take
>> true <-> 0
>> false <-> 1
>> OR <-> *
>> AND <-> +
>> it works again.
>
> No, it's not as perfect. For example the equality:
> (a AND b) OR (a AND c) = a AND (b OR c)
>
> would translate as:
> (a+b) * (a+c) = a*a + a*b + a*c + b*c
> = a * (1+b+c) + b*c
> != a + b*c
>
> because 1+b+c is not equal to 1 in all cases.
I think that should have been a+b+c. Anyway, the same argument could be
given for (a OR b) AND (a OR c) = a OR (b AND C) in the standard
interpretation.
>
> I agree it works in the boolean sense, that is if one side is zero, the
> other is too. But you do not have the equality that you have in the
> other approach.
>
> I'm nearly sure there is a deeper reason for that but I can't think of
> it right now.
Both interpretations should be interchangeable because of de Morgan's
law. I hope that is deep enough for you. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel a écrit :
> Both interpretations should be interchangeable because of de Morgan's
> law. I hope that is deep enough for you. ;)
Quite so :-) You've just shown me I had never given a good thought about
that... Funny how these things become so ingrained... I actually have a
hard time switching back and forth between the interpretations, I'll
have to train :-D
Thanks!
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 23:04, Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> scott wrote:
>
>>> I really don't understand why you find it so hard to learn C.
>
>> (I really don't understand why everybody else finds it so hard to learn
>> Haskell, but there we are.)
>
> Because Haskell is not imperative and doesn't use modules. Haskell uses
> a paradigm which does not correspond to how normal people think.
Which really is simply because it is not taught at school. There is no
reason for that other than tradition. Trust me, it can be learned and be
as natural as Boolean algebra, base eight
(http://jp.youtube.com/watch?v=a81YvrV7Vv8) or finite state machines,
none of which is taught at highschool nowadays (anymore*).
* The Tom Lehrer song is from 1965 or so.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mueen Nawaz <m.n### [at] ieeeorg> wrote:
>> Warp wrote:
>>> The difference is that it will use a hash table rather than a binary tree.
>
>> I mistakenly thought the current map already did that...
>
> It's impossible to use a hash table and get the elements in increasing
> order with a linear traversal. (Ok, it *is* possible, but then you get an
> extremely inefficient hash table.)
>
>> So the onus of coming up with a function will be on the user?
>
> It's impossible to provide good (or even working) hash functions for
> all possible user-defined types.
>
>> Will it provide some defaults?
>
> I don't know.
Well, I was comparing this all with python dicts. It uses a hashing
function, and does not guarantee any particular order (no attempts of
returning in any sorted manner). The catch is that the key must be
either an number or a string.
I had assumed maps also used hashing function.
So I was just wondering if hashmaps may provide some function for
"common" use cases...
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> The long and short is, I spent several months at college using C, and I
> always round it excrusiatingly difficult to get any of the programs to
> work properly. Unfortunately that's just the way C is designed; nothing
> is checked, the programmer is assumed to know exactly what they're
> doing, and if the programmer does something wrong... well that's just
> too bad.
I thought we were talking about C++.
> In C, just concatinating two strings is an ugly, complex operation. In
> fact, it seems to be easier to just write one string to stdout and then
> write the other, rather than trying to actually concatinate them. The
> language seems to make every tiny little operation really awkward and
> difficult. No thanks...
>
> Still, since I am the *only* person on the entire news server who thinks
> this, I guess I should just let it go.
Yes, but how much fun was Haskell 10 years ago? You're looking at the
state of the wrong language at the wrong time. Do you not think it has
been refined since then?
And besides, in C you have the STL which makes such operations somewhat
easier. Not as nice as C++, perhaps, but more manageable.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Mmm, and you think any sane Haskell programmer would implement the
> Fibonaci numbers that way in a real program? It's an interesting
> teaching example, but seriously, if you *want* Fibonacci numbers for
Thank you for repeating what I've said a few times already. The ugly
C/C++ code you're accustomed to are also "interesting teaching
examples". They teach you all that stuff with pointers and character
arrays because they want to make sure the students understand how things
work in a computer (and for good reason). It's not how programmers do
stuff typically.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ 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:
> 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?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> 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", you get "my
> program does something really weird which may even require me to reboot
> the whole PC to fix".
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?
(Don't get me wrong: C does suck. It's just that your comparison is not
completely fair.)
> >> Ditto for EOF
> >
> > You mean reaching the end of the file is such a fatal error, that the
> > program must be terminated with an exception?
> Well, it beats producing random garbage, surely?
Since when has the EOF value been "random garbage"? In standard C the EOF
value is -1 (integer, not char), and a file read past the end of file will
always return -1. How is that "random garbage"?
Besides, reaching the end of file (and getting that -1) is *not* an error.
It's a completely normal situation which all programs reading files have to
handle. How do you even detect the end of a file without a normal EOF
situation? If reaching the end of the file would cause a fatal error which
terminates the program, that would mean 90% of programs out there would not
work.
Sure, some programming languages might have libraries or other systems
which signal the program the end of file in some other ways, but it's still
not an error to reach the end of the file.
> >> array index out of bounds
> >
> > Unless you use a proper debugger.
> I've never seen a C debugger.
Thus you base all your prejudices on non-knowledge.
> Nor would I know where to find one.
Any decent compiler will have one.
> >> (And you don't have to memorise whether 0 is true or false.
> >
> > I see how that's such a hard thing to memorize.
> There are two possibilities which are apparently equally valid. It's
> very difficult to remember which one of them was arbitrarily selected by
> the language designers.
Luckily haskell doesn't have any arbitrarily selected features in it
which you need to memorize (such as for example some function names).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> What insane nutcase thought that making assignment an expression as a
> >> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..."
> >> then my program will silently fail to work correctly, and I'll probably
> >> spend hours if not days trying to figure out why.
> >
> > Use a proper compiler.
> How does that help?
The compiler warns you that the sentence looks suspicious.
> >> Boolean operators and bitwise operators. Which is which? Which ones are
> >> the short-circuit ones, and which aren't? I can never remember.
> >
> > Says the person who has probably memorized over half of the most
> > obscure functions and tricks in haskell.
> In Haskell, 1) you don't need the non-shortcut versions at all, and 2)
> if you use a bitwise operator where a Boolean operator is expected (or
> vice versa), you'll get a compile-time error telling you of your
> mistake.
You missed my point.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> > Because Haskell is not imperative and doesn't use modules. Haskell uses
> > a paradigm which does not correspond to how normal people think.
> Which really is simply because it is not taught at school.
Usually no programming languages are taught in normal school (unless
you specialize), but imperative OO languages still correspond better to
how people naturally think of tasks.
People don't think of tasks with recursive mathematical definitions.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Sep-08 9:42, Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>>> Because Haskell is not imperative and doesn't use modules. Haskell uses
>>> a paradigm which does not correspond to how normal people think.
>
>> Which really is simply because it is not taught at school.
<restored context>
>> There is no reason for that other than tradition. Trust me,
>> it can be learned and be as natural as Boolean algebra, base eight
>> (http://jp.youtube.com/watch?v=a81YvrV7Vv8) or finite state machines,
>> none of which is taught at highschool nowadays (anymore*).
</restored context>
>
> Usually no programming languages are taught in normal school (unless
> you specialize), but imperative OO languages still correspond better to
> how people naturally think of tasks.
>
> People don't think of tasks with recursive mathematical definitions.
>
They do to some extend, about as much as they naturally think in solving
equations*. Much of what we learn at maths and physics is some sort of
formalization of things we do when solving problems. The techniques and
theories we learn at school are just an arbitrary selection of the
available knowledge. Whether something was natural or not has not been a
reason to include something in the curriculum. If the teachers two or
more generations later try to suggest otherwise, they are more trying to
justify themselves than historically accurate.
Actually part of the motivation of the functional programming designers
was that functional programming better matches to mathematics than
imperative programming. More or less the same holds for declarative
languages that are meant to be a formalization of our logic reasoning.
In short: imperative, declarative, and functional programming (etc.) all
are meant to capture (parts of) normal human reasoning. If you think one
is more natural to people than another that mainly shows that you have
more experience in that style than in others.
*Which may be much more than you normally realize.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
>>> You mean reaching the end of the file is such a fatal error, that the
>>> program must be terminated with an exception?
>
>> Well, it beats producing random garbage, surely?
>
> Since when has the EOF value been "random garbage"? In standard C the EOF
> value is -1 (integer, not char), and a file read past the end of file will
> always return -1. How is that "random garbage"?
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.
> 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.
>> 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...
>> Nor would I know where to find one.
>
> Any decent compiler will have one.
I would imagine so, yes.
>> There are two possibilities which are apparently equally valid. It's
>> very difficult to remember which one of them was arbitrarily selected by
>> the language designers.
>
> 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.
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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Imperative OO languages still correspond better to
> how people naturally think of tasks.
>
> People don't think of tasks with recursive mathematical definitions.
No, they don't. Generally.
However, people quite often do think in set-based terms. Most people
don't have too much of a problem learning SQL, for example. (Although
having said that, some people insist on processing tasks row by row
rather than using a set-based solution...)
Haskell makes set-based thinking quite easy and natural.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Orchid XP v8" <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
