#148614 - Dwedit - Mon Jan 07, 2008 10:25 pm
How do I add c++ code to arm7 without the default C++ libraries eating up all the IWRAM?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148615 - wintermute - Mon Jan 07, 2008 10:28 pm
Don't use the C++ default libraries?
As I stated here just switching to C++ compilation does not automatically add overhead.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#148618 - elwing - Mon Jan 07, 2008 11:00 pm
as long as you are doing the same thing and you remove the useless link C++ won't be worst than C, now it's sure that if you try messing with object and template everywhere that won't be great...
#148619 - Dwedit - Mon Jan 07, 2008 11:04 pm
How do I force the linker to exclude the standard libraries so I can see where the link errors would form?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148622 - Dwedit - Tue Jan 08, 2008 12:26 am
I'm looking at the .map file, and the c++ linker added ~55k of crap.
I see some stuff that looks like it's related to exception handling, and rtti, despite everything being compiled with -fno-rtti -fno-exceptions
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148623 - tepples - Tue Jan 08, 2008 12:28 am
Dwedit wrote: |
How do I force the linker to exclude the standard libraries so I can see where the link errors would form? |
I'll let someone who knows more than I do about GCC internals answer your question:
In An Introduction to GCC, Brian J. Gough wrote: |
Note that programs using C++ object files must always be linked with g++, in order to supply the appropriate C++ libraries. Attempting to link a C++ object file with the C compiler gcc will cause "undefined reference" errors for C++ standard library functions |
You might still have problems with a "__gxx_personality" or something. Pages that I found with Google suggest using gcc with -lsupc++ to link in language features without linking in iostream/STL.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148627 - Dwedit - Tue Jan 08, 2008 12:55 am
Linking with gcc instead of g++, I get "undefined reference to floor".
I think I'll just steal some implementation of "floor" from somewhere...
Edit: Linking with g++, and supc++ works! No more c++ crap. 4k of code added from libraries, instead of 55k.
Edit: Size bounces back up the instant you add any global instances of classes...
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148630 - wintermute - Tue Jan 08, 2008 1:40 am
Dwedit wrote: |
Linking with gcc instead of g++, I get "undefined reference to floor".
I think I'll just steal some implementation of "floor" from somewhere...
|
That's because g++ links the math library ( -lm ) by default & gcc doesn't. Really you should avoid float if at all possible.
Quote: |
Edit: Linking with g++, and supc++ works! No more c++ crap. 4k of code added from libraries, instead of 55k.
|
Any chance of seeing the code - things shouldn't be linked in if you don't reference them.
Quote: |
Edit: Size bounces back up the instant you add any global instances of classes... |
new is also rather heavier than straight malloc.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#148634 - kusma - Tue Jan 08, 2008 2:14 am
Dwedit wrote: |
I see some stuff that looks like it's related to exception handling, and rtti, despite everything being compiled with -fno-rtti -fno-exceptions |
Are you sure the files actually got compiled with those flags? It's easy add things to CFLAGS instead of CXXFLAGS or something stupid when debugging, you know ;)
#148639 - tepples - Tue Jan 08, 2008 3:46 am
Unlike malloc, which returns NULL on failure, new throws an exception. To get malloc style behavior, use new<std::nothrow> (found in #include <new>) instead of plain new. Another question: Are the libraries throwing?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148643 - wintermute - Tue Jan 08, 2008 5:08 am
CXXFLAGS extends CFLAGS in the templates & examples.
The C++ libraries are build with exceptions enabled - that's one of the reasons that new is heavier than malloc ( new(nothrow) is in the same source file so unfortunately that doesn't help much) so you'll see them when you some of the C++ standard library.
One of the things on my long term TODO list is "investigate standard library exception removal" but I'm not sure how feasible that might be.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#148655 - kusma - Tue Jan 08, 2008 10:17 am
wintermute wrote: |
CXXFLAGS extends CFLAGS in the templates & examples.
|
Oh, that's SO wrong, man :)
I don't use the template-stuff myself since, well, the makefile kinda sucks. Wrong use of variables, auto-inclusion of every single source in the source tree, tricky to build anything else than the default goal without changing the makefile etc.
#148657 - nipil - Tue Jan 08, 2008 12:35 pm
kusma wrote: |
auto-inclusion of every single source in the source tree |
Might be a stupid trick, but the default template doesn't include anything in sub-directories. So sub-folders in source, data, include and gfx are not explored when built (at least in the template makefile i have)
kusma wrote: |
Wrong use of variables |
What do you mean with this ?
#148658 - Sunray - Tue Jan 08, 2008 12:56 pm
You can also try -fno-threadsafe-statics
#148662 - kusma - Tue Jan 08, 2008 1:48 pm
nipil wrote: |
Might be a stupid trick, but the default template doesn't include anything in sub-directories. So sub-folders in source, data, include and gfx are not explored when built (at least in the template makefile i have)
|
Thanks, but I prefer writing my own clean makefiles instead of hacking around other people's design-choices. Especially since make ain't that hard to deal with ween you're experienced.
Quote: |
What do you mean with this ? |
preprocessor flags are put in the CFLAGS-variable (and no CPPFLAGS-variable usage in the implicit rules for c/c++ sources), CFLAGS included in CXXFLAGS for one. I'd much rather see the makefiles use the pre-defined COMPILE.c-variable for compiling .c-files, for instance.
Oh, and by the way, by "wrong" I don't mean defect or anything like that - the makefiles does work and are correct, I mean wrong according to established GNU make standards. It makes them harder to modify for people who are not familiar with the devkitPro-way of doing it. I reccomend Managing Projects with GNU Make (available at Google Books if you're poor) for anyone wanting to polish their makefile-skills.
#148695 - Echo49 - Tue Jan 08, 2008 11:37 pm
Out of curiosity, what are the pros and cons in choosing to use C++ rather than C?
#148705 - Abcd1234 - Wed Jan 09, 2008 3:07 am
EDIT: I'm just deleting this whole thing... it's better written elsewhere.
Last edited by Abcd1234 on Wed Jan 09, 2008 3:42 am; edited 1 time in total
#148706 - sajiimori - Wed Jan 09, 2008 3:15 am
There are lots of threads on that question. Let's not make another one.
#148707 - Abcd1234 - Wed Jan 09, 2008 3:41 am
Geez, I see what you mean... I've never bothered to check out the forums other than the NDS-specific ones, and lo and behold, there's a whole forum specifically on C/C++, which is chock full of... colourful... threads on C++. :)
#149129 - Echo49 - Tue Jan 15, 2008 8:03 pm
What about specifically for the DS? Would, for example, the overhead from exception handling or creating a lot of objects be too large for time sensitive code?
#149133 - wintermute - Tue Jan 15, 2008 8:51 pm
If you're talking about the ARM7 then, personally, I just wouldn't use C++ code at all.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#149138 - sajiimori - Tue Jan 15, 2008 10:29 pm
Again, there are already threads about that question. Gigantic ones.