#142597 - sajiimori - Wed Oct 10, 2007 6:31 pm
[Digression split from this topic -- MOD]
I've had practical uses for every C++ feature I know of on the DS. I'd use it on GBA if I programmed for it anymore.
If you think C++ on GBA is weird, consider my last project's RAM layout: 3.75 MB were used by code, models, sound, music, and other assets. That leaves 256 KB for the main heap.
All that other data would have been in ROM on the GBA, so basically we developed a DS game in C++ with no extra RAM beyond what the GBA has.
Edit: And no, we didn't have to work very hard to squeeze the main heap into 256 KB. It was a natural fit; assets were the only challenge.
#142601 - Vich - Wed Oct 10, 2007 7:37 pm
| Miked0801 wrote: |
| In reality, a good portion of C++'s abilities aren't all that useful on DS due to platform limitations |
That's not true.
I have almost only worked with C++ techniques on the DS and made dozens of systems that are related to RTTI, serialization, containers, math, GUI lib, 2D/3D engine, etc.
I can tell you also that they perform very well, the executables are small and that there was already commercial interest by a company.
C++ is very useful if you know how to use it.
_________________
[project website] [personal website]
#142678 - Miked0801 - Thu Oct 11, 2007 6:24 pm
Lol - religious wars! :)
In all honesty, the more I use C++, the more I don't miss using C. I just personally hate being so enslaved to the compiler for obtaining useful code. I've been in the low levels for too long I guess.
BTW, what do you consider to be unpractical features?
#142679 - Vich - Thu Oct 11, 2007 7:06 pm
| Miked0801 wrote: |
| Lol - religious wars! :) |
My comment wasn't to say that C++ is the only way to go, it was to debunk your statement that "a good portion of C++'s abilities aren't all that useful" because it didn't make sense and you didn't show any proof to put force behind your statement.
It's not about preference of a language, it's about making statements that don't make sense.
I first learned C before I programmed C++ and I still use C for fast prototyping, implementing features that are more logical to implement with a C interface and for C++ libraries with C interface to enable C programmers to use it too.
| Quote: |
| In all honesty, the more I use C++, the more I don't miss using C. I just personally hate being so enslaved to the compiler for obtaining useful code. |
Taste can't be argued, but please don't shoot a language because you don't see the use of it.
I wonder what makes you think that C++ binds you so much to the language? Whenever you need to, you can still write C code within your C++ application.
| Quote: |
I've been in the low levels for too long I guess.
BTW, what do you consider to be unpractical features? |
Unpractical features of what?
_________________
[project website] [personal website]
#142684 - tepples - Thu Oct 11, 2007 8:37 pm
It's not C++ that's necessarily inefficient; it's the popular implementation. Both MinGW and devkitARM ship with GNU libstdc++, which is optimized for use as a shared library on a multiuser multitasking operating system, not for use as a static library in an embedded system with 395,264 bytes of RAM. Especially the <iostream> of static libstdc++ as provided with devkitARM is noticeably space-inefficient, leading to a 180 KB Hello_World_mb.gba. If I could figure out how to cross-compile uClibc++, which does away with some library features that are rarely used in an embedded environment, I'd probably use C++ features more freely in my devkitARM-based projects.
As for C#, does the CLR spec provide for small memory systems?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142722 - Vich - Fri Oct 12, 2007 9:01 am
| tepples wrote: |
It's not C++ that's necessarily inefficient; it's the popular implementation. Both MinGW and devkitARM ship with GNU libstdc++, which is optimized for use as a shared library on a multiuser multitasking operating system, not for use as a static library in an embedded system with 395,264 bytes of RAM. Especially the <iostream> of static libstdc++ as provided with devkitARM is noticeably space-inefficient, leading to a 180 KB Hello_World_mb.gba. If I could figure out how to cross-compile uClibc++, which does away with some library features that are rarely used in an embedded environment, I'd probably use C++ features more freely in my devkitARM-based projects.
[...] |
If you don't mind writing GPL'ed software, you're free to use my COW library, which basically implements the most commonly used STL containers and other handy things. Most of the OO stuff is implemented with C calls which gives the advantage of a very small library.
You're right about iostream: almost every time that I cut out some iostream-related include, the file size of the library shrunk amazingly(often douzens of kB's at a time).
The only STL include that is still in there is an std::map, but that'll be fixed.
_________________
[project website] [personal website]
#142725 - keldon - Fri Oct 12, 2007 9:59 am
That's not very free if I can only use it when making GPL'd software now is it ^_^
#142728 - Vich - Fri Oct 12, 2007 11:20 am
| keldon wrote: |
| That's not very free if I can only use it when making GPL'd software now is it ^_^ |
I'm not seeing it's free, I'm saying that he's free to use it under my terms.
But anyway: It's still available at no cost if you contribute to the open source community too by licensing the derivate project under the same license.
_________________
[project website] [personal website]
#142729 - keldon - Fri Oct 12, 2007 12:19 pm
| Vich wrote: |
| keldon wrote: | | That's not very free if I can only use it when making GPL'd software now is it ^_^ |
I'm not seeing it's free, I'm saying that he's free to use it under my terms.
But anyway: It's still available at no cost if you contribute to the open source community too by licensing the derivate project under the same license. |
I know, it's just my take on the "FREE" aspect. LGPL is more 'free' for the developer, but [potentially] less 'free' for the consumer.
You have a good take on GPL software, tutorials are (part of) the way forward!
#142734 - Vich - Fri Oct 12, 2007 1:00 pm
keldon, I replied here, because I don't want to hijack the topic any further :P
http://forum.gbadev.org/viewtopic.php?p=142733#142733
_________________
[project website] [personal website]
#142755 - sajiimori - Fri Oct 12, 2007 6:49 pm
Oh yay, two religious wars in one thread. @_@
Mike, the compiler isn't putting a gun to your head and forcing you to use C++ features. The worst it does is give you an error if you call a function incorrectly -- but you enabled those warnings in your C environment too, didn't you?
If you don't like the engine or culture, that's another story! :)
Tepples, iostream != C++. I don't use iostream on the DS.
#142768 - tepples - Fri Oct 12, 2007 9:19 pm
| sajiimori wrote: |
| Tepples, iostream != C++. |
I knew that. But there are a lot of people who think a program that uses <cstdio> is "half C and half C++" and find this mix undesirable.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#142772 - sajiimori - Fri Oct 12, 2007 10:54 pm
A good mental exercise for those people would be to imagine if iostream was never invented, then ask themselves again whether they'd like to use any C++ features.
#143196 - Miked0801 - Thu Oct 18, 2007 1:18 am
| Quote: |
Mike, the compiler isn't putting a gun to your head and forcing you to use C++ features.
|
Comment about C++ retracted guys. It is possible, in experienced hands, to write C++ that is as small as C. It is also possible to write said code as fast as C. It is also possible to make the compiler handle a lot of the lame overhead that C forces you into. But how many C++ programmers out there can do this kind of coding? I personally can't even guess.
#143197 - sajiimori - Thu Oct 18, 2007 1:41 am
I'd guess most programmers aren't good at writing fast code, in any language. Those who can write fast code in C can also write fast code in C++ by extension, but even they might not be able to make efficient use of features unique to C++.
(Then again, I don't know of any C++ features that were added for optimization purposes -- C was already good at being fast, leaving C++ to focus on extras that aid scalability.)
#143200 - Dwedit - Thu Oct 18, 2007 3:06 am
| sajiimori wrote: |
| (Then again, I don't know of any C++ features that were added for optimization purposes |
The inline keyword?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#143211 - sajiimori - Thu Oct 18, 2007 7:47 am
It was arguably added for scalability purposes as well, since macros were already available but had scoping and safety problems in larger systems.
#143213 - Vich - Thu Oct 18, 2007 9:49 am
| sajiimori wrote: |
I'd guess most programmers aren't good at writing fast code, in any language. Those who can write fast code in C can also write fast code in C++ by extension, but even they might not be able to make efficient use of features unique to C++.
(Then again, I don't know of any C++ features that were added for optimization purposes -- C was already good at being fast, leaving C++ to focus on extras that aid scalability.) |
It's not just about writing fast code, but more about writing good code. Good code is normally not slow. Bad code introduces bottlenecks a lot easier, but you get that in C just as easily as in C++.
C++ gives you the possibility to write object-oriented code. OO gives you structure so that code is a lot easier to maintain and extend(if you write good OO code). For me, the power of C++ is that code becomes easier to re-use, extend and manage.
That said, it's also possible to write OO-styled code in C too, but I don't think many C programmers are doing that.
_________________
[project website] [personal website]
#143233 - Miked0801 - Thu Oct 18, 2007 3:57 pm
Most commercial level C coders do. I've got to look at the crap I wrote 5 years ago and continue to support and extend it. The OO ideas of isolation (Encapsulation) is not hard to do in C with discipline. The thought of having to look at any piece of code I've ever written forces me to not 'hack' for a living.
#143242 - gmiller - Thu Oct 18, 2007 4:54 pm
I agree with Miked0801 ... I use the concepts of OO in C. Depending on the platform I may not be able to do C++ (due to tools, memory, or speed). I have done a lot of assembly so I like C because it gives me most of the control and operations I need without being non portable. I struggle with C++ at times because it does things for me that I might not know or want but in general it is OK. I try to pick the language based on what I am trying to do rather than any personal preference. I use rails, PHP, C, C++, Java and assembly based on project needs and other software I need to interface with.
#143251 - sajiimori - Thu Oct 18, 2007 7:04 pm
Agreed that it's entirely possible (and even common) to write good code in C.
One thing I've run into when I couldn't use C++ features is when "goodness" is at odds with efficiency. For instance, I've often wanted to hide the contents of a struct, but felt conflicted about it because the encapsulation implied efficiency costs in C.
Another example is when I have some repeated code, and I find myself thinking: Dang, I wish I could eliminate this repitition without an efficiency penalty. (See qsort vs STL sort.)
Of course, there are still plenty of times when I have similar conflicts while using C++, and I suspect that will always be the case for programmers. C++ just offers some extra tools to help with the most common cases.
#143271 - keldon - Fri Oct 19, 2007 12:48 am
Well there are C solutions to some problems that have equivalent C++ solutions to a problem. However there are some problems that have verbose C solutions where a more directly expressive C++ solution exists at the cost performance (to code called often).
C++ features are fine in any [supporting] platform depending on the feature, and the actual effect on running performance. RTTI makes use of vtables, which should have an effect on the cache. So the two (or so) lookups have a higher cost than just those additional accesses.