#171591 - Azenris - Thu Dec 03, 2009 3:40 am
I been looking at some source code of games and I swear everyone uses C, I feel left out in C++, what's wrong with it! Don't you miss all the C++ features or do you not like the idea of them!
Put it in the off topic section, not exactly super important, just asking :p
_________________
My Homebrew Games
#171593 - Dwedit - Thu Dec 03, 2009 7:07 am
It's basically because people perceive C++ as bloated, and under default build settings, it is.
To un-bloat C++:
Get rid of any IOSTREAM stuff. Other STL libraries are okay, such as Vector.
Use libsupc++ instead of libstdc++
Disable exception handling and Run time type identification. (Virtual methods are a different story, those are okay.)
Find some garbage the compiler sticks in there, such as __EABI_ATEXIT, and make a blank function to override it.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#171595 - elwing - Thu Dec 03, 2009 11:37 am
#171596 - headspin - Thu Dec 03, 2009 1:52 pm
Thanks elwing I was looking for one of those links the other day.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#171597 - gauauu - Thu Dec 03, 2009 3:48 pm
I used C for Anguna mainly because I'd never done a full scale project in C and though it would be fun to try ;-)
#171598 - Azenris - Thu Dec 03, 2009 4:35 pm
I have -fno-rtti -fno-exceptions flags in. got no iostream stuff, dunno what Use libsupc++ instead of libstdc++ is. How do I check __EABI_ATEXIT or whatever that is, check the memory map that is built when compiling?
Anyway thanks for the info :)
I really like classes, inheritance which is probably why I never tried to write C only.
_________________
My Homebrew Games
#171599 - vuurrobin - Thu Dec 03, 2009 10:34 pm
I use c++ in my library and other projects. I would really miss classes and templates when writing c only. not to mention no function overloading or declaring local variable midway functions.
the tips for unbloating c++ really are welcome :).
_________________
my blog:
http://vuurrobin.100webcustomers.com/
#171600 - Dwedit - Fri Dec 04, 2009 12:21 am
__aeabi_atexit is the real name of what I was talking about. It gets thrown into any C++ program that instantiates a global object that needs a destructor. Since GBA or NDS programs don't terminate, you never really need to call the destructor, so you can replace __aeabi_atexit with a blank function. (remember to declare it with C linkage, so it has that exact name with no name mangling)
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#171601 - Miked0801 - Fri Dec 04, 2009 1:27 am
That being a bit too anal on size don't you think? What's that save? 1K at most?
#171602 - sgeos - Fri Dec 04, 2009 7:03 am
I agree with Miked0801. You need to figure programmer time into your cost benefit analysis. (Cost: Resources == Food == Money == Time)
Are you even going to finish your project? If so, will you run out of space in the process? What have you written already? Will you need to rewrite it after you "un-bloat"? Would you rather use the time for an extra feature or bug squashing? Every situation is different. Only you can answer these questions for yourself.
I think that in most cases you can just write your program and it will work. If it does not work, it may be too ambitious for the hardware. If you write portable but "bloated" code, chances are you will be able to adapt it to the next hardware cycle with minimal changes. There are some cases where you do need to squeeze everything you can out of the current hardware. You are probably not that guy. Those positions tend to pay a lot.
You can probably describe the macro level goals for your project in a couple of sentences. Do not futz around with things that do not get you to your goals. Your journey will take you to unexpected places even if you try to get there ASAP.
#171605 - wintermute - Fri Dec 04, 2009 2:32 pm
Showstopper with C++ for me is lack of binary compatibility. If the support libraries distributed by devkitPro were written in C++ then every single one of them would need to be recompiled & rereleased for every toolchain update or nothing would link. You may have seen this problem with some ds libraries that have been written in C++ and released only in binary format.
Other annoyances are void * conversion and errors with orred together enum types if they're not cast.
None of this should be seen as reasons to not use C++ in general, just a couple of things to think about when choosing a language for a particular application.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#171606 - elwing - Fri Dec 04, 2009 2:40 pm
| wintermute wrote: |
| Showstopper with C++ for me is lack of binary compatibility. If the support libraries distributed by devkitPro were written in C++ then every single one of them would need to be recompiled & rereleased for every toolchain update or nothing would link. |
sorry, but why? (not saying it won't, just wanna learn why...)
#171610 - sajiimori - Fri Dec 04, 2009 8:48 pm
Hey wintermute, I'm also curious about the binary compatability issue -- I've never distributed a binary library. Does it help to declare your public interface as extern "C", or do the link errors arise from within the library itself (or something it depends on)?
Agreed about or'ing enums. C++ pretends that enums are a "strong" type, but they are hardly that -- it's a sort of half-assed safety. Oh well, minor syntactic issue.
#171613 - wintermute - Fri Dec 04, 2009 10:13 pm
As far as I know there's still no defined standard for C++ ABI the way there is for C - it's still a work in progress. This means that various C++ compilers all have their own name mangling schemes which prevent interoperability between compilers and even different versions of the same compiler due to updates on the way to a standard.
There is a plan to have a standard ABI which will allow interoperability but I don't know the current status.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#171614 - sajiimori - Sat Dec 05, 2009 2:30 am
Does it work if your entire API is extern "C"?
#171622 - wintermute - Sat Dec 05, 2009 12:08 pm
#171810 - mog123 - Sat Dec 26, 2009 3:50 am
I just plain don't like C++, although I've been doing some projects for classes in C++, In a summing-up project I'm not using it(it's not required) at all. I prefer C, gives more control, is a little less strict, a bit faster. I like the idea of classes, but having global structs (or a struct list) just feels more natural to me.
#171817 - keldon - Sat Dec 26, 2009 4:55 pm
| mog123 wrote: |
| I just plain don't like C++, although I've been doing some projects for classes in C++, In a summing-up project I'm not using it(it's not required) at all. I prefer C, gives more control, is a little less strict, a bit faster. I like the idea of classes, but having global structs (or a struct list) just feels more natural to me. |
Embrace name spaces and scope, it is your friend ... my friend!
#171835 - Miked0801 - Mon Dec 28, 2009 8:45 pm
C++ will pay you dividends if you ever decide to get a commercial job. Not too many C developers wanted anymore. Also, once you learn the ins and outs of C++ (takes a long time), you will be able to develop much faster in C++. Speed of execution is not really an issue.
#171861 - elwing - Wed Dec 30, 2009 10:42 am
| mog123 wrote: |
| I just plain don't like C++, although I've been doing some projects for classes in C++, In a summing-up project I'm not using it(it's not required) at all. I prefer C, gives more control, is a little less strict, a bit faster. I like the idea of classes, but having global structs (or a struct list) just feels more natural to me. |
read a book about OO design... that will surely change your point of view... I'm doing mostly C, but when you want to do something object oriented doing it in plain C is just a major pain... you keep rewriting the same jump table mechanism to mimic a bad polymorphism...
#171865 - wintermute - Wed Dec 30, 2009 1:19 pm
Got any recommendations on a good book?
It's probably because I spent a long time with low level code but I find C++ OO design rather frustrating. Quite often I end up running round in circles with inheritance and not really getting anything done.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#171875 - keldon - Wed Dec 30, 2009 7:25 pm
Hmm; I couldn't recommend a good book, but a bunch I can:
- design patterns by the GoF
- Exceptional C++
- More exceptional C++
- Exceptional STL
- Applied C++: Practical techniques for building better software
#171878 - sajiimori - Wed Dec 30, 2009 11:33 pm
I experimented with "proper" OOP years ago, and reached the same conclusion as you, wintermute -- ultimately, it's a lot of jumping through hoops. I really believe the best approach is to accumulate a large mental toolkit, and solve problems as they come, using any combination of the tools you have. The kinds of problems I'm thinking of are:
I don't know how to get the computer to do what I want: Many programmers regard this as the only "real" problem, but it's actually the easiest one, usually solvable by looking for code snippets on google... unless you are at Google. ;)
It's hard to tell if my code is really correct, or if it just happens to be working right now: Good code obviously has no mistakes. Bad code has no obvious mistakes.
I'm spending a lot of time in the debugger: You know what's better than debugging? Not writing bugs. Closely related to the previous problem.
Making this code cleaner will also make it slower: This is something I ran into a lot in C. Of all the languages I've used, C++ is the best for writing code that's fast and good (though this may change as it gradually gets harder to write fast C++ for newer platforms).
I have a lot of code that isn't solving a unique problem: Whereas OOP generates tons of boilerplate, free-form use of C++ features can shorten your code, especially initialization, cleanup, and minor variations on a theme.
Memory leaks and dangling pointers suck: Ok, abstract over them, and never write one again.
#171879 - sajiimori - Wed Dec 30, 2009 11:44 pm
#172023 - vuurrobin - Sun Jan 10, 2010 1:48 am
one of the biggest problems programmers have when they go from c to c++ (or simular languages) is the whole mentallity/paradigm shift. what they can do good and fast in the old paradigm, will be difficult when doing it in a new paradigm because they simply aren't used to the paradigm. they may end up going back to the old paradigm because of this.
if you don't get the paradigm/idea behind OOP, then it can feel like you are running around in circles. but if you learn what OOP is really about, then you'll see that it becomes alot easier and better, and you may even use the ideas when you aren't writing OOP.
however, OOP isn't better than sliced bread. it doesn't solve all problems and it doesn't prevent someone from writing bad code. if you are a bad programmer, then you will write bad code. depending on the language, the paradigm, the framework and the techniques, the code may be less bad (or the bad code will have less bad results), but the code will be bad.
The single most biggest factor in writing good code is the programmer.
like sajiimori says, a good programmer has a mental toolkit filled with solutions, tools and techniques and knows how to use the right solution for the right problem. with solutions, tools and techniques I think of programming languages, paradigms, algoritms, coding techniques, project techniques like agile development, design- document- and testing tools/techniques, common solutions like design patterns, ect. if the programmer knows and understands different kind of tools, then he/she will be able to choose the right kind of tool for the right problem.
@sajiimori, those problems can be solved with choosing the right technique.
I don't know how to get the computer to do what I want: if the problem is generic enough, then look if the language has something to help or look for libraries. if the problem isn't generic, then search if someone had a simular problem or ask someone with more experience/discuss it with someone with equal experience to see if you can solve it togetter. this useally becomes smaller when having more experience and google will help in most cases.
It's hard to tell if my code is really correct, or if it just happens to be working right now: then use asserts to check if the state of the program is what you expect it to be and/or write testcases (unit testing) to see if your code works in different situations.
I'm spending a lot of time in the debugger: then use an other testing technique, like asserts or unit testing (like above)
Making this code cleaner will also make it slower: then look at what is more important. does the code needs to be fast and is the speed increase significant? will the code be updated alot? can comments properly explain the code and the desision. will the 'unclean' code be contaminated to this part? ect.
I have a lot of code that isn't solving a unique problem: then try to solve the problem without code. if you have the solution, then it will be easier to put the solution into code.
Memory leaks and dangling pointers suck: then use a technique that will automaticly solve that for you, whether that is a smart pointer like auto_ptr or a complete garbage collection system.
the c++ faq lite is also great to read. it contains alot of advanced c++ stuff and even some things discussed here like 'c++ further from the machine than c' or 'the type of an enumeration.'.
_________________
my blog:
http://vuurrobin.100webcustomers.com/
#172025 - sgeos - Sun Jan 10, 2010 7:32 am
| vuurrobin wrote: |
| The single most biggest factor in writing good code is the programmer. |
I forget the figures right now, but a good programmer is many times more productive than a normal programmer. I suspect a bad programmer can actually hurt productivity if they introduce bugs quickly enough.
#172030 - ninjalj - Sun Jan 10, 2010 1:18 pm
| sgeos wrote: |
| I forget the figures right now, but a good programmer is many times more productive than a normal programmer. |
I think "The Mythical Man Month" says "an order of magnitude". There was an article from Paul Graham where he says this has increased with time.
| sgeos wrote: |
| I suspect a bad programmer can actually hurt productivity if they introduce bugs quickly enough. |
I suspect this is like the saying "A squad can only move as fast as its slowest unit". I don't know the origin of this saying, I read it on an old game called "The Ancient Art of War".
#172056 - sajiimori - Tue Jan 12, 2010 1:30 am
vuurrobin, that was basically my point: I was identifying core problems that I've attacked head-on with liberal and free-form use of C++ features.
I was also highlighting the difference between a real problem (e.g. "I spend too much time in the debugger") versus a theoretical problem (e.g. "this code isn't properly encapsulated").
#172072 - keldon - Tue Jan 12, 2010 11:06 pm
http://66.102.9.132/search?q=cache:http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
Interesting article by Charles Petzold, especially the closing paragraphs where he starts talking about "dealing with real problems".
The problem is that there are many schools of thought in programming; I myself suffer in some areas and am strong in others. But studying various design patterns and learning where they can be used best will help a lot. Once you know how to operate classes it's just a matter of building up your arsenal of structures that best communicate what you are doing.
It's just like writing; once you've got past the basic mechanics of the English language you can then move on to the deeper use of rhetorical methods and NLP.
#172081 - Exophase - Wed Jan 13, 2010 8:27 pm
| Miked0801 wrote: |
| C++ will pay you dividends if you ever decide to get a commercial job. Not too many C developers wanted anymore. Also, once you learn the ins and outs of C++ (takes a long time), you will be able to develop much faster in C++. Speed of execution is not really an issue. |
This isn't true in all disciplines. In embedded C is used drastically more than C++ (or anything else), and as time goes on this has been becoming more true instead of less. Embedded can't be sneezed at either, there are billions of embedded CPUs in the wild and most of them are running C code. The thing is, a lot of them are being programmed by electrical/computer engineers instead of software engineers/computer scientists. Still, having a programming degree doesn't prevent you from getting an embedded job. On the other end of the spectrum, I think Java and C# will help you more than C++. C++ is really being kind of outmoded in a lot of market sectors.
I think that the comment of being able to develop faster in C++ is much too generalized. It depends what you're doing, how large your team is, your own personal education and experience, and your particular preferences and comfort levels.
#172091 - elwing - Thu Jan 14, 2010 7:21 am
sorry, but I think we are mixing two distinct things... C and C++ is a thing, but lots of people there think of "bloated with lot of useless libraries" when thinking of C++ which is quite different... you can have some C++ code just as clean as standard C with the addition of templates and all theses little great additions...
#172093 - kusma - Thu Jan 14, 2010 10:10 am
| elwing wrote: |
| you can have some C++ code just as clean as standard C with the addition of templates and all theses little great additions... |
...yeah, but a lot of embedded systems doesn't HAVE a C++ compiler, so you'll get nowhere with your templates there.