Using "StandardCPlusPlus" library with teensy doesn't compile. Works on arduinos

[Ros3]

Using "StandardCPlusPlus" library with teensy doesn't compile. Works on arduinos

Hardware: teensy 3.2
Software: teensyduino 1.28-beta1 on Arduino 1.6.8 on windows 10

I'm looking at ManiacBug's standard C++ Library as a possible way to simplify some of my code, so I'm not reinventing the wheel if it's unneeded (specifically vectors are looking nice).
It hasn't been updated in about 4 years, so I'm not exactly hopeful for getting an official patch, and it works fine on arduinos. So it's really doing its job properly, I'm just asking more of it. (Although I realize the teensy is quite different from arduinos, and the compile flags tend to differ slightly)

ANYWAYS: so just including the library (My code is literally "#include <StandardCplusplus.h>" with an empty setup and loop) causes the compile to fail

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\eh_alloc.cpp:25:0:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:176:36: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

 = ((((((((_Unwind_Exception_Class) 'G' 

                                    ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:177:36: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

   << 8 | (_Unwind_Exception_Class) 'N')

                                    ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:178:35: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

  << 8 | (_Unwind_Exception_Class) 'U')

                                   ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:179:41: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

        << 8 | (_Unwind_Exception_Class) 'C')

                                         ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:180:40: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

       << 8 | (_Unwind_Exception_Class) 'C')

                                        ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:181:39: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

      << 8 | (_Unwind_Exception_Class) '+')

                                       ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:182:38: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

     << 8 | (_Unwind_Exception_Class) '+')

                                      ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/unwind-cxx.h:183:37: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class {aka char [8]}'

    << 8 | (_Unwind_Exception_Class) '\0');

                                     ^

Error compiling for board Teensy 3.2 / 3.1.

Link to the sourcecode where the error occurs
It seems those errors are all coming from exception casts, so assuming I won't be doing exception catching, would just removing exception catching work? An error would always result in me restarting the teensy anyways. Probably terrible practice, but it will ultimately be running in a vacuum, so if it runs fine during my testing, nothing should really change during its actual job

But compiling for any real arduinos seems to work fine (compiling for a mega):

Build options changed, rebuilding all

Sketch uses 674 bytes (0%) of program storage space. Maximum is 253,952 bytes.
Global variables use 15 bytes (0%) of dynamic memory, leaving 8,177 bytes for local variables. Maximum is 8,192 bytes.

Granted, they don't tend to really tell you ANYTHING if it compiles (I've noticed teensy shows warnings. which is kinda annoying, because I have a few libraries that use warnings to tell you their version number), but the point is that it compiles fine.
So my question really is: Is there a straightforward way to fix these errors/is there a better c++ library to use/should I just reinvent the wheel, as it'll be easier? I have written a rather nice linkedlist class before, but arduino doesn't like templates, so it doesn't work, and thus would have to be rewritten exclusively for this. Also even the examples fail to compile with other, very different errors, so I feel like I'll be fighting it 90% of the way

While I'm here: I'm currently using FastLED to drive 350 LEDs. that's easy enough, but at any single frame, 50% or more will be turned off (some static frames only have about 60 (=17%) of the LEDs lit), so is there a library that allows me to use less dynamic memory? It's not really a problem, I just know I won't be able to use an arduino uno in the end because I have to store 1,050 uint8's. Like I said: not really a pressing issue, the total library only takes up 1,793 bytes of dynamic memory (5,952 bytes on a teensy, but I realize the teensy takes up much more space for good reasons). Some of that are some arrays (base frames that have about 25 uint8's each) that'll never be changed, so I'm trying to find an easy way to store them in the program space (you'd think marking them const would handle that, but I'm just being lazy, and I know that)

 

[stevech]

Rare to find exception handling in a modest RAM-size MCU.
Compiler warnings can be disabled but I suggest leaving them on since some can indicate must-fix issues.

I'd beware using New or malloc() or free() in small RAM MCUs. Or overuse of the heap in general, or the String class.

constants/string will go to flash if declared const.

 

[WMXZ]

Compiler warnings can be disabled but I suggest leaving them on since some can indicate must-fix issues.

Well, the OP indicates compiler 'error' not 'warning'

may it not simply be that the way the compiler flags are set, this type of casting is indeed forbidden?

 

[Ros3]

Rare to find exception handling in a modest RAM-size MCU.
Compiler warnings can be disabled but I suggest leaving them on since some can indicate must-fix issues.

I'd beware using New or malloc() or free() in small RAM MCUs. Or overuse of the heap in general, or the String class.

constants/string will go to flash if declared const.

Yup, I use clang in sublimetext2 to point out warnings for me early on (although clang absolutely hates the asm in some classes, and insists my project has a good 30 critical problems at all times), seeing how they're useful to fix now rather than have unpredictable results later

I figured that. Except in certain cases, it's not really useful

I'm aware that "new" may cause some issues, but it's either create a dynamic list, or guestimate the biggest it'll ever be, and pre-allocate that whole chunk permanently, which I have done, but it just eats up a huge chunk of memory. Looking into ways to reduce it, it seemed making it dynamic was my best bet. However, if it truly more terrible than I realize, that may be a better idea

Really? I have these:

    const uint8_t eye_1[24] = {133,179,204,20,21,22,23,24,30,35,36,40,47,50,58,61,69,72,73,74,75,76,77,78};
    const uint8_t eye_2[24] = {195,73,73,20,25,26,27,28,33,34,39,42,49,51,59,60,68,71,72,73,74,75,76,77};
    const uint8_t mouth_1[33] = {0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118};

and it seems to eat up more ram than if I remove them(5,952 bytes vs 5,872 bytes, not a huge difference, but there'll be at least 8x more when I'm done. so about 900 bytes of static arrays). Is it because they're arrays, and thus aren't really a value, just a pointer to where it is storing the values? Would it be worth the extra code to convert them to a flash string that I then interpret at runtime?
(sorry about all the questions. even during my "low overhead" programming in school, we had so much extra ram and CPU cycles that I never really felt pressured to nitpick at my code's "efficiency" except for when I left a memory leak in or something)

Well, the OP indicates compiler 'error' not 'warning'

may it not simply be that the way the compiler flags are set, this type of casting is indeed forbidden?

Indeed. the note about warnings was just a side comment. the library I'm trying to use is causing actual compile errors.

 

[defragster]

    const uint8_t eye_1[24] = {133,179,204,20,21,22,23,24,30,35,36,40,47,50,58,61,69,72,73,74,75,76,77,78};
    const uint8_t eye_2[24] = {195,73,73,20,25,26,27,28,33,34,39,42,49,51,59,60,68,71,72,73,74,75,76,77};
    const uint8_t mouth_1[33] = {0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118};

and it seems to eat up more ram than if I remove them(5,952 bytes vs 5,872 bytes, not a huge difference, but there'll be at least 8x more when I'm done. so about 900 bytes of static arrays). Is it because they're arrays, and thus aren't really a value, just a pointer to where it is storing the values? Would it be worth the extra code to convert them to a flash string that I then interpret at runtime?

As written with CONST on them they do reside in flash, job Done - no extra code on Teensy.

Make one like this and see what changes:

    const uint32_t ear_1[99] = {0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118,
       0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118,
       0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118};

 

[Ros3]

As written with CONST on them they do reside in flash, job Done - no extra code on Teensy.

Make one like this and see what changes:

    const uint32_t ear_1[99] = {0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118,
       0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118,
       0,255,228,29,32,36,40,44,48,52,56,61,63,65,67,69,71,73,75,77,79,81,83,85,87,90,94,98,102,106,110,114,118};

with:
Sketch uses 26,308 bytes (10%) of program storage space. Maximum is 262,144 bytes.
Global variables use 6,268 bytes (9%) of dynamic memory, leaving 59,268 bytes for local variables. Maximum is 65,536 bytes.

without "const":
Sketch uses 26,308 bytes (10%) of program storage space. Maximum is 262,144 bytes.
Global variables use 6,268 bytes (9%) of dynamic memory, leaving 59,268 bytes for local variables. Maximum is 65,536 bytes.

commented out:
Sketch uses 25,588 bytes (9%) of program storage space. Maximum is 262,144 bytes.
Global variables use 5,872 bytes (8%) of dynamic memory, leaving 59,664 bytes for local variables. Maximum is 65,536 bytes.

what I didn't notice previously, the flash and RAM go up. Flash by 720, RAM by 396, although I guess that makes sense, because it must be written into the program to then be loaded into the volatile storage.
Const doesn't change the RAM or flash usage even 1 byte. Could it be because it's inside of an external library?

 

[defragster]

Something I didn't expect. Using this AUDIO clips go to FLASH :

const unsigned int AudioSampleGuitar[36929] = { #### }

That is in a cpp file and this is in an included header file:

extern const unsigned int AudioSampleGuitar[36929]

Sketch uses 255,744 bytes
Global variables use 15,504 bytes

 

[stevech]

Something I didn't expect. Using this AUDIO clips go to FLASH :

const unsigned int AudioSampleGuitar[36929] = { #### }

With the initializer (the constants enclosed with curly braces), you need not hard code the array size, i.e., 36929 in this case. You just use empty brackets like [].

I have a program that has several 46KB images in the compile time code. As big lists of hex numbers where those numbers came from a program that converts a raster image to hex ASCII comma separated as C souce.

 

[defragster]

Indeed "you need not hard code the array size" - but this was pulled from the PJRC example and the data creator did it that way, I included it specifically to make it apparent that there were not 36,929 integers, 32 bits in size stored in 15K of used RAM, but rather than as used it went straight to FLASH.

 

[stevech]

ah, yes.
My comment was more aimed at less experienced people.

Do you know about this:
What does GCC default to for string literals? Like
char text[] = "hello world";
or a better example
printf("%d hello world\n", millis());

Would both default to having the const attribute?
In some C compilers I've used, there's a choice and if it's wrong, it goes to RAM as initialized data.

 

[Ros3]

so, I appreciate the help, but this is all kinda just going over my head. It's been a while since I've done any complex programming. I may be screwing something up, but like for arrays, if I don't define the size before initializing it, it seems to cause issues
CLang tells me:

Error - array bound cannot be deduced from an in-class initializer

while the arduino IDE tells me

error: too many initializers for 'uint8_t [0] {aka unsigned char [0]}'

And then marking arrays as "const" in the header stops me from grabbing their address in the cpp code later.
I don't know if I'm screwing up something or what, but the RAM issue really isn't an issue. I was simply curious. I've already decided that I'll be running this on a mega or teensy (depends on how difficult accessing all of teensy's pins is gonna be, and if I need more than it can provide), and neither of those are really close to running out of RAM. it uses 21% on the mega, and 9% on the teensy, so I'm not really feeling any pressure.

My main concern was with the standardcplusplus library errors, and how I should go about this. Should I try to fix it, or should I find another solution? I was mostly hoping for vectors to store a (hopefully jagged) 2D array of sorts: a list of work to be done along with arguments on how to do it. Would it be better to just outright declare a stack size of 20, and keep that memory sanctioned? Can you even do jagged arrays in C? The only way I can find is to have an array of pointers to dynamically allocated arrays (which from what I read, dynamically allocating memory is the devil on MCUs).
So I would probably have to go back to a 20x8 uint8_t array and just keep that allocated the entire time. Which, actually looking at the memory usage again, isn't that much compared to FastLED's CRGB arrays. it's about 5% of a mega vs the 21% everything else is eating up (i allocate 2 of them so I can fill one while I work on the other because that's how I learned to do it in ASM, and I know I could allocate more flags and do it in one, buuuut I'm kinda lazy and that logic would be a bit more complicated than I'm willing to do right now)

As for aiming for inexperienced people: yes, please. I can do some rather complicated code, but I haven't done it professionally in a while. I'm a little rusty, and at the same time I never officially learned C. I'm just throwing C++ at it and seeing what sticks.

 

[stevech]

You can simply use all C for your work, yes? And either no C++, or use someone's library in C++, but write a C wrapper so your C code can use wrappers to call C++ functions. The wrappers are easy to do. And if you can avoid using C++ in your app, things will be SO much easier. The horrors of C++ for embedded come later, at run time, with memory leaks, depleting the heap, etc.

 

[defragster]

Error like this : 'uint8_t [0] {aka unsigned char [0]}'

Can come from simple errors - I'm not sure if this is represents the real code completely but there is no named variable there:

'uint8_t Variable_FOO[] = { 1, 2, 3 };'

 

[Ros3]

Error like this : 'uint8_t [0] {aka unsigned char [0]}'

Can come from simple errors - I'm not sure if this is represents the real code completely but there is no named variable there:

'uint8_t Variable_FOO[] = { 1, 2, 3 };'

yes, I'm well aware it needs a variable name, that just happens to be the error it spits out. the line is doesn't like it referenced here:

error: too many initializers for 'uint8_t [0] {aka unsigned char [0]}'

     uint8_t eye_left_neutral[] = {133,179,204,20,21,22,23,24,30,35,36,40,47,50,58,61,69,72,73,74,75,76,77,78};

and claims the error is on the closing brace
adding a 24 between the square brackets fixes it.

 

[stevech]

re post #14.. could this be an idiosyncrasy of the Arduino non-standard preprocessor?
ANSI C permits the [] syntax.

 

[defragster]

When you don't include relevant code it makes others guess ...

This compiles fine for me - as it should - it did warn me when I didn't 'use' it.. I'm on IDE 1.6.8. The compiler is prone to miscues - seemingly random, or spawned by something elsewhere.

uint8_t eye_left_neutral[] = {133,179,204,20,21,22,23,24,30,35,36,40,47,50,58,61,69,72,73,74,75,76,77,78};

  eye_left_neutral[3]++;

 

[PaulStoffregen]

What happens if you just comment or delete lines 175 to 183 from unwind-cxx.h?

Nothing in the library or its examples appears to actually use "__gxx_exception_class". Perhaps it's not really needed, just leftover code for something this library never actually does? Maybe you can just delete it and everything else might just magically work?

 

[stevech]

Does the unusual Arduino build process cause the linker to include functions that are explicitly defined via function prototypes, but those functions are not referenced/called in the actual code?

 

[PaulStoffregen]

Does the unusual Arduino build process cause the linker to include functions that are explicitly defined via function prototypes, but those functions are not referenced/called in the actual code?

No, it does not. Unused functions are not placed into the final executable image, unless they're somehow referenced.

 

[Ros3]

What happens if you just comment or delete lines 175 to 183 from unwind-cxx.h?

Nothing in the library or its examples appears to actually use "__gxx_exception_class". Perhaps it's not really needed, just leftover code for something this library never actually does? Maybe you can just delete it and everything else might just magically work?

alright, I did that. It compiles with some complaints about streams if I use -fpermissive. I don't know if it works (give me a minute to dig out a teensy and write a sample program to test it), but it at least seems to fully compile it. I was wondering if it could be that easy, but I wasn't entirely sure how to test it without just throwing myself at it (which I try to avoid while using other people's libraries)

random question: is there a way to tell teensyduino the difference between verify and upload? Even when just using verify it opens the teensy loader and wants to flash it.

Build options changed, rebuilding all
In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/complex:20,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\complex.cpp:19:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/fstream:28,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\fstream.cpp:24:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\ios.cpp:23:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/iostream:27,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\iostream.cpp:22:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\istream.cpp:23:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\ostream.cpp:22:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/sstream:27,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\sstream.cpp:22:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/string_iostream:20,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\string.cpp:25:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

Opening Teensy Loader...


Sketch uses 16,904 bytes (6%) of program storage space. Maximum is 262,144 bytes.
Global variables use 4,648 bytes (7%) of dynamic memory, leaving 60,888 bytes for local variables. Maximum is 65,536 bytes.

Edit: alright, it seems to be working (the program runs at least. at about 50,000 loops per second. Which may just be the low baud rate (9600) I went with)
Actually all the errors went away when I wrote a basic serial output in. huh. weird. Taking them out and they're still gone?
Oh well, I'm not complaining.

I tried to see if it would give me issues with more complex things like iterators or anything, but it works like a champ. Although the loops are now significantly longer because I was just trying to abuse it and see how long it would take to run out of RAM on this thing

here's the code I used to test it, in case you were curious:

#include <StandardCplusplus.h>
#include <vector>

uint32_t Counter = 0;
std::vector<int> vec;
void setup(){
    Serial.begin(250000);

}

void loop(){
  Serial.print(F("UPDATE LOOP #"));
  Serial.println(Counter);
  Serial.println("");
  Serial.print(F("Vector Size:"));
  Serial.println(vec.size());
  vec.push_back(Counter);

   std::vector<int>::iterator v = vec.begin();
   while( v != vec.end()) {
    Serial.print(F("value of v = "));
    Serial.println(*v);
      v++;
   }
  
  Counter++;
}

And for anyone curious, it broke at about "Vector Size:5048" (that's actually the last thing it said, so probably creating the iterator caused it to break)
Second time it broke on loop 5045 while 172 numbers in (failed right before printing 172)

And it just flat-out doesn't like ostream. Tried to use the "serstream" example and:

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream:28:0,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/istream:24,

                 from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/serstream:19,

                 from C:\Users\john\AppData\Local\Temp\buildc6fdc25064c66bb131c4593d49d39552.tmp\sketch\more.cpp:1:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers: In static member function 'static void std::__ostream_printout<traits, char, float>::printout(std::basic_ostream<char, traits>&, float)':

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/ostream_helpers:250:109: warning: there are no arguments to 'dtostrf' that depend on a template parameter, so a declaration of 'dtostrf' must be available [-fpermissive]

    length = strlen(dtostrf(f, static_cast<int>(stream.width()), static_cast<int>(stream.precision()), buffer));

                                                                                                             ^

serstream:11: error: no matching function for call to 'std::basic_oserialstream<char>::basic_oserialstream(usb_serial_class&)'
   ohserialstream cout(Serial);

                             ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\examples\serstream\serstream.ino:11:29: note: candidates are:

In file included from C:\Users\john\Documents\Arduino\libraries\StandardCplusplus\examples\serstream\serstream.ino:2:0:

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/serstream:230:12: note: std::basic_oserialstream<charT, traits, Tserial>::basic_oserialstream(Tserial&) [with charT = char; traits = std::char_traits<char>; Tserial = HardwareSerial]

    : basic_ios<charT, traits>(&sb), basic_ostream<charT,traits>(&sb), sb(serial_,ios_base::out)

            ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/serstream:230:12: note:   no known conversion for argument 1 from 'usb_serial_class' to 'HardwareSerial&'

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/serstream:213:60: note: std::basic_oserialstream<char>::basic_oserialstream(const std::basic_oserialstream<char>&)

   : public basic_ostream<charT,traits>

                                                            ^

C:\Users\john\Documents\Arduino\libraries\StandardCplusplus/serstream:213:60: note:   no known conversion for argument 1 from 'usb_serial_class' to 'const std::basic_oserialstream<char>&'

serstream: In function 'void setup()':
serstream:35: warning: unused variable 'button' 
   int (*button)[3] = new int[n][3];

         ^

no matching function for call to 'std::basic_oserialstream<char>::basic_oserialstream(usb_serial_class&)'

But that's fine. my project won't actually use the serial class at all once it's done
It seems like it's just missing the cross-class conversions. Mind you: still only on teensy. Compiling for arduinos works just fine.

 

[defragster]

random question: is there a way to tell teensyduino the difference between verify and upload? Even when just using verify it opens the teensy loader and wants to flash it.

Verify should only Verify the code and not upload, perhaps the button had been pushed on the teensy?

 

[Ros3]

Verify should only Verify the code and not upload, perhaps the button had been pushed on the teensy?

sorry, I was slightly mistaken. It opens the uploader, but it does not actually attempt to flash it. Just kind of odd that it opens the control program anyways.

 

[PaulStoffregen]

Teensy supports 2 methods to program. You can click verify and then press the button, or you can click upload which tries to do everything without a manual button press.

Arduino never really designed their system for the verify-then-press approach, so this is something of a kludge to fit it into the Arduino IDE. When you verify, it runs the Teensy Loader and notifies it of the newly created HEX file. It also puts Teensy Loader into auto mode, if it wasn't already in that mode. This allows you to just press the button on Teensy at any time, to reflash to the most recently compiled code.

 

[Ros3]

interesting. I guess it's just me knowing the default arduino setup more. Because, despite being a pretty poor IDE, it does make programming MCUs very easy. I tried to do a project with an MCU before arduino was a thing, and it was just a huge pain in the ass. Now arduino walks in, and it's a 1 click process. It's really obvious why suddenly arduino became the default microcontroller manufacturer, and why a lot of peripherals are designed for it's stupid design where the pins aren't the correct spacing. Sometimes I forget that the teensy is a completely separate device that just happens to have a plugin that allows it to interface with the arduino environment.
Ofc, I'll also have to get more familiar with op-amps seeing how the teensy sticks with 3.3v instead of the 5 that many many perifs use (i've only seen one that uses 3.3v, and ofc it came with a pre-set-up op amp system to step a 5v signal down to 3.3v).
But anyways, thanks for your help, Paul. I guess I should've just gone with the method of "remove everything that errors until it doesn't error anymore" (I know there was a website that automatically did that with javascript code you put in. It would often spit back exactly the same code, or basically nothing at all)

Random tidbit I found out while messing with how the compiler actually interprets code. The compiler actually completely ignores code that may be impossible to reach. Although you have to make it rather blatant sometimes. I guess any modern compiler will do this, but I have some debug code sprinkled throughout my code that mostly just does serial outputs. I enclosed them all in an if statement, and just set up a global boolean to control all of them (no function to change it, you just change the code). If I change it to false, it actually uses 6,196 fewer bytes in program storage, indicating it doesn't even include it. Like I said: any modern compiler should do this, and it's even more important for an MCU to cut out as much code as possible, I just thought it was interesting. I mostly have experience making full computer programs where they're typically a MB or 2, so the difference of a few thousand bytes isn't really noticeable. Ofc, you still run across people who are adamant that for(; is much better than while(true), which is true for very basic compilers, but not for modern ones.