 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] nawaz org<<<<<<
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
|
|
| |
| |
|
|
|
|
| |
|
|
