Unable to compile for tinyAVR (ATtiny 0 & 1-Series)

[ankur608]

Tested code on ATtiny3217 and 804,

include in DSTherm.h:16:10: fatal error.

Though compiles for old AVR and RISC.

[SpenceKonde]

I was pulled into this too - Is that line supposed to be #include ?

[ankur608]

No, the code works fine for AVR and RISC arch. Even tried to comment out the declaration, but it is associated with Sensor scratchpad object.

Phew, the only searches by stackoverflow were referenced to Xcode ;)

[pstolarz]

Thanks for the issue. AVR and megaAVR compilers don't contain C++ headers. The 1st compiler (AVR), installed on my setup in /opt/arduino-1.8.13/hardware/tools/avr, allows C++ new header by implementing its functionality in /opt/arduino-1.8.13/hardware/arduino/avr/cores/arduino/new(.h|.cpp) for the following cases:

void * operator new(size_t size);
void * operator new[](size_t size);
void * operator new(size_t size, void * ptr) noexcept;    // in-place new-operator
void operator delete(void * ptr);
void operator delete[](void * ptr);

but megaAVR compiler installed on my setup in ~/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5 doesn't provide in-place new operator by its ~/.arduino15/packages/arduino/hardware/megaavr/1.8.7/cores/arduino/new(.h|.cpp), (new header is missing here!):

void * operator new(size_t size);
void * operator new[](size_t size);
void operator delete(void * ptr);
void operator delete[](void * ptr);

Thanks for pointing this issue. I will fix it soon.

[SpenceKonde]

Hm, are you saying that this is a defect in the cores? If that is supposed to be there and it's not, then, that should be fixed at the core level....

Should I add that to new.h in megaTinyCore and DxCore?

What goes in the cpp file?

[pstolarz]

You may fix (and I believe you should) but some developers may have installed legacy versions of cores and will end up with this type of error. So, fix on my side would also be required to be less error prone.

Look at AVR version of new.cpp. In-place new operator is implemented there as:

void * operator new(size_t size, void * ptr) noexcept {
  (void)size;
  return ptr;
}

Just copy-paste AVR version of new operator functionality... And include <new> header (w/o .h).

[SpenceKonde]

Thanks, I will ,ake tjhat change; it will appear in 1.3.6 of DxCore (coming very soon - was expecting to release it over the past weekend) and 2.3.3 of megaTinyCore (not as soon)

[SpenceKonde]

Mmmm it looks like I also need to put in a file called new with no file extension. the text of which is #include "new.h", based on what the official arduino core did.

What nitwit thought extensionless source code files were a good idea?

[pstolarz]

The issue is fixed by #12 PR. Changes currently on branch inplace_new_fix branch. Let mi know if it solves your issue.

[pstolarz]

@SpenceKonde Nitwit!? ;) It's part of C++ standard introduced already in ancient times (like C++98 or so) while namespaces had been added. E.g.:

#include <string.h>  // Standard C header including strcpy(3), memcpy(3), printf(3) etc.
                     // Usage of such pure C headers is not recommended in orthodox C++ code due to namespace pollution
#include <cstring>   // like <string.h> but in std namespace
#include <string>    // C++ std::string class and siblings

Problem with these extensionless C++ headers is not all embedded toolchains support them (in Arduino for example: AVR/megaAVR dont but ESP & STM do).

So basically all these C++ toolchains which don't support those C++ headers are basically C compilers where C++ support has been added "through the kitchen door" with only limited functionality (like new and delete operators). I believe its related to limited resources of target MCUs the toolchains compile for where fully blown C++ including STL and libstdc++ would kill them instantly.