The template solution is also OK. One issue with using templates in embedded systems is that the code gets replicated each time the template is instantiated, leading to code bloat; but in this case you will only even instantiate the class once, so that doesn't apply.

Have you considered using a linked list instead of an array? That way you don't need to know in advance how many boards there will be. The disadvantage is that you need a little more RAM to store the links.

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

The template solution is also OK. One issue with using templates in embedded systems is that the code gets replicated each time the template is instantiated, leading to code bloat; but in this case you will only even instantiate the class once, so that doesn't apply.

You mean if I instantiate two classes with the same template parameters I have two copies of the same "generated" code ? That's interesting. Going to google a bit about that...

But yes, the idea is to have just one instance of that class per sketch.

Have you considered using a linked list instead of an array? That way you don't need to know in advance how many boards there will be. The disadvantage is that you need a little more RAM to store the links.

That's an interesting option. For the use case I'm thinking about I think a statically sized array is a better option though.

3. Do nothing. Pretend G++ does implement automatic instantiation management. Code written for the Borland model works fine, but each translation unit contains instances of each of the templates it uses. In a large program, this can lead to an unacceptable amount of code duplication.

3. Do nothing. Pretend G++ does implement automatic instantiation management. Code written for the Borland model works fine, but each translation unit contains instances of each of the templates it uses. In a large program, this can lead to an unacceptable amount of code duplication.

Does not apply here, it is for systems that can have page faults, these models help prevent them. ( page faults can be detrimental to games and such ):

Quote

When used with GNU ld version 2.8 or later on an ELF system such as GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the Borland model. On other systems, G++ implements neither automatic model.

Only ill formed code will have bloat, there is no reason why common code cannot be placed in a base class and inherited into a non-common template.

The instantiations I posted previously will not increase the size of the program unless you actually use the instantiation, they just allow the compiler to generate object files for the required template types:

Nope, standard C++ requires types to be unique, therefore only one definition of code can ever be used to describe a type.

A templated class instantiated twice with different template parameters gives rise to two distinct types.

Yes, that is correct. My response was in regard to multiple instantiations with the same parameters. i.e. the same type.

My doubt is about code duplication when using a template class with the same parameters in two compilation units. E. g. I have to classes, each written with the usual header/cpp file separation. They both #include MPLArray.h and they both have a data member which is an implementation if the template class with the same parameters, say MPLArray<int, 10>.The sketch #includes both classes header files, instantiates and uses one (global) object of each class.Will the final executable contain only one instance of the MPLArrary<int, 10> code, or will there be code duplication ?

My doubt is about code duplication when using a template class with the same parameters in two compilation units. E. g. I have to classes, each written with the usual header/cpp file separation. They both #include MPLArray.h and they both have a data member which is an implementation if the template class with the same parameters, say MPLArray<int, 10>.The sketch #includes both classes header files, instantiates and uses one (global) object of each class.Will the final executable contain only one instance of the MPLArrary<int, 10> code, or will there be code duplication ?

What should happen is that the compiler will instantiate the template once for each file, then the linker will spot that they are the same and only include one of them in the final code. To test this, if you change the second parameter for one of the instantiations, you should see the code size jump up.

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

foxbat

Will the final executable contain only one instance of the MPLArrary<int, 10> code, or will there be code duplication ?

There will only ever be one instance of the executable code if that's what you mean. Each compilation unit gets its own copy of the template methods in the object code but they are marked with the .weak attribute which causes the linker to discard duplicates.

The compiler implicitly marking functions as weak is different to explicitly using a function modifier, may not be portable either.

The serial case usage is not used on a template, and is there to stop multiple definition errors and allow the user to implement the body of serialEvent in their own code.

The hardwareSerial.cpp file is compiled first so without having a weak definition that the linker can throw away, it would have an 'unresolved external. When your sketch is compiled with a new function body, the linker will select it and discard all the others.