user7727: I'm writing a new serial library (eRCaGuy_Peer2Peer) to allow any 2 pins on an Arduino to be used for peer-to-peer type communication between Arduinos, withOUT interrupts or timers/counters. 
Currently SPI, Serial, and I2C are pin-specific, and SoftwareSerial requires pin change interrupts. My implementation will solve these problems. 
However, I first am trying to understand some things. As I study SoftwareSerial, I see it inherits from the Stream class, which inherits from the Print class. 
I don't understand how Print's write is implemented. This is from Print.h:
virtual size_t write(uint8_t) = 0;
size_t write(const char *str) {
  if (str == NULL) return 0;
  return write((const uint8_t *)str, strlen(str));
}
virtual size_t write(const uint8_t *buffer, size_t size);
size_t write(const char *buffer, size_t size) {
  return write((const uint8_t *)buffer, size);
}

This is from Print.cpp:
/* default implementation: may be overridden */
size_t Print::write(const uint8_t *buffer, size_t size)
{
  size_t n = 0;
  while (size--) {
    if (write(*buffer++)) n++; //<--where is this write defined?
    else break;
  }
  return n;
}

My Questions:

What does this mean? I've never seen anything like this before: virtual size_t write(uint8_t) = 0; Why the = 0?
What does it mean/how does it work defining functions in .h files? I've never done this before: ex:
size_t write(const char *str) {
  if (str == NULL) return 0;
  return write((const uint8_t *)str, strlen(str));
}
Where is the write command I've marked above defined? Is Print::write() calling itself recursively?
Also, why does SoftwareSerial.h call using Print::write; (shown below) when it already re-implements the virtual write function just above that?

virtual size_t write(uint8_t byte);
    virtual int read();
    virtual int available();
    virtual void flush();
    operator bool() { return true; }
using Print::write;


user4143: write is implemented in the class that inherits the Print class - such as HardwareSerial.
There are a number of write functions, and they are overloaded, which means that they are all distinct functions identified using their parameters as well as their name (write(uint8_t) and write(uint8_t *, size_t) are different functions).  The child class overrides the write(uint8_t) function that is pure virtual1 in the main Print class, but the other write functions with other parameter lists aren't overridden and are just "used".
The using Print::write tells it "the write functions to which I am referring are from the Print class."

Using-declaration introduces a member of a base class into the derived class definition, such as to expose a protected member of base as public member of derived. In this case, nested-name-specifier must name a base class of the one being defined. If the name is the name of an overloaded member function of the base class, all base class member functions with that name are introduced. If the derived class already has a member with the same name, parameter list, and qualifications, the derived class member hides or overrides (doesn't conflict with) the member that is introduced from the base class.

I'm not entirely sure why they feel they need to use it, since the write functon(s) in Print are public and thus exposed already.

What does it mean/how does it work defining functions in .h files? I've never done this before

Exactly the same as if you had defined the function in a .cpp file, but with a few minor differences, the most important one of which is that the compiler finds it easier to inline the function (or if you're really lucky eradicate the function altogether). It's great for simple functions such as setters and getters that just set or return the value of a variable. In such cases inlining is desirable, and the compiler may even be able to replace the entire function with just direct access to the variable (if it's clever enough).
Another important thing to note with functions in .h files is that you can only really do it with class member functions or static functions. Otherwise you end up with compilation errors complaining about multiple definitions if you use the header file in more than one place.


1: A Pure Virtual function (such as virtual size_t write(uint8_t) = 0;) is one which has to be implemented in the child class. Failure to implement it results in a compilation error. The pure virtual function defines part of the interface but doesn't implement the software for it - that is down to the child class to implement.


user41160: In the Print class the virtual size_t write (uint8_t)=0 DEFINES and names a function that accepts a byte and returns a size.  ANY "virtual" function in a base class CAN be over-ridden in a derived class; however, the =0 declares that there is NO actual function in the base class -- the compiler sticks a null function pointer there.  This is why pure virtual functions MUST be over-ridden in the derived (child) class.
The using Print::write; in the .h header file of your derived class tells the compiler that YOUR size_t DerCl::write (uint8_t val) {} should fill in that null pointer in the base class...this is why your write function must be declared exactly like the one in the base class.  If it were not, then when the base class calls it, it would push too many values onto the stack, it would pop too many values off the stack, or it would mix up the parameters sent to the function, etc.
This "polymorphism" allows the base class (Print) to define an interface (for printing in this case) and simultaneously allows the derived class to determine where the resulting byte stream will be sent.  Serial sends it to the USART's serial port.  SoftSerial sends it to any two port pins (one Tx and one Rx).  But you also can create classes to use SPI, TWI(i.e. CAN), a HDMC file, an LCD display, etc.  And you can leverage the uniformity and the functionality of all of the Write(), print(), and println() functions that you're already familiar with by writing a single, simple size_t write(uint8_t) function for your derived class.

7727: <p>I'm writing a new serial library (<a href="https://github.com/ElectricRCAircraftGuy/eRCaGuy_Peer2Peer" rel="nofollow noreferrer">eRCaGuy_Peer2Peer</a>) to allow any 2 pins on an Arduino to be used for peer-to-peer type communication between Arduinos, withOUT interrupts or timers/counters. </p>

<p>Currently SPI, Serial, and I2C are pin-specific, and SoftwareSerial requires pin change interrupts. My implementation will solve these problems. </p>

<p>However, I first am trying to understand some things. As I study <a href="https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/SoftwareSerial/src/SoftwareSerial.h" rel="nofollow noreferrer">SoftwareSerial</a>, I see it inherits from the <a href="https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/Stream.h" rel="nofollow noreferrer">Stream class</a>, which inherits from the <a href="https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/Print.h" rel="nofollow noreferrer">Print class</a>. </p>

<p>I don't understand how Print's <code>write</code> is implemented. This is from Print.h:</p>

<pre><code>virtual size_t write(uint8_t) = 0;
size_t write(const char *str) {
  if (str == NULL) return 0;
  return write((const uint8_t *)str, strlen(str));
}
virtual size_t write(const uint8_t *buffer, size_t size);
size_t write(const char *buffer, size_t size) {
  return write((const uint8_t *)buffer, size);
}
</code></pre>

<p>This is from Print.cpp:</p>

<pre><code>/* default implementation: may be overridden */
size_t Print::write(const uint8_t *buffer, size_t size)
{
  size_t n = 0;
  while (size--) {
    if (write(*buffer++)) n++; //&lt;--where is this write defined?
    else break;
  }
  return n;
}
</code></pre>

<p><strong>My Questions:</strong></p>

<ol>
<li>What does this mean? I've never seen anything like this before: <code>virtual size_t write(uint8_t) = 0;</code> Why the <code>= 0</code>?</li>
<li><p>What does it mean/how does it work defining functions in .h files? I've never done this before: ex:<br>
<code>size_t write(const char *str) {
  if (str == NULL) return 0;
  return write((const uint8_t *)str, strlen(str));
}</code></p></li>
<li><p>Where is the <code>write</code> command I've marked above defined? Is Print::write() calling itself recursively?</p></li>
<li>Also, why does <a href="https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/SoftwareSerial/src/SoftwareSerial.h" rel="nofollow noreferrer">SoftwareSerial.h</a> call <code>using Print::write;</code> (shown below) when it already re-implements the virtual <code>write</code> function just above that?</li>
</ol>

<p><code>virtual size_t write(uint8_t byte);
    virtual int read();
    virtual int available();
    virtual void flush();
    operator bool() { return true; }</code></p>

<pre><code>using Print::write;
</code></pre>
 4143: <p><code>write</code> is implemented in the class that inherits the Print class - such as HardwareSerial.</p>

<p>There are a number of <code>write</code> functions, and they are <em>overloaded</em>, which means that they are all distinct functions identified using their parameters as well as their name (<code>write(uint8_t)</code> and <code>write(uint8_t *, size_t)</code> are different functions).  The child class overrides the <code>write(uint8_t)</code> function that is <em>pure virtual<sup>1</sup></em> in the main <code>Print</code> class, but the other <code>write</code> functions with other parameter lists aren't overridden and are just "used".</p>

<p>The <code>using Print::write</code> tells it "the write functions to which I am referring are from the Print class."</p>

<blockquote>
  <p>Using-declaration introduces a member of a base class into the derived class definition, such as to expose a protected member of base as public member of derived. In this case, nested-name-specifier must name a base class of the one being defined. If the name is the name of an overloaded member function of the base class, all base class member functions with that name are introduced. If the derived class already has a member with the same name, parameter list, and qualifications, the derived class member hides or overrides (doesn't conflict with) the member that is introduced from the base class.</p>
</blockquote>

<p>I'm not entirely sure why they feel they need to use it, since the <code>write</code> functon(s) in <code>Print</code> are public and thus exposed already.</p>

<blockquote>
  <p>What does it mean/how does it work defining functions in .h files? I've never done this before</p>
</blockquote>

<p>Exactly the same as if you had defined the function in a .cpp file, but with a few minor differences, the most important one of which is that the compiler finds it easier to <em>inline</em> the function (or if you're really lucky eradicate the function altogether). It's great for simple functions such as <em>setters</em> and <em>getters</em> that just set or return the value of a variable. In such cases <em>inlining</em> is desirable, and the compiler may even be able to replace the entire function with just direct access to the variable (if it's clever enough).</p>

<p>Another important thing to note with functions in .h files is that you can only really do it with <em>class member functions</em> or <em>static</em> functions. Otherwise you end up with compilation errors complaining about <em>multiple definitions</em> if you use the header file in more than one place.</p>

<hr>

<p><sup>
1: A <em>Pure Virtual</em> function (such as <code>virtual size_t write(uint8_t) = 0;</code>) is one which has to be implemented in the child class. Failure to implement it results in a compilation error. The pure virtual function defines part of the <em>interface</em> but doesn't implement the software for it - that is down to the child class to implement.</p>

<p></sup></p>
 41160: <p>In the Print class the <code>virtual size_t write (uint8_t)=0</code> DEFINES and names a function that accepts a byte and returns a size.  ANY "virtual" function in a base class CAN be over-ridden in a derived class; however, the <code>=0</code> declares that there is NO actual function in the base class -- the compiler sticks a null function pointer there.  This is why pure virtual functions MUST be over-ridden in the derived (child) class.</p>

<p>The <code>using Print::write;</code> in the .h header file of your derived class tells the compiler that YOUR <code>size_t DerCl::write (uint8_t val) {}</code> should fill in that null pointer in the base class...this is why your <code>write</code> function must be declared exactly like the one in the base class.  If it were not, then when the base class calls it, it would push too many values onto the stack, it would pop too many values off the stack, or it would mix up the parameters sent to the function, etc.</p>

<p>This "polymorphism" allows the base class (Print) to define an interface (for printing in this case) and simultaneously allows the derived class to determine where the resulting byte stream will be sent.  <em>Serial</em> sends it to the USART's serial port.  <em>SoftSerial</em> sends it to any two port pins (one Tx and one Rx).  But you also can create classes to use SPI, TWI(i.e. CAN), a HDMC file, an LCD display, etc.  And you can leverage the uniformity and the functionality of all of the <code>Write()</code>, <code>print()</code>, and <code>println()</code> functions that you're already familiar with by writing a single, simple <code>size_t write(uint8_t)</code> function for your derived class.</p>
