Recently I've used C to code a project using SDL, and I think that if I were to start a serious, bigger project I'd really appreciate objects, thus I'm going to use C++ (or Objective-C, but I know nothing about it).
What are the most common pitfalls in C++ I should watch out for?
At first I wanted to s/What are the most common pitfalls in C++ I should watch out for?/What are the most common pitfalls in C++ (aside from using C++) I should watch out for?/,
but I decided not to since I wanted to get serious replies.
Seems I was wrong.
>>5
This.
It's wise to spend the time you save from learning sepples bullshit on more practical and less annoying things, like achieving Satori or implementing the game in Haskell¹.
_______________
¹ It is possible, e. g. http://d.hatena.ne.jp/mokehehe/20081005/nario
You should know better than to ask /prog/ for advice, especially on Sepples. /prog/ nearly always hates Sepples unless liking Sepples is considered trolling. Most of them would rather troll wank to the shitholes that are LISP and Haskell.
However, in the footsteps of the greatest troll (FrozenVoid), I will HELP HIM.
The most common pitfall is not using Boost for anything that isn't as trivial as "Hello, World!" There's almost no Sepples project that does not benefit from the use of Boost. If you need to do something, consult Boost first so you can see if they've implemented an effective solution first.
The second most common pitfall is using non-smart pointers. Smart pointers cost nearly nothing and improve your program by countless orders of magnitude. The idea behind a smart pointer is that it is a class wrapper to a pointer which gets destroyed when the pointer goes out of scope. Thus, you do not need to concern yourself over the details of destruction without implementing any sort of garbage collection.
Using SDL is a decent idea, it's a great abstraction library, but personally, I find needing to bind myself to the terms of SDL (which is going to change with the next major release - commercial licenses and whatnot) is a strong negative.
Also, it's a pain in the ass to do any sort of useful functions with SDL. SDL only allows you to load .bmp files without SDL_image, you can't do audio without SDL_mixer, and so on and so forth. You end up with like 5 different libraries (plus whatever you need to use the image formats you use, e.g. jpg/png).
In short: SDL is something of a pitfall, depending on your preferences and needs for your project.
Considering that you're coming from C, there are lots of differences you should be familiar with. The biggest ones are having to relearn void * use, malloc, free, etc. Sepples is a major kludge and a hack on C, so be prepared for some confusion. To take advantage of objects, you should be familiar with inheritance and how those work in Sepples (which is pretty unintuitive in most places).
I suggest you Google some reading material on transitioning between C and Sepples, but using Sepples is the fastest way to become familiar with what does and doesn't work.
Name:
Anonymous2009-05-23 15:46
>>10 The most common pitfall is not using Boost for anything that isn't as trivial as "Hello, World!" There's almost no Sepples project that does not benefit from the use of Boost. If you need to do something, consult Boost first so you can see if they've implemented an effective solution first.
The last game I played that used Boost was Civilization IV. That title, from a gaming perspective, is excellent.
From a performance perspective it is a bloated piece of slow-as-fuck shit.
It also has FIOC as it's scripting engine which aggravated the performance problem.
Name:
Anonymous2009-05-23 15:52
>>1
if you appreciate objects, learn a truly object oriented language, such as ruby.
>>11
You do realize that most of the complexity in Civilization IV isn't in anything that could potentially be handled by Boost, right? Boost doesn't do complicated AI, Boost doesn't do drawing, Boost doesn't do countless game iterations.
>>15
How did you come to that conclusion? The game comes with it's own Boost binary and is obviously linked to it. It's easy to imagine someone in the original dev team getting an idea to use the graph library for the AI. Boost doesn't do AI but it's used to implement it. Ditto for game "iterations".
>>13
Of course it's all baseless conjecture. I can't prove the game's performance sucks because of Boost. I'd love to see the source code and see for myself. :(
Name:
Anonymous2009-05-24 6:07
One common pitfall (especially if you've only used C) is to program in C++ as you would program in C.
Name:
Anonymous2009-05-24 12:19
One common pitfall (especially if you've only used C) is to program in C++.
>>17
Real programmers can write 'C' in any language.
Name:
Anonymous2009-05-24 13:50
My personal advice: keep programming in C.
Object orientation can be somehow used even in C, except for inheritance, thoug you don't need inheritance: that concept is not useful at all IMHO. Just watch at java and weep over that crappy "matrioska" structure...
I come from C as you, and I've tried so hart to learn sepple... you waste a lot of time just because the compiler complains about data types... It's almost like programming in ocaml...
Name:
Anonymous2009-05-24 14:04
in most cases c++ isn't even needed.
'a serious, bigger project' like Linux kernel doesn't need it either.
Name:
Anonymous2009-05-24 14:14
>>22
Don't accept the premise that Sepples adds something desirable over C, even if it isn't needed.
>>23
Sepples does have a lot of undesirable additions, but it does add increased type safety and EXCEPTIONS. Having to check tons of return values is really annoying and Sepples mitigates this.
I wouldn't call those nothing, but your basic point is that Sepples is rarely worth switching from C (probably actually increases your problem count, too) and you are correct.
It's kinda sad that a fan of Sepples can't defend against points like this. I'm hoping Sepplesox makes Sepples more worthwhile.
>>22
I like how this is the only example C programmers can bring up. There isn't a single other ``big'' C project in the world. Everything is better when Sepples is used.
>>26 There isn't a single other ``big'' C project in the world.
What are you talking about? There's C projects of all sizes. The kernel example is a particularly good one because it's a situation where C++'s features are not needed.
C isn't perfect, it has its uses. C++ is less perfect than C. Actually, C++ should be avoided. C is low level, but if you want powerful abstractions, why go to C++ and not lisp, for example?
Being a fallible mortal, I find C++'s use of stack scoped destructors, and consequent support for automated RAII worth all the other hassles like binary incompatibility except via extern "C", if I'm having to write native code (given that most places are faggy and balk at using e.g. Haskell in that niche).
On the rare occasion I have to code kernelish stuff for hardware appliances that is so low level where I don't get a libc++ to link against, so have to do vanilla 'C', it's nearly as painful as going back to 12-key card punches would be.
Name:
Anonymous2009-05-24 18:41
>>28
....please don'tpay any mind to haters.....i love your posts and your youtube..i been fllowing yours for over a year...please keep it up. >>29
Name:
Anonymous2009-05-24 19:56
>>25
you realize that you can do exception-style error handling with setjmp/longjmp
Name:
Anonymous2009-05-24 20:28
>>29
A true fallible mortal would not be able to write correct code in Sepples.
>>31
When was the last time you saw that included in the C99 specification and intermediate C learning materials? Oh wait, you haven't. Exception functionality is provided as a core component of Sepples, setjmp/longjmp is incredibly unintuitive to someone learning C.
I realize you can do it, but like the entirety of Sepples, it's just a hack in C. At least with Sepples, you get a clear construct for doing it.
Name:
Anonymous2009-05-24 22:34
>>31
Ooh, interesting. Never really looked at how those jumps work, I still have much to learn.
It's not exactly that I'm coming from C - I just picked it up recently so that I would actually do something in the language, not just "know" it. I learned a fair bit of other languages too, and I've actually started with C++ (in before HURRRR, I dropped it fairly quickly, just after learning the basics of programming in general).
By using C now, I know it's not necessary at all to have language support for objects, inheritance and things like that - it's just that I kind of prefer when I can call methods on objects doing object.method() instead of something like class_method(object).
Actually, now that I think of it there's a nice way of structuring my code I never thought about, gonna try that tomorrow.
Anyway, thanks for your help guys ：） I'm going to stick to C for now.