 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> BTW, Fez looks like a game I might actually buy. Cool-looking stuff...
I had not heard of Fez before, but I agree that it does look like it has
some pretty good potential. It looks sort of like like a super-fancy
Cave Story, so hopefully the actual gameplay will be of as high a
quality as well. Thanks for alerting me its existence!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Why reinvent the wheel, when there are lots of such libraries already
> available and widely used in games?
>
Have you used those libraries? Most are undocumented, unfinished,
undesiable or COSTs. What's worst is you don't know what you got until
you try and to use them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> 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.
> If you
> learned C++, or maybe Java if you preferred, you could use that skill to get
> a job you would like (games or not).
I already *know* Java. ;-)
(Although it sounds like they've added a few new language features since
I used it. And I am 100% certain that most of the APIs I know have been
deprecated, undeprecated, and redeprecated at least twice by now. For
some reason, the Java guys like to completely change all the APIs with
each minor release...)
> Why don't you put the time into it?
What makes you think I haven't?
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.
From what I've read, C++ is exactly like C, but 80% more complicated.
Given that I could bearly produce working code in C with the tutor's
help, my chances of getting anywhere with C++ are basically nil.
> I
> had a lot of fun with C++ and OpenGL in college. It's really not that hard
> to learn for someone like you.
As I say, the trouble is that if your program doesn't work, there is no
way you can ever find out why. (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.)
I've actually thought about trying to use OpenGL from Haskell, but I
keep being put off by just how huge and complex the API is...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The big problem with someone who has programmed almost exclusively with
> a language like Haskell for the past years is that he will be very biased
> towards the features and strong points of that language, and will then be
> constantly pulling his hair when trying to code something in C++. "Why do
> I have to do it like this? It's stupid. Why can't I do it like in Haskell?"
Like this:
http://lukeplant.me.uk/blog.php?id=1107301645
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible a écrit :
> Apparently there are people who know
> the Secret Techniques for debugging C programs
You mean putting some strategically placed printf's :-) ?
Seriously. Is that difficult?
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vincent Le Chevalier wrote:
> Invisible a écrit :
>> Apparently there are people who know the Secret Techniques for
>> debugging C programs
>
> You mean putting some strategically placed printf's :-) ?
>
> Seriously. Is that difficult?
printf() is usually the part I'm trying to debug. (As in, it prints
gibberish instead of printing what I was expecting.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible a écrit :
> Vincent Le Chevalier wrote:
>> Invisible a écrit :
>>> Apparently there are people who know the Secret Techniques for
>>> debugging C programs
>>
>> You mean putting some strategically placed printf's :-) ?
>>
>> Seriously. Is that difficult?
>
> printf() is usually the part I'm trying to debug. (As in, it prints
> gibberish instead of printing what I was expecting.)
>
Once you've figured how to put in the right format for the type you want
to print, you know enough to debug. If you consider that this is harder
than learning Haskell...
Hell, in C++ it's even easier as there is not even this problem of
formats anymore...
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> printf() is usually the part I'm trying to debug. (As in, it prints
>> gibberish instead of printing what I was expecting.)
>>
> Once you've figured how to put in the right format for the type you want
> to print, you know enough to debug.
Well you'd think so, and yet even with the correct format strings, it
doesn't always print what it's supposed to.
> If you consider that this is harder than learning Haskell...
I still don't get it: Learning Haskell is *easy*, not hard.
> Hell, in C++ it's even easier as there is not even this problem of
> formats anymore...
So I hear. This presumably doesn't stop a program from segfaulting when
you try to append a string from stdin to a string constant or some such.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible a écrit :
>> If you consider that this is harder than learning Haskell...
>
> I still don't get it: Learning Haskell is *easy*, not hard.
>
For some definition of easy and hard. Which may not be the same for
everyone in this case :-) Ordinarily people choose the easiest way; yet
Haskell does not get that many users.
> This presumably doesn't stop a program from segfaulting when
> you try to append a string from stdin to a string constant or some such.
I figure that if you use the std::string class you're safe from that. I
haven't tried, though.
--
Vincent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> If you consider that this is harder than learning Haskell...
>>
>> I still don't get it: Learning Haskell is *easy*, not hard.
>
> For some definition of easy and hard. Which may not be the same for
> everyone in this case :-) Ordinarily people choose the easiest way; yet
> Haskell does not get that many users.
Learning Haskell is like learning algebra; once you grasp a few basic
principles, the rest follows from there. It isn't instantly obvious that
(for example) the solution to ax^2 + bx + c = 0 is x = 1/2a (-b +/
Sqrt(b^2 - 4ac)), but if you know the basic principles you can at least
verify that it works.
Learning C is like learning the works of Shakespear; you just have to
memorise a huge wedge of stuff. If you come across something you haven't
memorised... sorry.
As for ordinary people... I think you'll find they choose the *most
popular* way, which may or may not actually be any good. ;-) (See
Betamax vs VHS, IE vs Netscape, etc.)
I will say this: Haskell is a great *language*, but the *tools* for it
are sadly lacking, as are the *libraries*. C may be one of the most
horrid languages ever invented, but at least it has an insane collection
of tools and libraries, the like of which few others can match.
>> This presumably doesn't stop a program from segfaulting when you try
>> to append a string from stdin to a string constant or some such.
>
> I figure that if you use the std::string class you're safe from that. I
> haven't tried, though.
Wait... you mean they made it a class?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> From what I've read, C++ is exactly like C, but 80% more complicated.
> Given that I could bearly produce working code in C with the tutor's
> help, my chances of getting anywhere with C++ are basically nil.
In terms of actual coding, in some ways C++ is simpler and more
intuitive than C. Also more readable.
I would say learning C++ is easier than C.
Seriously,
--
Who is General Failure and why is he reading my hard-disk.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> I figure that if you use the std::string class you're safe from that.
>> I haven't tried, though.
>
> Wait... you mean they made it a class?
Well, you *do* know that was the whole point of C++, right?
Trust me - I felt like you for a long time. Until I finally found a
good, recent book. Then I realized I'd been learning it the wrong way
all along.
Most of the books I had read assumed you didn't know too much about
programming, and would emphasize basic skills: Loops, arrays, even
C-style strings (character arrays). They'd make sure you could do the
basics. Stuff like vectors would be introduced way at the end, and stuff
like sets and maps often not at all.
I didn't need a book that taught me the basics of programming. I assume
you don't either. So finally I got a book that taught me how things
should be done in C++. Then I realized C++ code doesn't have to be
*that* ugly.
--
Who is General Failure and why is he reading my hard-disk.
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> From what I've read, C++ is exactly like C, but 80% more complicated.
>> Given that I could bearly produce working code in C with the tutor's
>> help, my chances of getting anywhere with C++ are basically nil.
>
> In terms of actual coding, in some ways C++ is simpler and more
> intuitive than C. Also more readable.
>
> I would say learning C++ is easier than C.
>
> Seriously,
Manual memory management? Pointers vs references? Copy constructors and
assignment constructors? The macro preprocessor? Method overrides that
don't actually override unless you insert special code? Templates?
Untrapped numeric overflows? Unchecked array indicies?
Sure. Sounds really simple to me...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Manual memory management? Pointers vs references? Copy constructors and
> assignment constructors? The macro preprocessor? Method overrides that
> don't actually override unless you insert special code? Templates?
> Untrapped numeric overflows? Unchecked array indicies?
>
> Sure. Sounds really simple to me...
I don't think it's much more worse than the POV SDL, actually. Of
course, I haven't gotten into class programming (yet), so maybe I'm in
the dark about how hard C++ really is. There are really only a few ways
you can mess things up badly.
You could always try Euphoria. There are some OpenGL wrappers for that
language. Easy dynamic arrays make Euphoria more fun than C++, and you
don't even have to compile the code if you don't want to. EU is a very
fast interpretive language, and even supports C++ style operations (ei.
var+=2). I left EU because the SVGA library I was using depended on DOS,
and when I switched to XP... well you get the picture :(
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Manual memory management?
You can mostly forget about that if you avoid the keyword 'new'.
> Pointers vs references?
You can usually avoid using pointers if you avoid the keyword 'new'.
> Copy constructors and assignment constructors?
You usually don't need to care about them if you avoid the keyword 'new'.
> The macro preprocessor?
You usually don't need it in C++.
> Method overrides that don't actually override unless you insert
> special code?
What do you mean?
> Templates?
One of the coolest, most powerful and most useful things around.
> Untrapped numeric overflows?
You want the compiler to automatically insert a conditional after each
single arithmetic operation you perform? Maybe you should use some other
language.
> Unchecked array indicies?
You can use checked array indices if you avoid raw arrays and the 'new'
keyword, by using the at() method of random access containers.
> Sure. Sounds really simple to me...
It's complicated only if you make it so.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> From what I've read, C++ is exactly like C, but 80% more complicated.
Incorrect. C++ support most of the things as C, but is approximately 80%
less complicated to use.
For example, handling dynamic data in C++ is usually laughably easy and
safe, while in C it's a nightmare.
> Given that I could bearly produce working code in C with the tutor's
> help, my chances of getting anywhere with C++ are basically nil.
On the contrary: C++ makes it much easier to write working safe code.
You just need a few rules of thumb:
1) If you ever get the temptation of using the keyword 'new', don't.
(And no, "malloc()" is not good either. See rule 3.)
2) If possible, avoid using pointers.
3) If possible, avoid functions in the C standard library.
4) If you want, use the at() method to access data in random access data
containers.
That's it. With these simple rules you will be writing clean safe code
in no time. These rules should be broken only when you get very fluent
with the language and know what you are doing.
> > I
> > had a lot of fun with C++ and OpenGL in college. It's really not that hard
> > to learn for someone like you.
> As I say, the trouble is that if your program doesn't work, there is no
> way you can ever find out why.
Modern compilers and profilers do a quite good job at catching typical
beginner mistakes in C++ programs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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...
>> Method overrides that don't actually override unless you insert
>> special code?
>
> What do you mean?
Recall that I've never actually programmed in C++. I just read a book
about it to see if it was any good.
Anyway, according to this book, by default all class methods have static
binding. If you want real OO-style dynamic binding, that's an extra
feature that you have to remember to turn on. (Presumably because it
incurs a small performance hit, and C++ is targetted at speed, not
flexibility.)
This also suggests that if somebody else wrote some code and you only
have a binary copy, and they decided to not make some method
overridable... too bad. (But then, frankly, trying to extend classes
that somebody else wrote is usually pretty hard in any OO language.)
>> Templates?
>
> One of the coolest, most powerful and most useful things around.
And also one of the hardest parts to learn, no doubt.
>> Untrapped numeric overflows?
>
> You want the compiler to automatically insert a conditional after each
> single arithmetic operation you perform? Maybe you should use some other
> language.
The "maybe you should use some other language" part pretty much hits the
mark, IMHO.
The long and short of it is that C++ is designed to be used by experts,
and if you're not one, the langauge will make no attempt to prevent you
hurting yourself. Now I don't know about you, but when *I* code things,
I make mistakes. And I appreciate having systems in place to help me
find and fix those mistakes. Clearly this is not C's design goal, and it
appears not to be the goal of C++ either. These languages are designed
to be efficient, not safe.
> It's complicated only if you make it so.
Well, there sure seems to be a lot to learn there, that's all I'm saying...
(It's not even a complete list. Isn't there a special syntax for bit
fields or something? And then there's the fun of destructors. And all
kinds of interesting edge cases where that's "meant" to happen becomes
slightly grey. And...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Given that I could bearly produce working code in C with the tutor's
>> help, my chances of getting anywhere with C++ are basically nil.
>
> On the contrary: C++ makes it much easier to write working safe code.
> You just need a few rules of thumb:
>
> 1) If you ever get the temptation of using the keyword 'new', don't.
> (And no, "malloc()" is not good either. See rule 3.)
>
> 2) If possible, avoid using pointers.
>
> 3) If possible, avoid functions in the C standard library.
>
> 4) If you want, use the at() method to access data in random access data
> containers.
>
> That's it. With these simple rules you will be writing clean safe code
> in no time.
Rule 3 should be easy - assuming C++ provides good replacements. (Seems
like a safe assumption to me.) Rule 1 looks fairly easy.
Rule 2 is the one that puzzles me. At least in C, *anything* larger than
a machine register is a pointer. So "avoid pointers" is pretty much
impossible as soon as you want to touch anything larger than 32 bits. No
strings, no arrays, no structs, nothing. Unless C++ radically changes
the rules in this respect, I'm not sure I see a way round that.
Regarding rule 4... does this mean C++ at least manages to provide some
standard containers *other* than arrays? (And that you can *query the
size* of an array?)
> 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. ;-)
>>> I
>>> had a lot of fun with C++ and OpenGL in college. It's really not that hard
>>> to learn for someone like you.
>
>> As I say, the trouble is that if your program doesn't work, there is no
>> way you can ever find out why.
>
> Modern compilers and profilers do a quite good job at catching typical
> beginner mistakes in C++ programs.
Well, perhaps. I doubt they'll help you fix OpenGL issues though...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Anyway, according to this book, by default all class methods have static
> binding. If you want real OO-style dynamic binding, that's an extra
> feature that you have to remember to turn on. (Presumably because it
> incurs a small performance hit, and C++ is targetted at speed, not
> flexibility.)
The basic design principle in C++ is that you don't have to pay for
what you don't use.
If C++ classes were always dynamically bound (like eg. Java classes are),
then each instance of each class would have a size overhead of one pointer,
and every function call would have a double indirection (making it very hard
for the compiler to perform inlining and other optimizations).
This means that if you had, for example, a pixel class which has nothing
else than 4 bytes inside it (for rgba), its size would actually be 8 bytes
(or 12 in 64-bit systems, which would be even worse), even if you didn't
use dynamic binding for anything, and everything you cared about with your
pixel class is optimal memory usage and speed. Also all the functions of
that pixel class would be double indirections.
C++ supports dynamic binding if you need it, but it's not shoved down
your throat by force.
> This also suggests that if somebody else wrote some code and you only
> have a binary copy, and they decided to not make some method
> overridable... too bad. (But then, frankly, trying to extend classes
> that somebody else wrote is usually pretty hard in any OO language.)
Nowadays object-oriented features such as dynamic binding are falling
out of fashion, and they are less and less popular. In this way C++ actually
got to the winning side by turning it off by default.
> >> Templates?
> >
> > One of the coolest, most powerful and most useful things around.
> And also one of the hardest parts to learn, no doubt.
What's so hard to learn about them? Usually the only difference is
that theres one or more type which are abstracted away, and that's it.
For example, rather than writing:
int foo(int parameter) { ... }
where the type of the parameter and the return value is fixed to int,
you abstract them away like this:
template<typename Data_t>
Data_t foo(Data_t parameter) { ... }
Now you can call that function with ints, longs, doubles, chars...
Sure, when you start developing really complicated template code, you
can get quite obfuscated templates, but that's usually more the exception
than the rule.
The most complicated template sentence I have written in actual code
has been this:
typename Allocator::template rebind<size_t>::other(*this).deallocate(refCount, 1);
It would probably take half a book to explain everything that is involved
there. :P
However, you don't usually have to write code like that when you are
making regular programs.
> >> Untrapped numeric overflows?
> >
> > You want the compiler to automatically insert a conditional after each
> > single arithmetic operation you perform? Maybe you should use some other
> > language.
> The "maybe you should use some other language" part pretty much hits the
> mark, IMHO.
Sometimes you have to use what the industry demands, not what you would
like to use. Besides, it's not that bad.
> The long and short of it is that C++ is designed to be used by experts,
> and if you're not one, the langauge will make no attempt to prevent you
> hurting yourself. Now I don't know about you, but when *I* code things,
> I make mistakes. And I appreciate having systems in place to help me
> find and fix those mistakes.
I don't like that when it's shoved down your throat whether you want
it or not, at the expense of, among other things, memory usage efficiency
and speed.
Yes, debug checks are nice. They are nicer if you can turn them off
for a final release.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Rule 2 is the one that puzzles me. At least in C, *anything* larger than
> a machine register is a pointer. So "avoid pointers" is pretty much
> impossible as soon as you want to touch anything larger than 32 bits. No
> strings, no arrays, no structs, nothing. Unless C++ radically changes
> the rules in this respect, I'm not sure I see a way round that.
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.
> 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.)
> (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.)
> > 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
(Actually, Haskell does something similar - but Haskell is so un-OO that
that's a fairly bad comparison.)
But I guess having to do it manually isn't so hard.
>>>> Templates?
>>> One of the coolest, most powerful and most useful things around.
>
>> And also one of the hardest parts to learn, no doubt.
>
> What's so hard to learn about them?
I don't know - I haven't tried yet. ;-)
> Usually the only difference is
> that theres one or more type which are abstracted away, and that's it.
> For example, rather than writing:
>
> int foo(int parameter) { ... }
>
> where the type of the parameter and the return value is fixed to int,
> you abstract them away like this:
>
> template<typename Data_t>
> Data_t foo(Data_t parameter) { ... }
>
> Now you can call that function with ints, longs, doubles, chars...
So that basically means the same thing as Haskell's
foo :: x -> x
foo = ...
then?
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?
> Sure, when you start developing really complicated template code, you
> can get quite obfuscated templates, but that's usually more the exception
> than the rule.
Well, yeah, that goes for any language feature... ;-)
>> The "maybe you should use some other language" part pretty much hits the
>> mark, IMHO.
>
> Sometimes you have to use what the industry demands, not what you would
> like to use.
Ain't that the truth! ;-)
> Besides, it's not that bad.
Well, I guess not. I could have people forcing me to write Bash
scripts... >_<
> 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. :-(
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] devnull> 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
|
|
| |
| |
|
|
|
|
| |
|
|
