problem using the STL library

chow@vajri.com · **Joined:** Wed Jun 20, 2012 3:42 pm **Posts:** 9

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/th ... c-streams/

jasonk · **Posted:** Tue Aug 28, 2012 7:20 pm

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 · **Joined:** Sat Jul 16, 2011 10:19 am **Posts:** 289

Any news about implementing std::vector?

Thanks.

EmbeddedMan · **Posted:** Tue Nov 20, 2012 12:45 am

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

*Brian

rasmadrak · **Posted:** Tue Nov 20, 2012 11:52 pm

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 · **Joined:** Sat Jul 16, 2011 10:19 am **Posts:** 289

rasmadrak wrote:

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.

rasmadrak wrote:

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

rasmadrak wrote:

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 · **Posted:** Thu Nov 22, 2012 10:02 pm

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):

Code:

#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);
}

problem using the STL library

Who is online