@ashthespy Generally I believe most routines should not allocate and return, the caller needs to remember to free the buffer and its not obvious. I subscribe to the model of passing a buffer into the function that it will fill, so...

it depends on the scope of buff. If it's global, you don't need to pass it, it would be accessible by any scope. If you allocate in a function, you'd need to pass it since it's scope is limited to that callstack.

If you're using that string many times in your app, you can always allocate a permanent "sensorString" char array in your sensor class which can be updated and returned to anyone calling "printsensors"

AND, BTW, you now are taking up memory the total time of your app running of STR_SIZE. If you used a scoped variable and pass it, it only takes the memory within the scope as the variable is on the stack. Generally I avoid globals if I can.

Hi,asked some time before if there is any experience with the watchdog function.My NodeMCU with actual sketch is sometimes "freezing". Means I can not access it any more over WiFi.I have a "watchdog ping"-function (thx to everslick) that should cause a reboot if the ESP looses connection to wifi. But I think, that the ESP doesn't process normal code any more.I tried to simulate the internal watchdog with an endless loop for (int i = 0; i < 100000000; i++) { __asm__ volatile ("nop"); }. In that case the ESP is rebooting properly.How can I do more debug, to find out what is causing the ESP to stuck?Any hint is appreciated.

@brutzler Are you familiar with "Divide and Conquer" debugging? Find half the functionality you can easily disable in your sketch; see if the problem reproduces. If not, disable the other part and enable the part that could cause the issue. Continue until you find the problem.

@ashthespy Local variables allocate on the stack not the heap, which is quick. When the variable goes out of scope (return from a function call) then the stack is popped and the memory just goes away. Stack = cheap memory allocation and limited life. For large allocations you should be concerned (over 128 bytes or so) but otherwise your stack is already taking up memory just in case its needed for the deepest function call.

void MyFunctionThatDoesSomething()
{ // <- at function start, the stack pointer is stored for popping when it leaves the functionchar strPrint[34]; // <- strPrint allocated on stack, which is just check stack max and increment a stack pointersnprintf(strPrint, _coundof(strPrint), blah, blah);
} // <-- strPrint just disappears at this point due to the stack being popped for the function

Memory allocations by using new are realitively heavy and if new and delete to often you end up with memory fragmentation which limits allocations after that.

@Makuna I follow that variables defined in the local scope of the function will be cleared( or as I learned the proper term popped of the stack). However, I am confused as what the best practice is when it comes to passing the said char array pointer out!

I wish I could copy your code above, but imagine one of those functions passing a string "This sensor value is of the greatest importance and should not be ignored:%s", the callsite it would be obvious you need a larger buffer for this one case; but if you did it globablly internally, it would be harder to catch.

True, there is a loss in flexibility, but if its a standard string each time (for debug actually) with only the values updating (who's values I know the max value, so the max buffer size), then is it still frowned upon?

Sorry for all the questions, I am trying to relearn C++ with a focus on embedded systems, but using proper object oriented code, rather than than all my sledgehammer-if-it-works-I-am-happy code so far!

its standard right now, you might, someone else might copy your code and also might change in that in the future. Its also about writing robust code. In two months, will you remember details of why? But if you follow good patterns they won't come back and bite you.

AND, I am talking from a point of embedded. Some of this has other arguments against it on desktop machines.

P.S. Have you looked into templates? The old C++ OOD of base classes and derived classes is actually rather memory intensive. Not a subject to step into lightly though ;-)