 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> std::string someText(1000, ' ');
> someText += "Hello";
> someText.at(10) = 'A';
>
> std::vector<int> anArray(1000);
> anArray.at(10) = 5;
>
> std::vector<std::string> anArrayOfStrings(1000);
> anArrayOfStrings.at(10) = "Hello";
>
> std::cout << someText << "\n" << anArrayOfString.at(10) << "\n";
>
> Lots of dynamically allocated data, no pointers anywhere.
So what's the lifetime of the data? The scope of the variable?
As I say, my major problem with C is that as soon as you need anything
other than an int or a char, you start getting segfaults. (By the way...
char, unsigned char, long char... WTF?)
>> Regarding rule 4... does this mean C++ at least manages to provide some
>> standard containers *other* than arrays?
>
> Dynamically allocated vectors, strings, doubly-linked lists, binary trees
> (as sets, multisets, maps and multimaps) and double-ended queues. None of
> them requiring any pointers or 'new' to use. (The upcoming C++ standard
> will also include hashmaps as a new data container.)
Well that's something then.
>>> These rules should be broken only when you get very fluent
>>> with the language and know what you are doing.
>
>> But you can 100% guarantee that any code you read that was written by
>> somebody else will be full of such exceptions. ;-)
>
> Don't make the same mistakes as others.
But surely if I make whole *new* mistakes, nobody will have already
worked out a solution for me? ;-)
(Only kidding...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> Warp wrote:
> > The basic design principle in C++ is that you don't have to pay for
> > what you don't use.
> >
> > C++ supports dynamic binding if you need it, but it's not shoved down
> > your throat by force.
> I prefer the Eiffel way, where the compiler looks at your program and
> automatically decides which things can be bound statically (with all the
> optimisations that follow), and which things actually require dynamic
> binding.
That's incompatible with precompiled and dynamically loadable libraries.
I have always wondered why so many "fancy" languages seem to completely
disregard the idea of dynamically loadable libraries. The idea with them
is that the OS loads them only *once* into memory for all programs to use.
For example, linux (afaik) loads libc.so only once into memory, and all
the myriad of programs which require libc.so use that single copy in memory
rather than each one loading it separately. (Given that libc is something
like 2 megabytes in size and the amount of programs depending on it and
running at any single time in a typical system is counted on the hundreds,
that's a significant memory usage saving.)
Of course it makes the size of the executable files smaller (because
libc and other standard libraries don't need to be linked into them),
saving disk space (and making loading times faster).
> Does it actually build a seperate copy of the function for each data
> type, or just build one generic version that works with all of them?
How could it use one generic function for all possible data types,
given that the data types can have different sizes and even have completely
different implementations for their operators, etc?
One common misconception people have about templates is that they
increase the size of the executable because the functions are created
for each used type. However, this is only true in some cases.
In many cases, however, template functions actually *reduce* the size
of the executable. If you have 20 regular functions somewhere, and you
call only one of them, all the 20 will nevertheless be compiled in the
object file. Then it's up to the linker to remove the ones which are not
called at all. Many linkers don't do this (eg. the gcc linker doesn't),
and those unused 19 functions will be linked into the executable,
incrementing its size, even though they are not used.
If they were template functions, however, the ones which are never
called are never instantiated. No trace of them whatsoever will be
compiled into the object file nor the executable file. They just don't
exist. Thus they don't increase the size of the executable, unlike
regular unused functions do.
Inlining can also help reducing the size of the executable, besides
making the program faster.
The great thing about templates is that the compiler is able to optimize
the code on a per-type basis. For example, if you sort an array of integers,
the compiler will most probably be able to compile each comparison into
a CPU register comparison opcode. If you sort an array of strings, then
it will have to perform a string comparison function call. However, the
original sorting function code was the same. Templates just allow the
compiler to perform better optimizations based on the type.
> > Yes, debug checks are nice. They are nicer if you can turn them off
> > for a final release.
> There is certainly something to be said for that.
> The problem is that, certainly with C anyway, there's no switch to turn
> it ON in the first place. :-(
It depends on the compiler. Some compilers do insert checks in debug
mode.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> So what's the lifetime of the data? The scope of the variable?
Yes.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Really? There isn't some iPhone SDK that just gives you an emulator?
Yep. I think it's installed as an addon to Xcode (Mac's IDE). Only works on
Intel Macs running OS X Leopard.
Or, you can use unofficial SDKs (someone even ported gcc to run *on* the
iPhone), but then you don't get a simulator, or proper documentation, etc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Haskell is a small, simple, logical language. C++ is a huge, messy,
> complex language. I don't see how learning an easy language should
> enable me to learn a hard language.
Don't state that as a fact. I looked at Haskell once, only shortly because
it looked like a big hairy mess.
Probably because I didn't look for long enough.
Go look at C++ for long enough.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Wait... you mean they made it a class?
Want the technicality?
std::string is not a class. It's a typedef for std::basic_string<char>,
which is a template for a class.
...but pretend it's just a class to avoid an early headache...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> The macro preprocessor?
>>
>> You usually don't need it in C++.
>
> Well, from what little I've seen, you "usually" don't need it in C
> either. Unless you want symbolic constants...
const int FOO = 42;
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> (And that you can *query the size* of an array?)
>
> Getting the size of a vector, string, deque and binary tree is O(1).
> (For doubly-linked lists it's not guaranteed.)
And libstdc++ developers decided to keep list::size as O(n) as a tradeoff
(otherwise mutating operations would have to keep the size up-to-date,
making *them* slower).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> If you can learn an obscure language like Haskell, you can learn C++.
>
> I see. And what do you base this observation on?
>
> Haskell is a small, simple, logical language. C++ is a huge, messy,
> complex language. I don't see how learning an easy language should enable
> me to learn a hard language.
Heh, Haskell looks complicated and hard to learn to me. I guess it's
relative to your current experience. I just think that if you have the brain
to understand all of the constructs Haskell provides and why they're cool or
interesting, you have the capability to do the same with any other language,
especially a commonly used one.
> I already *know* Java. ;-)
Oh; aren't there Java programming jobs around?
>> Why don't you put the time into it?
>
> What makes you think I haven't?
The fact that you haven't learned C++ yet. =)
> Actually, at college we spent a whole semester programming in C. I'm sure
> I've recounted the tale before. Basically C is a language designed for
> experts. If you do something dumb, it will make absolutely no attempt to
> save you. It will just merrily produce garbage, and leave you with no hope
> of finding out why. Apparently there are people who know the Secret
> Techniques for debugging C programs, and even writing C programs that are
> correct in the first place - but this wasn't part of the syllabus.
Well, aside from having a good debugger, you just need to be honest with
yourself about what parts of your program you do or don't understand. If
it's not working right, then there must be something about it that you don't
understand, and you need to identify what it is. Prints help with that (If
you're using C++ and not just C, then use cout for simplicity) because they
let you confirm that any given part of the program is working the way you
expect. If you have to ask questions to understand something, pile up a list
and ask them here once in a while. Just be honest with yourself about it:
don't let yourself gloss over an expression that you may have seen somewhere
but only partially understand. That's the sort of thing that will hurt you.
Understand every character of every line in every program you write.
And of course, getting started is always hard. It took me at least two
attempts (separated by learning other languages like JavaScript and VB) to
learn C++.
> As I say, the trouble is that if your program doesn't work, there is no
> way you can ever find out why.
Honestly, binary search with prints works in a lot of cases. If you know
what the program is supposed to do, then you can identify the places it does
something wrong.
> (Especially if you're using something like OpenGL. It's an extremely
> complicated API, and unless you pay money it's not possible to get hold of
> useful documentation.)
OpenGL can be difficult because if you do something wrong it will sometimes
silently fail. And yeah, it's hard to get good documentation (I learned it
by taking a class), but it's fun once you can use it so it may be worth
buying a book on.
Ultimately my point is this: I think you *can* learn it, and if you're
looking for a good programming job, I think you have a lot to gain by doing
so.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Manual memory management?
Less necessary in C++ than in C, with all the container STL libraries
around. When you do need it, I find new and delete to be more intuitive than
malloc and free.
> Pointers vs references?
References are easier than pointers and there's not too much to learn to use
them. C only has pointers.
> Copy constructors and assignment constructors?
These can be difficult. They do mirror concepts used in C though.
> The macro preprocessor?
I think that's more of a C thing than a C++ thing, though it's available in
both.
> Method overrides that don't actually override unless you insert special
> code?
I'm with Warp on this one: what?
> Templates?
They can cause some difficulties. But they can make your life a lot easier
too (STL again).
> Untrapped numeric overflows?
I think C and C++ both have this property. In practice you barely ever have
to worry about it.
> Unchecked array indicies?
Also a C and C++ thing. If you want your array indices checked, and you're
using the std::vector class, you can use the vector.at(index) function. (In
practice though, I usually just add my own asserts.)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> I would say learning C++ is easier than C.
>>
>> Seriously,
Bunch of people have already answered, but I might as well add to the
mix. I'll just add that I made the statement comparing C++ with C. Many
of your complaints seem to be more along the lines of C++ vs <Some other
language>.
Keep in mind I'm not a C++ expert.
> Manual memory management?
Easier in C++ than in C.
> Pointers vs references?
References are easier. Use them unless you need a pointer.
> Copy constructors and assignment constructors?
OK. Perhaps a pain. I haven't dealt with this much elsewhere so I don't
know how bad it is.
> The macro preprocessor?
C++ was designed to minimize the uses of the preprocessor. I think it's
used for stuff like header guards, but off hand I'm not sure of any
other important uses (and would like to be educated...).
> Method overrides that don't actually override unless you insert special code?
Same amount of confusion as everyone else.
> Templates?
*Using* templates make life much easier. I haven't coded them much, so
I can't comment on that.
> Untrapped numeric overflows? Unchecked array indicies?
Same as in C.
I'll grant that C & C++ have their pains. Yes, as you said, the
programmer is expected to know what he/she is doing. But why do you
think you can't program that way? You'll be bitten a few times, and
you'll learn from those mistakes and not make them again later.
I'd never ask someone to do a project in C++ if Java/Python/something
else will do the job. However, knowing C++ has its benefits: Namely
getting a job. My assertion is that it simply is something you *can* learn.
Trust me, I know it's a pain with the wrong resources. I first tried
learning it over 10 years ago and had to deal with the compilers I had
on me not handling the very code in the book I was learning from. The
DOS C++ compiler would give an error. The Windows version would give me
a General Protection Fault (3.1 days) - both were Borland products. Very
discouraging. I wish I could find that book now to see if it was illegal
code.
Then when I was at university, they made me write everything in a text
editor (when I was used to a very helpful IDE for all my coding), and
use an "obscure" command line tool for compilation (g++). And what's
more, for some crazy reason, all my a.out files would be 700K - even a
simple "Hello world" program.
And I tried a number of times since then to learn it, always giving up.
Until, of course, the last time.
In retrospect, the reason was not that the problem was with me, but
with the resources: Bad tools and bad books.
If you do stuff with vectors, you generally don't need arrays. You
don't get a lot of the bugs that arrays provide. You don't need to know
the size of the vector at compile time. You can grow a vector. I believe
you can insert an element in the middle of a vector.
You probably don't need to use pointers and code your own linked list.
The standard library has it for you.
But yes, of course, if you want to know C++ well enough, you should
learn references and pointers.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 1) If you ever get the temptation of using the keyword 'new', don't.
> (And no, "malloc()" is not good either. See rule 3.)
Out of curiosity, how realistic is that? Can you give a scenario where
one *should* use new? (i.e. can't find a way around it).
> 2) If possible, avoid using pointers.
As in, use references instead?
> 3) If possible, avoid functions in the C standard library.
Amen.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>> Dynamically allocated vectors, strings, doubly-linked lists, binary
>> trees
>> (as sets, multisets, maps and multimaps) and double-ended queues. None of
>> them requiring any pointers or 'new' to use. (The upcoming C++ standard
>> will also include hashmaps as a new data container.)
>
> Well that's something then.
That's what I was referring to when I said that most introductory C++
books written in the past either did not mention them or put them
somewhere at the end of the book.
In reality, you should use a vector instead of an array unless you have
a good reason not to. It includes a lot of the protections people look for.
In coding Python, I've used sets and maps a lot. I'm sure you use them
even more in Haskell. I sure wish someone had told me years ago that the
C++ standard library had them.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Dynamically allocated vectors, strings, doubly-linked lists, binary trees
> (as sets, multisets, maps and multimaps) and double-ended queues. None of
> them requiring any pointers or 'new' to use. (The upcoming C++ standard
> will also include hashmaps as a new data container.)
What's a hashmap? Or rather, how does it differ from a map?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Orchid XP v8 wrote:
> >>> The macro preprocessor?
> >>
> >> You usually don't need it in C++.
> >
> > Well, from what little I've seen, you "usually" don't need it in C
> > either. Unless you want symbolic constants...
> const int FOO = 42;
Unfortunately that's not a compiler-time constant in C (although it is
in C++).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> >> (And that you can *query the size* of an array?)
> >
> > Getting the size of a vector, string, deque and binary tree is O(1).
> > (For doubly-linked lists it's not guaranteed.)
> And libstdc++ developers decided to keep list::size as O(n) as a tradeoff
> (otherwise mutating operations would have to keep the size up-to-date,
> making *them* slower).
It's perfectly possible to have an O(1) size() function *and* O(1) splicing,
with the only price to pay that immediately after a splice (one where the
list cannot know how many elements were spliced) size() becomes an O(n)
operation once (but O(1) in subsequent calls).
I really don't understand why standard library developers are not doing
that. I have been studying the problem and can't see any rational reason
not to do that. Some sacrifice the speed of size() to get a constant-time
splice(), others do the other way around, but I have never heard of an
implementation like the one I describe, even though it's perfectly
possible. It's not only possible, it's rather trivial to do. (I have even
tested it myself in practice. There's no problem with it.)
Go figure.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> What's a hashmap? Or rather, how does it differ from a map?
Its usage is otherwise the same as a map, but the order of the elements
is undefined (in other words, if you traverse the hashmap from begin() to
end(), it returns the elements in an unspecified order). It will be called
std::unordered_set and std::unordered_map.
The difference is that it will use a hash table rather than a binary tree.
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.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Warp wrote:
> > 1) If you ever get the temptation of using the keyword 'new', don't.
> > (And no, "malloc()" is not good either. See rule 3.)
> Out of curiosity, how realistic is that? Can you give a scenario where
> one *should* use new? (i.e. can't find a way around it).
I don't know about "should", but there are certainly situations where
there's no way around it, so it's a "must". For example if you want to
write a special dynamic data container not offered by the standard library.
There are also situations where you have to allocate dynamically some
object because it cannot be a direct member variable of a class (eg.
because it doesn't have a default constructor and the constructor
parameters cannot be known when the outer class is constructed, but
only later).
In the latter case it's often a good idea to use some type of smart
pointer (or, alternativaly, forbid the copying/assignment of the outer
class, although that's not always an option).
> > 2) If possible, avoid using pointers.
> As in, use references instead?
Mostly. (Althoug it *is* possible to misuse references. Just not as
easily.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <fak### [at] emailaddress> wrote:
> > As I say, the trouble is that if your program doesn't work, there is no
> > way you can ever find out why.
> Honestly, binary search with prints works in a lot of cases. If you know
> what the program is supposed to do, then you can identify the places it does
> something wrong.
Often a good debugger is easier to use than having to write those prints.
(OTOH debugger breakpoints aren't always the solution either...)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I prefer the Eiffel way, where the compiler looks at your program and
>> automatically decides which things can be bound statically (with all the
>> optimisations that follow), and which things actually require dynamic
>> binding.
>
> That's incompatible with precompiled and dynamically loadable libraries.
It's certainly incompatible with dynamic loading. I don't see a problem
with precompiled code though. (Provided the precompiled code isn't just
a blob of executable data but actually contains enough metadata.)
> I have always wondered why so many "fancy" languages seem to completely
> disregard the idea of dynamically loadable libraries.
Because it's a tricky thing to get right? IDK.
Certainly the Java guys love to scream and shout about how easy this is
in Java. Which is amusing, because actually it *isn't* especially easy.
You still have to write a heap of code yourself to make this possible...
As an aside... does anybody here know anything about how Windoze DLLs
actually work?
>> Does it actually build a seperate copy of the function for each data
>> type, or just build one generic version that works with all of them?
>
> How could it use one generic function for all possible data types,
> given that the data types can have different sizes and even have completely
> different implementations for their operators, etc?
Plain ordinary OOP manages to do this without difficulty. (Argue
amoungst yourselves about how *efficient* it is, but it works.)
> One common misconception people have about templates is that they
> increase the size of the executable because the functions are created
> for each used type. However, this is only true in some cases.
>
> If they were template functions, however, the ones which are never
> called are never instantiated.
>
> Inlining can also help reducing the size of the executable, besides
> making the program faster.
>
> The great thing about templates is that the compiler is able to optimize
> the code on a per-type basis.
...so templates are like a kind of less-stupid macro expansion system?
(Everybody *talks* about how great templates are, or how much templates
suck, but few people ever say what they *are*.)
>>> Yes, debug checks are nice. They are nicer if you can turn them off
>>> for a final release.
>
>> There is certainly something to be said for that.
>
>> The problem is that, certainly with C anyway, there's no switch to turn
>> it ON in the first place. :-(
>
> It depends on the compiler. Some compilers do insert checks in debug
> mode.
Mmm, OK. Well my only experience with writing C is Borland's C compiler
for MS-DOS. (Actually, that's a lie. It was a C++ compiler, but we only
wrote C.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>> complex language. I don't see how learning an easy language should enable
>> me to learn a hard language.
>
> Heh, Haskell looks complicated and hard to learn to me.
Well, I guess there are probably people who look at something like
x = (-b +- Sqrt(b^2 - 4ac)/2a
and go "OH MY GOD! That looks SO complicated!" But actually, if you know
a little algebra, you discover that this contraption is actually quite
straight forward.
> I just think that if you have the brain
> to understand all of the constructs Haskell provides and why they're cool or
> interesting, you have the capability to do the same with any other language,
> especially a commonly used one.
Yes - because "commonly used" = "it's very easy". Oh, wait... :-P
>> I already *know* Java. ;-)
>
> Oh; aren't there Java programming jobs around?
My problem is that I'm not finding *any* programming jobs, for *any*
language. (Or rather, I can find a few jobs with titles like "senior
systems architect" and "lead developer", but I'm not finding anything
like "trainee programmer" or "graduate Java developer".)
>>> Why don't you put the time into it?
>> What makes you think I haven't?
>
> The fact that you haven't learned C++ yet. =)
FWIW, I also failed to learn Latin. And that's *supposed* to be easy!
> Well, aside from having a good debugger, you just need to be honest with
> yourself about what parts of your program you do or don't understand.
Well that's just it. It's not like I have any resources telling me how
to actually program in C++. I just sort of have to take a guess. Oddly
enough, that doesn't work very well.
> And of course, getting started is always hard. It took me at least two
> attempts (separated by learning other languages like JavaScript and VB) to
> learn C++.
Ah, VB... That *other* language I completely failed to learn.
>> As I say, the trouble is that if your program doesn't work, there is no
>> way you can ever find out why.
>
> Honestly, binary search with prints works in a lot of cases. If you know
> what the program is supposed to do, then you can identify the places it does
> something wrong.
Like I said, printing stuff out is usually the bit that won't work.
(Although I gather C++ at least managed to fix this part.)
>> (Especially if you're using something like OpenGL. It's an extremely
>> complicated API, and unless you pay money it's not possible to get hold of
>> useful documentation.)
>
> OpenGL can be difficult because if you do something wrong it will sometimes
> silently fail. And yeah, it's hard to get good documentation (I learned it
> by taking a class), but it's fun once you can use it so it may be worth
> buying a book on.
Possibly a dump question, but... can you actually call a C interface
from C++? At any rate, presumably you can completely forget Warp's
"don't use pointers" rule if you want to talk to OpenGL - or any other
API designed for C. ;-)
> Ultimately my point is this: I think you *can* learn it, and if you're
> looking for a good programming job, I think you have a lot to gain by doing
> so.
Hmm. A good Haskell programmer and a very bad C++ programmer. Which one
would you hire?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 10:16, Invisible wrote:
>>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>>> complex language. I don't see how learning an easy language should
>>> enable me to learn a hard language.
>>
>> Heh, Haskell looks complicated and hard to learn to me.
>
> Well, I guess there are probably people who look at something like
>
> x = (-b +- Sqrt(b^2 - 4ac)/2a
unbalanced parentheses in line 10
> and go "OH MY GOD! That looks SO complicated!" But actually, if you know
> a little algebra, you discover that this contraption is actually quite
> straight forward.
Although very well known and easy I managed to have a proposition in my
thesis on this formula. Which, I admit, no one could understand unless
they knew what was not in my thesis (we are talking about an audience of
approximately just below one). ;)
>> I just think that if you have the brain to understand all of the
>> constructs Haskell provides and why they're cool or interesting, you
>> have the capability to do the same with any other language, especially
>> a commonly used one.
>
> Yes - because "commonly used" = "it's very easy". Oh, wait... :-P
Some people study physics because they have not such a good memory, but
can remember if it makes sense. OTOH some people study medicine because
they can remember things but you don't have to understand (most of) it.
More people are studying medicine than physics, but that does not imply
that I could.
>>> I already *know* Java. ;-)
>>
>> Oh; aren't there Java programming jobs around?
>
> My problem is that I'm not finding *any* programming jobs, for *any*
> language. (Or rather, I can find a few jobs with titles like "senior
> systems architect" and "lead developer", but I'm not finding anything
> like "trainee programmer" or "graduate Java developer".)
I did not contribute to this thread, because I had the feeling this
subject was beaten to death already. I case you forgot, I still think
that you should have stayed in research.
>>>> Why don't you put the time into it?
>>> What makes you think I haven't?
>>
>> The fact that you haven't learned C++ yet. =)
>
> FWIW, I also failed to learn Latin. And that's *supposed* to be easy!
who told you that? Or is that because it can't be hard if they did it
already two thousand years ago?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> > How could it use one generic function for all possible data types,
> > given that the data types can have different sizes and even have completely
> > different implementations for their operators, etc?
> Plain ordinary OOP manages to do this without difficulty.
At the cost of increased memory consumption (by a rather large factor)
and decreased performance. Plus it's difficult to make it work for native
types (at least with any kind of efficiency).
> ...so templates are like a kind of less-stupid macro expansion system?
I suppose you could think of them like that. Of course it's not the
whole story.
(One example of templates being different from preprocessor macros
is that when you instantate a template function or class, it creates
an actual type, with a type name which the linker will see. Preprocessor
macros don't do that.)
> > It depends on the compiler. Some compilers do insert checks in debug
> > mode.
> Mmm, OK. Well my only experience with writing C is Borland's C compiler
> for MS-DOS. (Actually, that's a lie. It was a C++ compiler, but we only
> wrote C.)
For example Visual C++ adds lots of checks into the compiled code in
debug mode (for example iterator range checks, vector bounds checks, etc).
Not every memory error can be caught with it, though. But then you can
use a good profiler for the rest.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Well, I guess there are probably people who look at something like
> x = (-b +- Sqrt(b^2 - 4ac)/2a
> and go "OH MY GOD! That looks SO complicated!" But actually, if you know
> a little algebra, you discover that this contraption is actually quite
> straight forward.
I wouldn't call this straightforward:
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
Short? Yes. Clever? Yes. Easy for a non-haskell-programmer
non-mathematically-oriented person to understand? No.
(The curious thing about that is that it's easy to convince a layman
that it works, but the more (procedural) programming you know, the harder
it will be to understand *why* it works (and isn't, for example, an infinite
recursion that never terminates, as there doesn't seem to be any kind of
termination condition). Also understanding why it procudes the correct
result may be difficult.)
> Possibly a dump question, but... can you actually call a C interface
> from C++?
That's the whole idea.
> At any rate, presumably you can completely forget Warp's
> "don't use pointers" rule if you want to talk to OpenGL - or any other
> API designed for C. ;-)
I don't recall OpenGL requiring that many pointers either. Just tons
of straight function calls.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> At any rate, presumably you can completely forget Warp's "don't use
>> pointers" rule if you want to talk to OpenGL - or any other API
>> designed for C. ;-)
>
> I don't recall OpenGL requiring that many pointers either. Just tons
> of straight function calls.
OpenGL returns lots of IDs for all kinds of stuff, but they are more like
handles.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I wouldn't call this straightforward:
>
> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
OK, well how about this:
while (TRUE) { cont = (*cont)(); }
I wouldn't exactly call that straightfoward either. It's not *actually*
complicated, but it sure *looks* pretty baffling.
Alternatively,
while(*v++ = *s++);
I mean, what THE HELL...?
>> At any rate, presumably you can completely forget Warp's
>> "don't use pointers" rule if you want to talk to OpenGL - or any other
>> API designed for C. ;-)
>
> I don't recall OpenGL requiring that many pointers either. Just tons
> of straight function calls.
Mmm, actually... yes, doesn't it tend to refer to thing by numerical
indecies rather than actual pointers?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca3efa$1@news.povray.org...
>
> while(*v++ = *s++);
>
> I mean, what THE HELL...?
>
I doubt that's the recommended way of copying an array any longer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> while(*v++ = *s++);
>>
>> I mean, what THE HELL...?
>>
>
> I doubt that's the recommended way of copying an array any longer
I doubt that was *ever* the "recommended" way. And yet I, a person who
doesn't know C very well, am aware of this example. What does that tell
you? ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 13:01, Gail wrote:
>
> "Invisible" <voi### [at] devnull> wrote in message
> news:48ca3efa$1@news.povray.org...
>
>>
>> while(*v++ = *s++);
>>
>> I mean, what THE HELL...?
A nice example of language design inspired by hardware (and vice versa).
May result in very fast code.
>>
>
> I doubt that's the recommended way of copying an array any longer
I don't think it is a problem as long as the string is known to be null
terminated. Don't put it in a library though. These are bound to be used
by people who have never heard of the concept of preconditions. Or
yourself in a weak moment after midnight.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> > I wouldn't call this straightforward:
> >
> > fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
> OK, well how about this:
> while (TRUE) { cont = (*cont)(); }
> I wouldn't exactly call that straightfoward either. It's not *actually*
> complicated, but it sure *looks* pretty baffling.
But the haskell code is normal, regular haskell. Your C example is
not code any sane person would write.
> Alternatively,
> while(*v++ = *s++);
> I mean, what THE HELL...?
At least it's easy to understand what it does (and why it works) when
it's explained. The haskell example isn't.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> >> while(*v++ = *s++);
> >>
> >> I mean, what THE HELL...?
> A nice example of language design inspired by hardware (and vice versa).
> May result in very fast code.
Actually a memcpy() call would probably be faster (at least if you know
the amount of data to copy).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I wouldn't exactly call that straightfoward either. It's not *actually*
>> complicated, but it sure *looks* pretty baffling.
>
> But the haskell code is normal, regular haskell. Your C example is
> not code any sane person would write.
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
some reason, there is a simple, well-known O(1) algorithm for that.
>> Alternatively,
>
>> while(*v++ = *s++);
>
>> I mean, what THE HELL...?
>
> At least it's easy to understand what it does (and why it works) when
> it's explained. The haskell example isn't.
Really? I mean, it's a little perplexing that the computer is actually
able to unravel it without getting stuck, but once you understand what
the machine is doing internally, it's not so hard.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 15:22, Invisible wrote:
>>> I wouldn't exactly call that straightfoward either. It's not
>>> *actually* complicated, but it sure *looks* pretty baffling.
>>
>> But the haskell code is normal, regular haskell. Your C example is
>> not code any sane person would write.
>
> 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
> some reason, there is a simple, well-known O(1) algorithm for that.
>
>>> Alternatively,
>>
>>> while(*v++ = *s++);
>>
>>> I mean, what THE HELL...?
>>
>> At least it's easy to understand what it does (and why it works) when
>> it's explained. The haskell example isn't.
>
> Really? I mean, it's a little perplexing that the computer is actually
> able to unravel it without getting stuck, but once you understand what
> the machine is doing internally, it's not so hard.
>
You mean that you not only understands how it works, but it even helped
you understand how compilers work?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And lo on Fri, 12 Sep 2008 09:16:07 +0100, Invisible <voi### [at] devnull> did
spake, saying:
>>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>>> complex language. I don't see how learning an easy language should
>>> enable me to learn a hard language.
>> Heh, Haskell looks complicated and hard to learn to me.
>
> Well, I guess there are probably people who look at something like
>
> x = (-b +- Sqrt(b^2 - 4ac)/2a
>
> and go "OH MY GOD! That looks SO complicated!" But actually, if you know
> a little algebra, you discover that this contraption is actually quite
> straight forward.
But look at the knowledge you need for that. We'll assume that the basics
are covered = + - x ÷ and that you recognise the x, a, b, and c parts of
the equation. First up we get - how can you start with a - symbol, what am
I subtracting b from? Next is a ±; okay you hopefully recognise that it's
a + and a - combined, but how do I add and subtract at the same time? Then
we get a √ um okay the shape of that gives no clue unless you just know
it. Then ² which we might know as shorthand for b x b as many times as the
number. Then we get an 4ac, is that a new character; you know a-z, aa-az,
etc? You have to know that it's shorthand for 4 x a x c. Then finally you
get a / or just one big line which you need to recognise as a ÷.
Spell out all the assumed shorthand plus symbols there and you can see why
it could legitimately be considered complicated.
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Really? I mean, it's a little perplexing that the computer is actually
>> able to unravel it without getting stuck, but once you understand what
>> the machine is doing internally, it's not so hard.
>>
> You mean that you not only understands how it works, but it even helped
> you understand how compilers work?
Well I mean *notionally*, the way Haskell executes is fairly simple. In
the case of the magic tail-chasing fibs definition, fibs starts out as a
list where some list cells are defined, and some haven't been computed
yet. And the ones that haven't been computed yet refer to the ones that
have. (If it were the other way round, you WOULD have a problem.) As you
ask for list cells, they get computed, one by one, until you get the one
you want.
It's a nice example of how lazy evaluation allows you to program in
unusual ways, but it's probably not terrifically practical unless you
only need a handful of Fibonacci numbers.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Invisible" <voi### [at] devnull> wrote in message
news:48ca500c@news.povray.org...
>>> while(*v++ = *s++);
>>>
>>> I mean, what THE HELL...?
>>>
>>
>> I doubt that's the recommended way of copying an array any longer
>
> I doubt that was *ever* the "recommended" way. And yet I, a person who
> doesn't know C very well, am aware of this example. What does that tell
> you? ;-)
That you're looking for examples of why the language is incomprehensible.
That you had a bad lecturer/textbook at university
That you're reading up on why C++ is bad and what constructs are known to
cause problems.
Taking the example to my prefered language, I'd say that 80% of people who
have worked much with SQL can and will use cursors, yet every expert in SQL
will tell people to never use them
Does that mean that SQL is incomprehensible to the average person and a
language that's easy to break things in?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I doubt that was *ever* the "recommended" way. And yet I, a person who
>> doesn't know C very well, am aware of this example. What does that
>> tell you? ;-)
>
> That you're looking for examples of why the language is incomprehensible.
Doesn't take much looking, does it?
> That you had a bad lecturer/textbook at university.
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'm sure this makes the compiler much easier to implement, and no doubt
it contributes to the efficiency and flexibility of the language, but...
I prefer having some kind of safety features in a programming langauge.
> That you're reading up on why C++ is bad and what constructs are known
> to cause problems.
Actually... no.
> Taking the example to my prefered language, I'd say that 80% of people
> who have worked much with SQL can and will use cursors, yet every expert
> in SQL will tell people to never use them.
> Does that mean that SQL is incomprehensible to the average person and a
> language that's easy to break things in?
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.
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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 15:36, Phil Cook wrote:
> And lo on Fri, 12 Sep 2008 09:16:07 +0100, Invisible <voi### [at] devnull> did
> spake, saying:
>
>>>> Haskell is a small, simple, logical language. C++ is a huge, messy,
>>>> complex language. I don't see how learning an easy language should
>>>> enable me to learn a hard language.
>>> Heh, Haskell looks complicated and hard to learn to me.
>>
>> Well, I guess there are probably people who look at something like
>>
>> x = (-b +- Sqrt(b^2 - 4ac)/2a
>>
>> and go "OH MY GOD! That looks SO complicated!" But actually, if you
>> know a little algebra, you discover that this contraption is actually
>> quite straight forward.
>
> But look at the knowledge you need for that. We'll assume that the
> basics are covered = + - x ÷ and that you recognise the x, a, b, and c
> parts of the equation. First up we get - how can you start with a -
> symbol, what am I subtracting b from? Next is a ±; okay you hopefully
> recognise that it's a + and a - combined, but how do I add and subtract
> at the same time? Then we get a √ um okay the shape of that gives no
> clue unless you just know it. Then ² which we might know as shorthand
> for b x b as many times as the number. Then we get an 4ac, is that a new
> character; you know a-z, aa-az, etc? You have to know that it's
> shorthand for 4 x a x c. Then finally you get a / or just one big line
> which you need to recognise as a ÷.
>
> Spell out all the assumed shorthand plus symbols there and you can see
> why it could legitimately be considered complicated.
>
For me the most interesting thing is the ±, that one is quite rare in
highschool maths. Here, and I assume also elsewhere, it is pronounced as
'plus or minus'. Where the 'or' apparently means that we have to
consider one *and* the other. An obvious question is: 'How can it be
that an equation has more than one answer'? There is also the often
overlooked complication that formula manipulating normally consists of
equivalent transformations. Here we have something that isn't, it is
more of a bifurcation resulting in two separate formulas, neither of
which is equivalent to the original equation. It is not obvious how to
run this process in reverse. I think I learned that one later
separately, without being told the intimate connection to the ± in this
formula (or more precise the boolean thing hidden in there somewhere).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well, I guess there are probably people who look at something like
>>
>> x = (-b +- Sqrt(b^2 - 4ac)/2a
>>
>> and go "OH MY GOD! That looks SO complicated!" But actually, if you
>> know a little algebra, you discover that this contraption is actually
>> quite straight forward.
>
> But look at the knowledge you need for that.
>
> Spell out all the assumed shorthand plus symbols there and you can see
> why it could legitimately be considered complicated.
Presumably *any* language will _look_ cryptic if you don't understand
it. The question is how easy it is or isn't to _learn_. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Presumably *any* language will _look_ cryptic if you don't understand it.
> The question is how easy it is or isn't to _learn_. ;-)
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).
If you want to get more advanced, then learn to handle arrays and what & and
* do (quite easy things to remember, not complex at all), and you're pretty
much set to understand 99.999% of C code out there - including things like
while(*v++ = *s++);
What's the problem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 16:16, scott wrote:
>> Presumably *any* language will _look_ cryptic if you don't understand
>> it. The question is how easy it is or isn't to _learn_. ;-)
>
> 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).
>
> If you want to get more advanced, then learn to handle arrays and what &
> and * do (quite easy things to remember, not complex at all), and you're
> pretty much set to understand 99.999% of C code out there - including
> things like while(*v++ = *s++);
>
> What's the problem?
>
How to translate from the concept in your mind to a working program.
That you can use a word processor and have a plot in mind does not
necessary imply that you can write a good story. Especially if the story
has to be written in a language that doesn't fit your preferences.
Exercise: rewrite your reply in Dutch. Hint: we use for all practical
purposes the same alphabet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 15:37, Invisible wrote:
>>> Really? I mean, it's a little perplexing that the computer is
>>> actually able to unravel it without getting stuck, but once you
>>> understand what the machine is doing internally, it's not so hard.
>>>
>> You mean that you not only understands how it works, but it even
>> helped you understand how compilers work?
>
> Well I mean *notionally*, the way Haskell executes is fairly simple. In
> the case of the magic tail-chasing fibs definition, fibs starts out as a
> list where some list cells are defined, and some haven't been computed
> yet. And the ones that haven't been computed yet refer to the ones that
> have. (If it were the other way round, you WOULD have a problem.) As you
> ask for list cells, they get computed, one by one, until you get the one
> you want.
>
> It's a nice example of how lazy evaluation allows you to program in
> unusual ways, but it's probably not terrifically practical unless you
> only need a handful of Fibonacci numbers.
>
That is not really an answer to the question. OTOH it does show that the
Haskell example can also be used to explain how the Haskell compiler (or
whatever it is) works.
Aside, the Haskell evaluation needs much more to explain that the C code
execution. That is of course because all processors have instruction
sets that are modelled on imperative languages (and vice versa). For
most programmers that seems to imply that imperative languages are more
natural perhaps even more fundamental.
I personally think imperative languages are also perceived as more
natural because of the way maths is taught. Teachers tell you to do this
and then do that. That imposes a sense of direction on the process that
is not actually there. It does however make it easy to understand such
things like x=x+1. To such an extend that I have never seen any student
object to such silliness.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Aside, the Haskell evaluation needs much more to explain that the C code
> execution.
You're probably right about that.
(OTOH, doesn't C have short-circuit Boolean operators?)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.)
> 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).
>
> If you want to get more advanced, then learn to handle arrays and what &
> and * do (quite easy things to remember, not complex at all), and you're
> pretty much set to understand 99.999% of C code out there - including
> things like while(*v++ = *s++);
>
> What's the problem?
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?)
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.
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.
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!
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.
Boolean operators and bitwise operators. Which is which? Which ones are
the short-circuit ones, and which aren't? I can never remember.
Pointers in general usually result in disaster. I constantly get the
syntax wrong for pointer types, pointer dereferencing, and pointer creation.
Apparently you're not supposed to mutate strings encoded in the program
source code. It seems to make Strange Things happen.
What's the difference between #include "" and include <>?
Preprocessor macros. (Need I say more?)
Header files, make files, include files, "extern", the whole shooting
match. Wuh?
At least some of these things appear to be fixed in C++.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How to translate from the concept in your mind to a working program.
I didn't get the impression that is what Andy was complaining about, after
all he says he can program in Java, so converting from concept to C
shouldn't be very different from converting from concept to Java. I assume
he can also program POV SDL, and has dabbled in BASIC etc.
If you'd only ever programmed in Haskell or some other functional language,
then sure I can see how you might have a hard time writing some C even if
you knew all the commands and syntax.
> That you can use a word processor and have a plot in mind does not
> necessary imply that you can write a good story. Especially if the story
> has to be written in a language that doesn't fit your preferences.
> Exercise: rewrite your reply in Dutch. Hint: we use for all practical
> purposes the same alphabet.
Sure, teach me all the words you use and any grammar rules and it shouldn't
be too hard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> How to translate from the concept in your mind to a working program.
>
> I didn't get the impression that is what Andy was complaining about,
> after all he says he can program in Java, so converting from concept to
> C shouldn't be very different from converting from concept to Java.
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.
Ditto for EOF, array index out of bounds, out of memory...
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...)
Memory leaks? What memory leaks? No dangling pointers here either.
Need I go on?
In short, Java is a suck-ass language, but at least it's easier than C.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 16:33, Invisible wrote:
> andrel wrote:
>
>> Aside, the Haskell evaluation needs much more to explain than the C
>> code execution.
>
> You're probably right about that.
that is rather sparse quoting. The context was meant to imply that it
shouldn't (in an ideal world with no memory and fresh teachers very year).
> (OTOH,
?
> doesn't C have short-circuit Boolean operators?)
Not sure if the answer for an negated question should be yes or no.
Anyway C logical operators don't evaluate terms on the right if the
answer is already known. Perfectly sensible in a world without side effects.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 16:35, scott wrote:
>> How to translate from the concept in your mind to a working program.
>
> I didn't get the impression that is what Andy was complaining about,
> after all he says he can program in Java, so converting from concept to
> C shouldn't be very different from converting from concept to Java. I
> assume he can also program POV SDL, and has dabbled in BASIC etc.
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.
> If you'd only ever programmed in Haskell or some other functional
> language, then sure I can see how you might have a hard time writing
> some C even if you knew all the commands and syntax.
>
>> That you can use a word processor and have a plot in mind does not
>> necessary imply that you can write a good story. Especially if the
>> story has to be written in a language that doesn't fit your
>> preferences. Exercise: rewrite your reply in Dutch. Hint: we use for
>> all practical purposes the same alphabet.
>
> Sure, teach me all the words you use and any grammar rules and it
> shouldn't be too hard.
>
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?
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 (though I
really do like the kernverklaringen, we really should introduce that in
the language). Language is much more than syntax and grammar. Which was
the point I wanted to make in the first place.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> 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!
Mind you, I would think _every_ language looks like that until you
understand the rules. ;-)
> 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. 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, while the translation the other
way is moderately reliable.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-Sep-08 17:08, andrel wrote:
>>> That you can use a word processor and have a plot in mind does not
>>> necessary imply that you can write a good story. Especially if the
>>> story has to be written in a language that doesn't fit your
>>> preferences. Exercise: rewrite your reply in Dutch. Hint: we use for
>>> all practical purposes the same alphabet.
>>
>> Sure, teach me all the words you use and any grammar rules and it
>> shouldn't be too hard.
>>
> 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?
>
After correcting the grammar and minor adjustments to restore the
meaning this is the back translation in english:
I do not understand really why you find it this way difficult for C. to
learn. There is only an extremely small number of core declarations
(such as if, while, return etc.) and the syntax of them all is very
similar. How functions must write you to learn, but that is it same for
any language. Letters of mathematical formulas are also very easy and
similar to almost each other language which (+ -/* etc. use). If you
want become more sophisticated, leathers then to treat arrays and which
& and * (to rather easy things remember, not at all complex), and you
are rather able understand 99,999% of the code of C - including things
as while (*v++ = *s++); What is the problem?
Good luck on applying grammar rules to correct 'How functions must write
you to learn, but that is it same for any language.' Not to mention the
first sentence that is (after exchanging understand and really) probably
grammatically correct English, but may not exactly express what you
intended.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
