problem using the STL library

Created Mon, 27 Aug 2012 19:44:35 +0000 by chow@vajri.com

chow@vajri.com

Mon, 27 Aug 2012 19:44:35 +0000

I am using the latest RC4 build (target platform is Uno32) and having problems using the STL.

using try / catch blocks around calls to functions like std::vector.push_back() give compilation errors "error: exception handling disabled, use -fexceptions to enable".

However, omitting the try / catch blocks results in linker errors, "c:/mpide/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/include/c++/4.5.1/bits/vector.tcc:68: undefined reference to `std::__throw_length_error(char const*)'"

Is there a way to use the template library? or do I need to do something like http://andybrown.me.uk/wk/2011/01/15/the-standard-template-library-stl-for-avr-with-c-streams/

jasonk

Tue, 28 Aug 2012 18:20:12 +0000

As you've discovered, C++ exceptions are not yet supported. The same is true for STL. These are both features that we could add in a future release, but not something that is actively being developed as far as I know.

avenue33

Mon, 19 Nov 2012 21:51:01 +0000

Any news about implementing std::vector?

Thanks.

EmbeddedMan

Mon, 19 Nov 2012 23:45:25 +0000

At this point, I do not believe that anyone is working on extending the C++ facilities of the MPIDE compiler.

*Brian

rasmadrak

Tue, 20 Nov 2012 22:52:26 +0000

aveneu33,

A vector is actually a rather simple thing to program, it's basically just a class with pointers to its neighbors.

I'm curious to why you need them thou? You're risking memory fragmentation if you have a lot of de-/allocations going on. There's also the speed issue.

I'd simply create the list in advance and be done with it. :)

avenue33

Wed, 21 Nov 2012 07:39:01 +0000

aveneu33, A vector is actually a rather simple thing to program, it's basically just a class with pointers to its neighbors.

I adapted my own vector library. But the memory management functions don't work for the reason explained by jasonk.

I'm curious to why you need them thou? You're risking memory fragmentation if you have a lot of de-/allocations going on. There's also the speed issue.

I have to deal with an array which size is unknown and may change. See https://github.com/rei-vilo/Serial_LCD

I'd simply create the list in advance and be done with it. :)

I've already implemented that solution. The drawback is the maximum size is hard-coded.

rasmadrak

Thu, 22 Nov 2012 21:02:07 +0000

Correct me if I'm wrong, but the number of digits/pixels in the display is also hardcoded? Or if it's about accessing a custom length textfile etc for displaying, maybe this video by Ben Heck could get you going?

[url]http://www.element14.com/community/docs/DOC-49215/l/episode-49-see-ben-hecks-pocket-computer-episode [/url]

I don't know if these are doing something nasty, but for me they work at least (and I'm only creating them once anyway):

#include <WProgram.h>

/* 
//Increase HEAP size, if wanted:
#define CHANGE_HEAP_SIZE(size) __asm__ volatile ("\t.globl _min_heap_size\n\t.equ _min_heap_size, " #size "\n")

CHANGE_HEAP_SIZE(65536);

extern __attribute__((section("linker_defined"))) char _heap;
extern __attribute__((section("linker_defined"))) char _min_heap_size;
*/

void* operator new(size_t const n)
{
    void*   m = malloc(n);
    return m;
}

void* operator new[] (size_t const n)
{
    void*   m = malloc(n);
    return m;
}

void operator delete(void* const m)
{
    free(m);
}

void operator delete [](void* const m)
{
    free(m);
}