#148302 - zxcvbnm - Fri Jan 04, 2008 2:48 pm
I am new to programming, but I know there are 2 programming languages you can use in a ds. I don't want a rrepeat of the religous wars I've seen in other threads.
What are the advantages and disadvantages to each?
#148312 - Kyoufu Kawa - Fri Jan 04, 2008 3:58 pm
C is relatively simple, but you don't get to use classes, overloading and templates, stuff like that.
C++ gives you those mentioned above, most if not all of regular C, but adds a whole lot of overhead to make the classes and templates and stuff actually -work-.
A lot of professional games, even today, are still made in C. I have proof where Pok?mon is concerned ;)
#148320 - zxcvbnm - Fri Jan 04, 2008 4:17 pm
So c++ is for making high end games that push the limits of the system while c is for games that are less cpu intensive?
#148327 - keldon - Fri Jan 04, 2008 4:34 pm
I wouldn't put it like that! Just think that C++ gives you templates, virtual methods, and multiple inheritance (easily). If you're trying to dig a hole use a spade, not a spoon - i.e. use the right tool for the job. Likewise don't use a spade to eat a bowl of soup ...
#148342 - Miked0801 - Fri Jan 04, 2008 7:07 pm
If you are doing this for professional experience, use C++. Almost no one is hiring 'plain' C programmers anymore :)
#148343 - gmiller - Fri Jan 04, 2008 7:42 pm
C++ is a very good language to use and you can use it with or without classes so it can be VERY C like. There are some minor differences with C++ without classes and C but in general C is a subset of C++.
There are times when the object oriented support in C++ can be an overhead but that can be dependent on the runtime libraries. For small memory machines a trim and minimal runtime library can be very helpful. Of course this can also be the case with C. Finding a good book to use can be helpful and understanding the under lying architecture can be very helpful for embedded machines (like the GBA/DS/GP2X ...).
You can do OO in C but the compiler does not help you do it you have to do it yourself which can lead to lots of problems.
The original C++ compilers generated C and then compiled it, but that is not the case now. If you need lean and mean close to the hardware code then C is valid choice because it does not supply many extras.
I think of C as portable assembly language (not a lean or fast as ASM) because there is very little extra there. C++ on the other hand provides classes and other things (templates, operator overriding, encapsulation, etc..) that can make putting together the code faster and less prone to error. You need to pick the correct tool for the problem you are trying to solve.
BTW: I use C almost exclusively for the things that I code on embedded systems but for other platforms I use C and C++.
#148345 - Kyoufu Kawa - Fri Jan 04, 2008 8:02 pm
| Miked0801 wrote: |
| If you are doing this for professional experience, use C++. Almost no one is hiring 'plain' C programmers anymore :) |
Objection! Your honor, I'd like to call to the stand, a random Nintendo employee. </hahaonlyserious>
#148346 - sajiimori - Fri Jan 04, 2008 8:11 pm
The following statements should not be controversial at all:
Every time you use a C++ feature, be aware of its cost.
You don't have to pay for anything you don't use.
#148359 - Miked0801 - Fri Jan 04, 2008 11:32 pm
But if you aren't using all the whiz-bang feautres of C++ to help out development, are you really coding in C++? :)
#148370 - Lick - Sat Jan 05, 2008 1:54 am
With all the dynamic languages popping out of the ground and some of them becoming really popular and even industry standards, I'd say that a compiled language like C++ can't be seen as "bloated" anymore. Only learning C because it runs on (snail-like) slow systems is stupid.
So I suggest learning C++ and back-porting to C, if necessary.
_________________
http://licklick.wordpress.com
#148373 - sajiimori - Sat Jan 05, 2008 2:06 am
I don't even know what "back porting" from C++ to C means. Hand-writing VTables?? heheh
#148374 - Lick - Sat Jan 05, 2008 2:15 am
Well yes, true, but aren't complete rewrites more fun anyway? :)
_________________
http://licklick.wordpress.com
#148387 - StoneCypher - Sat Jan 05, 2008 5:11 am
So, there's a lot of bad information going around here. Let me endeavor to clear some of it up.
1) There isn't really much of a reason to use C anymore; the standards committee has been debating whether or not to end the language for the last several years.
2) C++ includes quite literally all of C, and with three tiny details which most people won't understand, all C is legal C++.
3) Almost every overhead you hear about with C++ is fictional. C++ actually optimizes significantly better than C, largely due to that the compiler has a whole lot more information in C++ code, so it can do things that wouldn't be safe in C, where certain things remained unknown (by example, the method of typecasting, or the static const volatile register problem.) C++, just like C, was designed with zero-compromise efficiency in mind; it discards features instead of speed (which is why we have compile time templates, but no generics.) When someone hand-waves about arbitrary overhead, it's a red flag that they probably don't know what they're talking about; if they did, they'd be citing specific examples.
4) The size difference between C and C++ isn't nearly as large as most people make it out to be. The problem that most people see is that C++ includes more libraries by default than C does; all they really have to do is turn them off, turn TU paring on, shut off RTTI, shut off exceptions, strip symbols (because name mangled symbols are hueg lol) and quit being such a whiny bitch about it. The C runtime is about 40k, and the CPP runtime is about 80k, in the case of GCC with pretty much everything turned off. That was a modest difference in the GBA era; on the DS it basically doesn't matter, unless you're talking about a wifi binary, and since the homebrew community can't make those, that doesn't count.
5) C++ is SIGNIFICANTLY EASIER FOR NOVICES than C is. Yes, it's a larger language, but not by much; there's only about 15 new keywords, and about two dozen new operators. Classes are just structs with methods and publicity. Inheritance isn't hard if it's explained well. Yes, the libraries are enormous, but novices don't need to learn them. Yes, writing your own templates is hugely difficult. Other than that? You get all the benefits of type safety, polymorphism, and a much more complete set of fundamental libraries. There's really no question about this when you talk to anyone who knows both languages well, and it's worth noting that Kernighan and Ritchie - the two guys who invented C - both say that a new programmer should learn C++ first.
6) None of you (nor I) are writing code at the level that you can compete with the C++ compiler or the GCC STL, so don't even pretend it's about efficiency. Nobody's fooled.
7) That jagoff who says classes invoke a bunch of overhead doesn't know what he's talking about. Unless you're dealing with RTTI, which is off in devkitpro by default, it's quite literally zero extra overhead unless it's a polymorphic call, and you can't actually implement as fast a polymorphic dispatch system in C as fast as the compiler in C++ unless you're willing to compile code on the fly. Since C doesn't do polymorphism, it's pretty clear that Kyofu hasn't the faintest goddamned idea how compilers actually work. Static calls are simple jumps; they're resolved at compile time. Static calls into classes aren't different. They're still static calls. All the class does is provide you a mechanism for organization.
8) There's really no reason you'd need to "back-port" from C++ to C, unless you're trying to target a device so small that it would seem absurd by today's standards (64k is about the danger line for C++, 20 for C.)
9) That's not what a dynamic language is, Will. Stow it.
10) Lick is otherwise generally correct. Clinging to C is generally appropriate for the GBA era if you're making a game at the very edge of the system's capabilities. That said, you can generally get more just by implementing algorithms with an eye for space, and the space saved in C++ by removing unnecessary jumps through better inlining is generally larger than the space consumed by the C++ RTL once you're over a few hundred K. Incidentally, if you actually do care about space, go download one of the free ARM compilers; the ARM C++ runtime is smaller than the GCC C runtime. But you're not going to do that, are you? Because it isn't really about space. You're not strapped for 40 k.
11) MikeD: because C++ is a better C compiler. C++ is a much stricter language than C is. GCC catches way more of your bugs for you in C++ mode than C mode. And frankly, you don't have to use all of the features; just one feature is enough to set a single command line flag and move on with life. If you can't think of even one good reason to set that flag, then you don't know C++ well enough to comment.
12) Sajimori: you raise a good point, and I'm going to rephrase it, because some of the people here won't realize how important what you said actually is. The design of the C++ language allows you to turn off quite literally everything with overhead. If you're not using it, shut it off, and it costs you nothing.
13) Kyoufu, the reason the Nintendo SDK - which you shouldn't have, creep - is in C is so that it can be used by both C and C++ programmers. Most APIs are still C apis, because they want to support legacy dinosaur people. Essentially all internal Nintendo code is C++. This is API design 101. Please stop feigning understanding what's going on, or familiarity with Nintendo code other than the stuff you managed to steal on usenet.
14) GMiller knows his shit and speaks clearly. Keldon too.
15) zxcvbnm: "So c++ is for making high end games that push the limits of the system while c is for games that are less cpu intensive?" No, they're both machine-near languages, appropriate for high performance applications. C++ evolved from C; it's C with a whole bunch of new tools. That doesn't mean it's any less appropriate for simple stuff, though. The reason you should prefer C++ is that it gives you more options, and allows you to express yourself more precisely in less code. It's just fine for small things. For large things, it provides tools that you really need. Can you build big stuff in C? Sure: linux is C. But, that's because Linux is older than C++. Modern unix kernels are almost exclusively C++, with the notable exception of embedded kernels for ridiculously limited machines.
16) A lot of professional games, even today, are still made in C. I have proof where Pok?mon is concerned ;) The current pokemon codebase is older than C++; its being C is a reflection of the tools that were available at the time it was written. Brag about software theft again and you'll be removed from gbadev.org . Several of the people at this board are the people you're stealing from. Shame on you, Kyoufu.
_________________
Quidquid Latine dictum sit, altum Sonatur
[Images not permitted - Click here to view it]
#148393 - tepples - Sat Jan 05, 2008 7:24 am
Thank you for clearing some things up. Your post is now linked from the FAQ.
| StoneCypher wrote: |
| 4) The size difference between C and C++ isn't nearly as large as most people make it out to be. The problem that most people see is that C++ includes more libraries by default than C does; all they really have to do is turn them off |
True, the C++ library is big, especially if you're stuck with GNU libstdc++. But some whiners, especially some who might not have looked at Meyers' recommendation in More Effective C++ to consider alternative libraries, will pull a no true Scotsman fallacy when they see a C++ program that uses <cstdio> instead of <iostream>.
I'm pretty sure a TU is a translation unit. But what is "translation unit paring"? Google doesn't seem to help. Based on a dictionary's definition of "pare" meaning "to trim", I think it has something to do with compiler and linker options that cut out unreferenced functions and data.
| Quote: |
| Incidentally, if you actually do care about space, go download one of the free ARM compilers; the ARM C++ runtime is smaller than the GCC C runtime. |
Are you talking about RealView, or something else?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148394 - StoneCypher - Sat Jan 05, 2008 8:04 am
| Quote: |
| True, the C++ library is big, especially if you're stuck with GNU libstdc++. |
Sorry, that's my fault, I should have been clearer. By big, I meant from the programmer's perspective, in the number of functions and constants one needs to learn, rather than in terms of code size. You're not incorrect, I just wasn't clear about what I meant.
| Quote: |
| Based on a dictionary's definition of "pare" meaning "to trim", I think it has something to do with compiler and linker options that cut out unreferenced functions and data. |
Correct.
| Quote: |
| Are you talking about RealView, or something else? |
I'm not honestly sure. I think RVCT is still for pay, and it was either ADS or SDT that was made free, but it's been years since I checked, so you'd do well to just go look.
_________________
Quidquid Latine dictum sit, altum Sonatur
[Images not permitted - Click here to view it]
#148413 - kusma - Sat Jan 05, 2008 2:58 pm
| StoneCypher wrote: |
C++ includes quite literally all of C, and with three tiny details which most people won't understand, all C is legal C++.
|
I'm just curious, those three are:
- implicit cast from void-pointer
- named members in struct-initializers
- implicit typedefing of structs
...Right?
| Quote: |
| Classes are just structs with methods and publicity. |
structs can have methods in C++. The only real difference is the publicity.
| Quote: |
There's really no reason you'd need to "back-port" from C++ to C, unless you're trying to target a device so small that it would seem absurd by today's standards (64k is about the danger line for C++, 20 for C.)
|
This is not true at all. I work as an embedded software developer targeting a wide range of high to low end devices. All of them are new. You'd be surprised how many of our customers does not support C++ or supports it very very poorly in their real-time OSes. For us, pure C is an absolute requirement.
| Quote: |
| Incidentally, if you actually do care about space, go download one of the free ARM compilers |
I'm pretty sure there are no free compilers in the ARM RealView-suite... I checked the web-site, and I couldn't find any free version...
#148430 - Lick - Sat Jan 05, 2008 4:48 pm
I incorrectly mentioned dynamic languages when I was really referring to interpreted languages.
_________________
http://licklick.wordpress.com
#148435 - StoneCypher - Sat Jan 05, 2008 6:22 pm
| Quote: |
- implicit cast from void-pointer
- named members in struct-initializers
- implicit typedefing of structs
...Right? |
Implicit cast from void pointer is one of them. Named members in struct initializers aren't part of C or C++, though many compilers support them. Implicit typality of structs was added to c99, so you would have been right one standard ago.
The other two are the change in sizeof(char) and the extensions to TU named linking under generic probe which were necessary to make export work. Actually, I forgot a fourth one, which is seriously obscure: the meaning of the keyword auto, which has been out of use for so long that even linux kernel hackers aren't still writing it every three lines, is being changed to allow compile time type inference.
| Quote: |
| Quote: | | Classes are just structs with methods and publicity. |
structs can have methods in C++. The only real difference is the publicity. |
Yeah, I meant the difference between C structs and C++ structs, not the difference between C++ structs and C++ classes. It's my fault: I should have been clearer. When I said publicity, I wasn't referring to default public on structs and private on classes, I was referring to that C++ has the concept of publicity and C doesn't.
My bad. I'll try to be clearer. Thank you for forcing me to explain.
| Quote: |
| You'd be surprised how many of our customers does not support C++ or supports it very very poorly in their real-time OSes. |
I've also done embedded work outside the gaming industry. That's the reason for C++ to C compilers such as GHOC and Comeau. It's just a question of knowing what tools are available to you.
| Quote: |
| I'm pretty sure there are no free compilers in the ARM RealView-suite... I checked the web-site, and I couldn't find any free version... |
Yeah, like I said to Tepples, RVCT isn't free. They make other compilers that target this toolchain. Look for ADS and SDT, as I'm pretty sure one of them is free these days.
_________________
Quidquid Latine dictum sit, altum Sonatur
[Images not permitted - Click here to view it]
#148438 - wintermute - Sat Jan 05, 2008 7:47 pm
| StoneCypher wrote: |
1) There isn't really much of a reason to use C anymore; the standards committee has been debating whether or not to end the language for the last several years.
|
Whether or not the standards committee choose to end the C language is irrelevent. There will be a requirement to maintain C projects for quite some years to come.
| Quote: |
3) Almost every overhead you hear about with C++ is fictional.
|
I'm not entirely sure that overhead is at all relevent really. Back when I first started programming assembly was considered the only way to write games with any degree of complexity and C was one of those new fangled things less skillful programmers used.
| Quote: |
The C runtime is about 40k, and the CPP runtime is about 80k, in the case of GCC with pretty much everything turned off. That was a modest difference in the GBA era; on the DS it basically doesn't matter, unless you're talking about a wifi binary, and since the homebrew community can't make those, that doesn't count.
|
I'm really not sure where you get these figures from - the size of the binary you end up with depends largely on what language features and/or standard functions you use from the runtime libraries. I fail to see how you can assign an abitrary size like this.
As an example, with devkitARM a simple test which mallocs a buffer comes in at ~6k but the same code using new weighs in at ~42k. Not such a big deal on the arm9 using the 4meg RAM but possibly a disaster for the arm7 core where we only have 96k.
If you start using iostreams with gcc you'll find that you're losing around 300k - Probably not something to be overly concerned about while your application still fits in available RAM but could become quite significant later.
| Quote: |
5) C++ is SIGNIFICANTLY EASIER FOR NOVICES than C is.
|
Doesn't automatically make it a better language. PAlib is significantly easier for novices than libnds yet anyone who's looked inside the former has run away screaming in horror.
| Quote: |
6) None of you (nor I) are writing code at the level that you can compete with the C++ compiler or the GCC STL, so don't even pretend it's about efficiency. Nobody's fooled.
|
This all really depends what it is you're actually debating. Using standard libraries is more efficient use of the programmer's time and makes for more portable code. In the microcontroller world where storage is at a premium C is an incredibly useful tool for preventing the programmer making use of memory hungry features and assembly is often used to gain absolute control over what gets used where.
| Quote: |
7) That jagoff who says classes invoke a bunch of overhead doesn't know what he's talking about. Unless you're dealing with RTTI, which is off in devkitpro by default.
|
devkitPro still isn't a toolchain.
RTTI is not off by default in the compiler, just the template projects provided. Both RTTI & C++ exception handling appear to be somewhat heavy in gcc.
| Quote: |
8) There's really no reason you'd need to "back-port" from C++ to C, unless you're trying to target a device so small that it would seem absurd by today's standards (64k is about the danger line for C++, 20 for C.)
|
Again you seem to be quoting arbitrary figures that make no sense. The "overhead" of C & C++ is largely dependent on what features the programmer chooses to use.
| Quote: |
10) Lick is otherwise generally correct. Clinging to C is generally appropriate for the GBA era if you're making a game at the very edge of the system's capabilities.
|
You could make the same argument for assembly - bloat, like beauty, is largely in the eye of the beholder.
| Quote: |
That said, you can generally get more just by implementing algorithms with an eye for space,
|
agreed.
| Quote: |
and the space saved in C++ by removing unnecessary jumps through better inlining is generally larger than the space consumed by the C++ RTL once you're over a few hundred K.
|
The RTLs for C & C++ still aren't monolithic - the space consumed by them depends on what functions the programmer chooses to use.
| Quote: |
Incidentally, if you actually do care about space, go download one of the free ARM compilers; the ARM C++ runtime is smaller than the GCC C runtime. But you're not going to do that, are you? Because it isn't really about space. You're not strapped for 40 k.
|
Firstly there is no free ARM compiler available to the general public, secondly if you choose to go that route you're starting over from scratch, having to produce your own crt0, linkscripts and support libraries for the DS/GBA hardware.
| Quote: |
13) Kyoufu, the reason the Nintendo SDK - which you shouldn't have, creep - is in C is so that it can be used by both C and C++ programmers. Most APIs are still C apis, because they want to support legacy dinosaur people. Essentially all internal Nintendo code is C++. This is API design 101. Please stop feigning understanding what's going on, or familiarity with Nintendo code other than the stuff you managed to steal on usenet.
16) A lot of professional games, even today, are still made in C. I have proof where Pok?mon is concerned ;) The current pokemon codebase is older than C++; its being C is a reflection of the tools that were available at the time it was written. Brag about software theft again and you'll be removed from gbadev.org . Several of the people at this board are the people you're stealing from. Shame on you, Kyoufu. |
This one I read as either being involved in Pok?mon or knowing someone who is.
Ultimately for me, there isn't really a question about whether a novice should learn C or C++. The latter implements a superset of the latter so by learning C++ you're also learning C with the handy side effect of improving your employment prospects. Ideally you should really be familiar with as many languages as possible if you want to pursue a career in programming.
How to become a hacker suggests you learn Python, C/C++, Java, Perl, and LISP. Personally I prefer PHP to perl and I've been known to write bash shell scripts for small tasks.
My personal opinion is that one of the singularly worst things you can do as a programmer is become a language evangelist. The best language to program in is the one which makes you most productive and that will depend a lot on the project you're part of. There's no point spending your time arguing about how C++ would be better for the task if significant work has already been done in C or even vice versa - you'll be a more productive team member if you just dig in and work within the framework that's already there.
libnds and libgba are written in C not for performance reasons or because of resource usage but because users should have the choice and it avoids the issue of having to recompile everything when the gcc version in devkitARM is updated. Similar reasoning probably applies to the nitroSDK.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#148440 - kusma - Sat Jan 05, 2008 8:08 pm
| StoneCypher wrote: |
Named members in struct initializers aren't part of C or C++, though many compilers support them.
|
I thought it was added in C99, but I seem to be wrong. Thanks for the corrections, and for the overview of the dissimilarities. I've got one more though, size of character literals; sizeof('a') is equal to sizeof(char) in C++, but sizeof(int) in C.
| Quote: |
| I've also done embedded work outside the gaming industry. That's the reason for C++ to C compilers such as GHOC and Comeau. It's just a question of knowing what tools are available to you. |
While your solution might do the trick for some projects, it wouldn't work for us. The problem is, our customers are actually changing our code for their implementations, and they get multiple deliveries. Generated code is not something that is easy to work with. Sorry, your point is still invalid IMO. There are still reasons to use plain C, and in "my world" they are not uncommon. That doesn't mean that someone should choose C over C++ "just in case" though. C++ is a far more productive programming language than C, and I'm using it for most of my spare-time projects myself.
| Quote: |
| Yeah, like I said to Tepples, RVCT isn't free. They make other compilers that target this toolchain. Look for ADS and SDT, as I'm pretty sure one of them is free these days. |
I checked, and there's no free downloads of ADS apart from patches, and I'm unable to find anything else than old documentation on SDT. Several google-searches also turn up with nothing that seems to be of any value.
#148441 - tepples - Sat Jan 05, 2008 8:15 pm
| kusma wrote: |
| StoneCypher wrote: | C++ includes quite literally all of C, and with three tiny details which most people won't understand, all C is legal C++.
|
I'm just curious, those three are:
- implicit cast from void-pointer
- named members in struct-initializers
- implicit typedefing of structs
...Right? |
That and the fact that C++98 lacks some new features in C99, such as restrict pointers, <stdint.h>, and C99-style complex numbers, though C++ compilers are likely to provide restrict pointers and <cstdint> as extensions.
| wintermute wrote: |
| If you start using iostreams with gcc you'll find that you're losing around 300k |
With G++, or with GNU libstdc++? Has anybody managed to configure uClibc++ on devkitARM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148444 - StoneCypher - Sat Jan 05, 2008 8:33 pm
| wintermute wrote: |
| StoneCypher wrote: |
1) There isn't really much of a reason to use C anymore; the standards committee has been debating whether or not to end the language for the last several years.
|
Whether or not the standards committee choose to end the C language is irrelevent. There will be a requirement to maintain C projects for quite some years to come. |
Yeah, but whether or not old projects need to be maintained, the original question was about what language a new project should be in. That the language may end is of great importance to the original poster's understanding of the situation: C as a language has been eclipsed. It's going to fill a legacy role for a long time, but then, we wouldn't tell him to use COBOL (which is entirely possible) just because it's legacy, and there's a whole lot more legacy COBOL out there than C.
He's asking what language to start in, and if C's been eclipsed, he should know that, and why, so that he can make appropriate choices, in my opinion. That's why I raised the issue.
| wintermute wrote: |
| StoneCypher wrote: |
3) Almost every overhead you hear about with C++ is fictional.
|
I'm not entirely sure that overhead is at all relevent really. Back when I first started programming assembly was considered the only way to write games with any degree of complexity and C was one of those new fangled things less skillful programmers used. |
I agree actually - overhead isn't particularly relevant. That said, it's one of the things the naysayers like to crow about, and it's trivially easy to dispatch, so why argue with their argument rather than just putting it to bed, right?
But, you're right: that really shouldn't be a concern.
| wintermute wrote: |
| StoneCypher wrote: |
The C runtime is about 40k, and the CPP runtime is about 80k, in the case of GCC with pretty much everything turned off. That was a modest difference in the GBA era; on the DS it basically doesn't matter, unless you're talking about a wifi binary, and since the homebrew community can't make those, that doesn't count.
|
I'm really not sure where you get these figures from - the size of the binary you end up with depends largely on what language features and/or standard functions you use from the runtime libraries. I fail to see how you can assign an abitrary size like this. |
Perhaps you missed the phrase "with pretty much everything turned off." That means that if I know how to turn it off, I did. And, we've gone through the command line argument argument before; you know I'm aware of a lot of such stuff. :)
I probably missed a few things, but I did as best a job I could of turning everything off, and an int main which just loops incrementing then decrementing a single variable, when I did this a while back, was 41k in C and 83k in C++, using the devkitpro of that era. ISTR this being approx late april of last year, though you know me and time.
They're not arbitrary numbers at all. They're "this is how small I was able to get a nothing application." I bet you could do better, but I think I did pretty well.
| wintermute wrote: |
As an example, with devkitARM a simple test which mallocs a buffer comes in at ~6k but the same code using new weighs in at ~42k. Not such a big deal on the arm9 using the 4meg RAM but possibly a disaster for the arm7 core where we only have 96k.
|
Ok, so you're actually seeing a 36k difference, as compared to my 42k. I bet that's a result of you doing better than I did with respect to C++, rather than more poorly than I did with respect to C. Anyway, I bet there's also a bunch of measurement differences - for example, once I had a binary, I put a header on it and so forth, made a legal-except-thumbprint binary.
And hey, maybe you just did *way* better than me. I'd like to know how you got C++ down to 42k, if indeed you generated a legal-except-thumbprint binary. Have you considered documenting the state of your making-it-omg-tiny work?
As far as the Arm7 core, 1) that should be ASM, not C, because it needs to be realtime, and 2) You know that you could assign VRAM to it if you felt like it... ;)
| wintermute wrote: |
| If you start using iostreams with gcc |
... then you shouldn't be involved in an efficiency discussion. :D Yes, I know, GCC's streams implementation is major bloat. I think it might be nice if someone would try STLPort, or one of the efficiency-focussed ones, but I'm much too lazy to do it myself.
| wintermute wrote: |
| StoneCypher wrote: | | 5) C++ is SIGNIFICANTLY EASIER FOR NOVICES than C is. |
Doesn't automatically make it a better language. |
Agreed. But it is one germane facet in choosing a good language to work in, and there are almost no downsides. It's worth mentioning.
| wintermute wrote: |
| PAlib is significantly easier for novices than libnds yet anyone who's looked inside the former has run away screaming in horror. |
Are you suggesting that C++ is broken like PA_lib? You realize I'll strangle you in the night if you offend my god that way again, right? :D
| wintermute wrote: |
| In the microcontroller world where storage is at a premium C is an incredibly useful tool for preventing the programmer making use of memory hungry features and assembly is often used to gain absolute control over what gets used where. |
I already acceded that point. We're not in the microcontroller world. This is an amateur writing a DS application. And, frankly, you and maybe steve are the only people in the community who could say that without me booing them down as posers who would be unable to do what was suggested.
| wintermute wrote: |
| StoneCypher wrote: | | 7) That jagoff who says classes invoke a bunch of overhead doesn't know what he's talking about. Unless you're dealing with RTTI, which is off in devkitpro by default. |
devkitPro still isn't a toolchain. |
You're a toolchain.
| wintermute wrote: |
| RTTI is not off by default in the compiler, just the template projects provided. Both RTTI & C++ exception handling appear to be somewhat heavy in gcc. |
From the perspective of the amateur, that distinction probably doesn't make sense. I said it in the way that I thought he would best understand it.
| wintermute wrote: |
| StoneCypher wrote: |
8) There's really no reason you'd need to "back-port" from C++ to C, unless you're trying to target a device so small that it would seem absurd by today's standards (64k is about the danger line for C++, 20 for C.)
|
Again you seem to be quoting arbitrary figures that make no sense. |
No, I'm not. I gave a very specific case for these: devkitpro for the nintendo ds, with everything I was able to strip stripped. You're being willful in what you want to hear. Cut it out.
| wintermute wrote: |
| The "overhead" of C & C++ is largely dependent on what features the programmer chooses to use. |
Which is why I listed what features I chose to use: nothing I was able to decline.
| wintermute wrote: |
| Quote: |
10) Lick is otherwise generally correct. Clinging to C is generally appropriate for the GBA era if you're making a game at the very edge of the system's capabilities. |
You could make the same argument for assembly |
In fact, I did, later in the post. Read the whole message before you reply to it. You're not telling me anything I didn't already say.
| Quote: |
That said, you can generally get more just by implementing algorithms with an eye for space,
|
agreed.
| wintermute wrote: |
| StoneCypher wrote: |
and the space saved in C++ by removing unnecessary jumps through better inlining is generally larger than the space consumed by the C++ RTL once you're over a few hundred K. |
The RTLs for C & C++ still aren't monolithic - the space consumed by them depends on what functions the programmer chooses to use. |
Pay attention next time you reply. That was defined, and you're repeating yourself. You don't need to pick apart every place you see what you think is a repeated mistake, and when it turns out not to be a mistake at all, it gets really annoying.
| wintermute wrote: |
| StoneCypher wrote: |
Incidentally, if you actually do care about space, go download one of the free ARM compilers; the ARM C++ runtime is smaller than the GCC C runtime. But you're not going to do that, are you? Because it isn't really about space. You're not strapped for 40 k.
|
Firstly there is no free ARM compiler available to the general public, secondly if you choose to go that route you're starting over from scratch, having to produce your own crt0, linkscripts and support libraries for the DS/GBA hardware. |
Actually, RVCT at least can use the DKP stuff almost line for line, IIUC. As far as the free compiler, you're wrong about that - SlashDot had a story about when RVCT got released, the really old one that Jeff Froewihn used to use was made free.
| wintermute wrote: |
| This one I read as either being involved in Pok?mon or knowing someone who is. |
I suppose it's possible. I rather doubt it, though. How many commercial developers do you know that show internal code to non-programmers?
| wintermute wrote: |
| My personal opinion is that one of the singularly worst things you can do as a programmer is become a language evangelist. The best language to program in is the one which makes you most productive and that will depend a lot on the project you're part of. |
Well, you and I are in deep agreement about that; lord knows you've seen me try to get people to pick up erlang, C++, PHP, javascript, actionscript/flex, proper CSS, all sorts of stuff.
| wintermute wrote: |
| Similar reasoning probably applies to the nitroSDK. |
Yes, that's what I meant in #13. Perhaps I could have been clearer.
_________________
Quidquid Latine dictum sit, altum Sonatur
[Images not permitted - Click here to view it]
#148468 - sajiimori - Sun Jan 06, 2008 3:30 am
StoneCypher, your tone is forceful (and perhaps "truthy", if I'm using the term correctly), but your posts contain a lot of mistakes or things that are marginally true at best. Almost every part of your 16-part list contains something false, highly debatable, or inflammatory.
A few things that bothered me most:
Code size can matter even more on DS than GBA because code is in RAM.
C++ is a much larger language than C: the spec is about twice as long, considering only the core language.
Some of us do hand-write code that's competitive with compiled C++ or STL components, for efficiency reasons.
Your comment about "virtually all" of Nintendo's internal code being C++ is bogus.
C++ is much older than Linux: 1983 vs 1991.
Your comment about modern non-embedded Unix kernels almost all being C++ is bogus.
Pokemon is not older than C++.
I do especially agree that hand-waving about overhead tends to be a sign of ignorance.
#148469 - wintermute - Sun Jan 06, 2008 4:14 am
| StoneCypher wrote: |
I probably missed a few things, but I did as best a job I could of turning everything off, and an int main which just loops incrementing then decrementing a single variable, when I did this a while back, was 41k in C and 83k in C++, using the devkitpro of that era. ISTR this being approx late april of last year, though you know me and time.
|
Something that simple should be identical in size regardless of C or C++. Are you sure you were using devkitARM? As far as I'm aware there's never been any overhead in devkitARM for just switching to C++.
| Quote: |
They're not arbitrary numbers at all. They're "this is how small I was able to get a nothing application." I bet you could do better, but I think I did pretty well.
|
I'd need to see some code - I'm having trouble imagining how you got a "do nothing" app to that size. Currently the complete .nds for a simple "int main() { while(1); }" weighs in at 12800 bytes compiled as either C or C++ code. That includes nds header and default arm7 core - the arm9 binary on it's own is 2824 bytes.
| Quote: |
| wintermute wrote: | | PAlib is significantly easier for novices than libnds yet anyone who's looked inside the former has run away screaming in horror. |
Are you suggesting that C++ is broken like PA_lib? You realize I'll strangle you in the night if you offend my god that way again, right? :D
|
Just couldn't resist a dig at something considered easy but best avoided :P
| Quote: |
| wintermute wrote: |
Firstly there is no free ARM compiler available to the general public, secondly if you choose to go that route you're starting over from scratch, having to produce your own crt0, linkscripts and support libraries for the DS/GBA hardware. |
Actually, RVCT at least can use the DKP stuff almost line for line, IIUC. As far as the free compiler, you're wrong about that - SlashDot had a story about when RVCT got released, the really old one that Jeff Froewihn used to use was made free.
|
That was SDT and it was only ever made free to students. I can't find it in the ARM site atm but ADS appears to be missing in there as well. Can't seem to find anythng on Slashdot either but search was never a strong point over there anyway.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#148473 - tepples - Sun Jan 06, 2008 5:18 am
| sajiimori wrote: |
| Code size can matter even more on DS than GBA because code is in RAM. |
On the GBA, code is guaranteed to be in ROM only for the first player. Players 2 through 4 run code from EWRAM (256 KiB) if they don't have a copy of the game; in fact, this is the origin of the name "multiboot". In such an environment, you need to be extra careful not to use libraries or language features that you don't need.
| Quote: |
| C++ is much older than Linux: 1983 vs 1991. |
ISO C is from 1989 and 1990, with a major update in 1999. ISO C++ is from 1998, revised as of 2003.
| Quote: |
| Pokemon is not older than C++. |
Pokemon Red (J) is from 1996, and the first Pokemon game I can think of on a platform designed for C (and not hand-written assembly language) was Pokemon Stadium (J) for N64, from 1998.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148476 - sajiimori - Sun Jan 06, 2008 5:30 am
Yeah tepples, I guess you're right: Nothing was ever written in C++ until 1998. There were no compilers, and no books on it. How could there be for a language that doesn't exist?
And I don't understand how the the so-called "Java" myth got started. Why do people insist on its existence when there is clearly no ISO or ANSI standard for it? I suggest people stop using all the nonexistent software written in it and get on with real, standards-compliant life.
#149388 - tepples - Sat Jan 19, 2008 1:28 pm
| sajiimori wrote: |
| Yeah tepples, I guess you're right: Nothing was ever written in C++ until 1998. |
It depends. Does your definition of "C++" include only the standard <iostream> or also the pre-standard <iostream.h>?
| Quote: |
| And I don't understand how the the so-called "Java" myth got started. Why do people insist on its existence when there is clearly no ISO or ANSI standard for it? |
JLS.
Another related topic: What's a good book for new programmers to jump straight into C++, but which also covers the <c*> parts of the C++ standard library? I already know to avoid anything that lists Herb "void main" Schildt as an author.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149392 - Optihut - Sat Jan 19, 2008 2:33 pm
My answer to C vs C++ is the latter, because C++ can do everything C can, but the reverse is not true.
Of course, if you are a language purist and are against mixing the two, then weighing one against the other is indeed a difficult question. Since I don't have a problem with including C code in C++ programs, though, I have to go with C++.
#149401 - gauauu - Sat Jan 19, 2008 7:02 pm
| tepples wrote: |
It depends. Does your definition of "C++" include only the standard <iostream> or also the pre-standard <iostream.h>? |
That's akin to asking if a child car seat built 10 years ago is still a child car seat, even if it doesn't meet today's standards.
Yes, C++ has changed, and the standardized version of C++ which exists now is different than C++ was before Linux was created. But C++ definitely existed.
#149411 - sajiimori - Sat Jan 19, 2008 9:07 pm
Tepples, do you think Java hasn't changed since its inception? Or do you think C++ didn't have books describing it in the 80's, say... I don't know, The C++ Programming Language by Bjarne Stroustrup?
I know you like to work with absolute definitions of everything, but at some point you have to accept that the human mind doesn't work that way -- not even yours. And it's a good thing, too! Intuitive definitions greatly optimize communication. It's like JPEG compression: lossy, but much more compact.
So, my "definition" of C++ is vauge (like my definition of almost everything else), but it tends to include the language that Bjarne Stroustrup named "C++" in the 80's.
#149415 - tepples - Sat Jan 19, 2008 10:14 pm
OK, I understand now about modern C++ vs. Shakespearean C++.
So if someone with 0 programming experience wants to learn C++, which book is best? Should we start with C++, or should we start with something a bit more type-safe and garbage-collected such as Python, ECMAScript, Java, or C#?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149430 - gmiller - Sun Jan 20, 2008 12:37 am
It "depends" ... if you are an OO programmer then C++ is definitely not your OO dream because it is not a pure OO language. Of course the only pure OO language I ever used was smalltalk ...
I tend to use the language that maps the best to the problem set rather than getting into a religious view of things. When all of the problems start looking like nails all the solution start looking like hammers. Use what solves your problem and what you are comfortable with, there is no all encompassing language solution so admit it and keep an open mind.
I use C, C++, Java, python, Ruby ... and bash for my programming and I am trying to make sure I use the right ones for the problem I am trying to solve. I also try to learn new languages to see how they work and how they can help me (the only language I learned that I hated was Modula 2 ... and Cobol)
#149439 - sajiimori - Sun Jan 20, 2008 1:47 am
If I could go back in time and give myself a single C++ book when I was a beginner, it would be a book that mostly focuses on the C subset at first, then incrementally introduces C++ features, with explanations about why they're helpful.
Thinking In C++ is great for the second part, but it might be a bit fast for people who are new to C.
#152875 - furrykef - Sat Mar 22, 2008 1:53 am
| StoneCypher wrote: |
| Sure: linux is C. But, that's because Linux is older than C++. |
Actually, Linus Torvalds really really hates C++, and there's no doubt he'd still write the Linux kernel in C if he had to start over from scratch. He has the sort of venom for C++ that is usually reserved for languages like COBOL. His issue isn't so much with the language itself -- he, like everyone else, knows you can basically use C++ as a "better C" -- but with the way other people use it. Here's one of his rants on it.
I think if C++ were really so bad as he makes it out to be, nobody would be using it. Still, I can't help but side with him just a little: there really are ways in which C++ is a hideous monster. I can't remember what made me buy the book Exceptional C++, but when I bought it, my eyes were forced wiiiiiiiide open. (Even more so for me than most people, since I was used to pre-standard C++ with <iostream.h> and all that.)
Of course, at least for the DS, you're advocate compiling with exceptions off, which does eliminate problems with exception safety -- at the expense of missing out on the benefits of exceptions, of course. (But then, you could always try something like leaving exceptions on only in debug builds, if you're careful to never need them in a release build.) A lot depends on the project and who's working on it, too.
I do think that, realistically, C++ is the way to go for a homebrew DS project. If you (switching to the generic "you" here, not StoneCypher) have particular reasons for preferring C, there's nothing wrong with that, though you may end up making more work for yourself as a result. If you don't know either language yet and you're trying to decide which to use, I really can't answer that -- except I'd advise you to start with the PC and gradually work your way towards the DS rather than just diving in with it. It's a more sane environment to work with.
BTW, are RTTI and exceptions really that bad on the DS? I imagine you might want them off for a high-performance game, but it shouldn't hurt so much for a Tetris clone or something, should it?
| tepples wrote: |
| So if someone with 0 programming experience wants to learn C++, which book is best? Should we start with C++, or should we start with something a bit more type-safe and garbage-collected such as Python, ECMAScript, Java, or C#? |
I'm an advocate of the "Don't start with C [or C++]" approach. My language of choice -- i.e., the one I use whenever possible -- is Python. It's useful for learning programming, for writing quick scripts, for game development (not on the DS, obviously), and all kinds of stuff. For me, Python is the language that keeps on giving. I'm sure the same can be said for some other languages, like Ruby. (Perl, not so much. Perl's definitely a language for people who already know how to program...)
- Kef
(And by the way, StoneCypher... yo mama so fat, her sizeof don't fit in a size_t. ;))
Last edited by furrykef on Sat Mar 22, 2008 3:00 am; edited 1 time in total
#152877 - antiaverage - Sat Mar 22, 2008 2:21 am
| furrykef wrote: |
| yo mama so fat, her sizeof don't fit in a size_t |
<3
#152880 - furrykef - Sat Mar 22, 2008 3:00 am
That was a reference to a game StoneCypher and I ended up playing on IRC a couple of weeks ago. StoneCypher won. :(
#152884 - tepples - Sat Mar 22, 2008 3:30 am
| furrykef wrote: |
| Still, I can't help but side with [Mr. Torvalds] just a little: there really are ways in which C++ is a hideous monster. I can't remember what made me buy the book Exceptional C++, but when I bought it, my eyes were forced wiiiiiiiide open. (Even more so for me than most people, since I was used to pre-standard C++ with <iostream.h> and all that.) |
I haven't read that one, but I have read parts of Effective C++ and More Effective C++ by Scott Meyers. In the first book, he encourages the use of <iostream> over <cstdio> because <iostream> is easier to extend in a standard way (E2). But in More, he devotes an item to admitting that no library is perfect (M23). Some are comparatively bloated, such as GNU libstdc++. Sometimes your platform's <cstdio> is the right library for the job, especially on resource-constrained platforms like handhelds:
| Scott Meyers wrote: |
| I've never come across an iostream implementation that was as fast as the corresponding stdio implementation. In addition, the size of this trivial program's executable using stdio tends to be smaller (sometimes much smaller) than the corresponding program using iostreams. |
In fact, <iostream> of GNU libstdc++ calls the underlying platform's <cstdio> to do its work, guaranteeing that it is bigger and slower than <cstdio> alone.
Based on my conversations with StoneCypher here, on IRC, and even on Slashdot, he wants you to think about 1. the difference between the overhead of the language and the overhead of a library, and 2. the difference between the overhead of a spec and the overhead of a particular implementation. This adds up to four things to juggle: the overhead of each C++ feature, the overhead of g++'s implementations of those features, the overhead of the C++ standard library, and the overhead of GNU libstdc++. He appears to be a fan of Green Hills compilers.
| furrykef wrote: |
| BTW, are RTTI and exceptions really that bad on the DS? I imagine you might want them off for a high-performance game, but it shouldn't hurt so much for a Tetris clone or something, should it? |
I don't know about exceptions on the DS, but the space overhead of exceptions under g++ would have hurt one of my tetromino games for GBA.
| furrykef wrote: |
| I'm an advocate of the "Don't start with C [or C++]" approach. My language of choice -- i.e., the one I use whenever possible -- is Python. It's useful for learning programming, for writing quick scripts, for game development (not on the DS, obviously), and all kinds of stuff. |
And for data integration within an e-tailer.
| furrykef wrote: |
| (And by the way, StoneCypher... yo mama so fat, her sizeof don't fit in a size_t. ;)) |
Incidentally, neither does my mother's sizeof, but that's because Avogadro's number needs 80 bits, and size_t isn't even close to that big on any common ABI that I'm aware of.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#152889 - furrykef - Sat Mar 22, 2008 6:11 am
I think we got a little confused on the iostream thing. I was referring to the use of "#include <iostream.h>" as opposed to "#include <iostream>". When I first learned C++, the standard was still fairly new. The closest thing to a standard before that was the ARM (Annotated Reference Manual; nothing to do with the ARM CPU of course). So the book I learned C++ from used ARM. The next few books I used either used C or happened to use a subset of C++ that worked both with ARM C++ and ISO C++, so I still had no exposure to standard C++. That didn't come up until I picked up Exceptional C++. (By the way, Exceptional C++ is much more focused on gotchas than Effective C++ is. I don't have More Effective C++, so I can't really comment on it.)
BTW, in case anyone's wondering, the difference between <iostream.h> and <iostream> is basically the same as between, say, <stdio.h> and <cstdio>. That is, no 'std' namespace. I think in some cases <iostream.h> might actually behave differently from <iostream> in other ways, though. I don't really know because I didn't learn terribly much about iostream.h anyways.
- Kef
#153010 - sajiimori - Mon Mar 24, 2008 5:09 am
We've shipped many DS games that use RTTI. Use it in cases where, in absence of language support, you would have hand-rolled your own RTTI.
For very simple type distinctions, I've sometimes used virtuals that return an enumerated type value as an optimization. I'm leaning away from this strategy in newer projects because it's a waste of programmer time. If RTTI is too slow for a particular use case, simulating it is probably not the best solution either.
#153551 - SevenString - Tue Apr 01, 2008 8:02 pm
| furrykef wrote: |
Actually, Linus Torvalds really really hates C++, and there's no doubt he'd still write the Linux kernel in C if he had to start over from scratch. He has the sort of venom for C++ that is usually reserved for languages like COBOL. His issue isn't so much with the language itself -- he, like everyone else, knows you can basically use C++ as a "better C" -- but with the way other people use it. Here's one of his rants on it.
...
|
Yep. I think the C++ language itself is just fine. But the abuses I've seen... *shudder*
I had to lead a programming team in managing about a million lines of C++ code, taken over from an external developer when they couldn't deliver their milestones.
THAT was the project that taught me a healthy respect for the loaded gun that is C++. Until that project, I had made the mistaken assumption that programming a million lines of (sort of) working C++ code meant that you probably weren't a group of retarded monkeys on crack. My mistake. :(
On a philosophical note, I think that learning how to write C code using an OOP approach can be helpful as one learns C++, because (IMHO) the programmer may be less prone to abusing the language if he or she has a deeper understanding of WHY C++ language features are there in the first place.
_________________
"Artificial Intelligence is no match for natural stupidity."
#153781 - sgeos - Sun Apr 06, 2008 6:56 am
| furrykef wrote: |
| He has the sort of venom for C++ that is usually reserved for languages like COBOL. |
That is too funny.
| SevenString wrote: |
| Yep. I think the C++ language itself is just fine. But the abuses I've seen... *shudder* |
This is a people problem, not a technical problem.
| SevenString wrote: |
| I had to lead a programming team in managing about a million lines of C++ code, taken over from an external developer when they couldn't deliver their milestones. |
Although clearly it can be a real problem. =) Any advice on how avoid this problem, or did picking it up actually make sense from your business perspective?
-Brendan
#153787 - SevenString - Sun Apr 06, 2008 8:57 am
| sgeos wrote: |
| SevenString wrote: | | Yep. I think the C++ language itself is just fine. But the abuses I've seen... *shudder* |
This is a people problem, not a technical problem.
|
agreed.
| sgeos wrote: |
| SevenString wrote: | | I had to lead a programming team in managing about a million lines of C++ code, taken over from an external developer when they couldn't deliver their milestones. |
Although clearly it can be a real problem. =) Any advice on how avoid this problem, or did picking it up actually make sense from your business perspective? |
It was definitely a business decision. We had a $10M product to ship, and the external group just wasn't cutting it. Of course, during my evaluation of that group a year earlier, I had predicted (in writing) that they wouldn't make their milestones, and had recommended at the time that we either pull the plug on the project or bring it in-house.
After taking over the code, I really hated being right on that one. LOL
But to your question, there was no REAL way to avoid the problem, upper management decisions being what they are. ;)
_________________
"Artificial Intelligence is no match for natural stupidity."
#153792 - sgeos - Sun Apr 06, 2008 9:51 am
| SevenString wrote: |
| But to your question, there was no REAL way to avoid the problem, upper management decisions being what they are. ;) |
Sure. Business decisions always trump technical decisions.
Back on topic. You can shoot yourself in the foot with both C and C++. Don't do that. Evidently you can also shoot someone else or your company in the foot with either language as well. Don't do that either.
-Brendan
#153806 - sajiimori - Sun Apr 06, 2008 8:02 pm
Socially, one of the biggest problems I've seen with the way people use C++ is that they try to follow an "ideology" and apply "principles". The result is usually code that's twice as long as it needs to be, filled with boilerplate and structural nonsense to wade through.
It's easy to see why this happens. C++ adds features that greatly expand the design space for any given problem. If a coder wants to find the "best" design, they have to sift through a vast sea of options, many of which they wouldn't have considered if they were writing in C.
Faced with this task, many coders look for quick "once-and-for-all" answers: Usually some flavor of OOP, mixed with "best practices" from a book of 101 C++ tips. This narrows the design space to a level they're more comfortable with.
But it's possible to get past the "sea of options" problem, and the paralysis it causes. If you invest a lot of time on fully exploring a few problems early on, it gets much easier to quickly find near-optimal solutions for future problems.
#153811 - gmiller - Sun Apr 06, 2008 9:15 pm
I agree with sajiimori ... I have seen crap code written in many languages and there are many ways to do that. Writing good code in any language requires more than surface understanding. Any time you write a piece of code there are potential trade-offs between the "religion" of your design approach and the practicality of the language you are using. Begin able to make decisions in this space is difficult and easy to take the wrong path but some experience in doing so can help you avoid the obvious wrong paths.
#153816 - silent_code - Sun Apr 06, 2008 10:13 pm
this has been pretty abstract and most beginners (and surely even some of the "more experienced" hobby programmers - i would count myself to the latter) won't know what you are talking about. i myself can imagine what you mean, but i'm certainly *not* sure.
what about sharing some (if possible) small and simple examples?
@sajiimori - ps: i swear i'm going to shut up this time. ;^D
#153819 - sgeos - Sun Apr 06, 2008 10:38 pm
| silent_code wrote: |
| what about sharing some (if possible) small and simple examples? |
The problem is that they are all problem specific. If you need a system that can do A, B and C, then build a system that can do those things. If your system will only ever need to do A, and you spend a bunch of time making a system that can also support B and C because it is a "better architecture", that is time wasted.
Rules of thumb are just that- they apply most of the time. If you insist on following them all the time, you are doing something wrong. Of course, you have to know what you are doing and why the rules of thumb were stated in the first place before you can "break" them appropriately.
I once heard someone criticize Python because it forces indentation on the programmer. His criticism was that, most of the time that is OK because you want properly indented code, but it does not give you the flexibility to indent differently when it is important to do. In effect, it doesn't matter for routine code, but this damages the readability of important chunks of code, precisely where readability is most important, because indentation can not be negotiated in the Python universe.
If your language lets you use dynamite, that is fantastic. Sometimes you need it, but this will be rare. Knowing when not to break out the dynamite is part of your job. The few who will legitimately need to use it everyday will know who they are. (They will also know how to properly deploy the dynamite and clean up the mess when they are done.)
Hopefully someone else has a simple, practical, concrete example.
-Brendan
#153827 - Dwedit - Mon Apr 07, 2008 12:28 am
If you want to know what's wrong with C++, try using VTK.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#153840 - silent_code - Mon Apr 07, 2008 1:47 am
that was a very nice and simple example sgeos. i wish some other people, who know what they are talking about could put something like this together. simple analogies are as useful as code sometimes. i encourage everybody to go on, because this is priceless for the unexperienced mind. :^)
ps: i'm not a big friend of libraries (libnds and opengl/al are as far as i go without hurting myself repeatedly. ;^p ) for the heck of it, i code everything i can by myself, just for the learning and understanding. so, well, such a "virtualization toolkit" sure scares me off by the very name of it! ;^)
![[Images not permitted - Click here to view it]](http://feeds.feedburner.com/StoneHome.gif){kind=link}