OOP style C vs C++ (for arduino users)

[Dany-Boy55]

First of all, thank you very much for creating such a fantastic library, it is most certainly an amazing piece of work. I must admit I have little to no experience with plain C, but I do have quite a bit with "arduino" C++ and a lot with C#. At the beginning I was completely baffled by the way the library handles object oriented programming, until I did a bit of reading and understood the objects are handled with pointers to objects rather than the objects themselves. Are there any plans to change the style of the object handling to something similar to the current "arduino" like C++?
For example instead of using a pointer to a BLEScan object like this:

BLEScan *pBLEScanner = BLEDevice::getScan();
pBLEScanner->setAdvertisedDeviceCallbacks(new Callbacks());
pBLEScanner->setActiveScan(true);
pBLEScanner->start(30);

Using straight up objects like this:

BLEScan bleScanner = BLEDevice.getScan()
bleScanner.setAdvertisedDeviceCallbacks(new Callbacks())
bleScanner.setActiveScan(true)
bleScanner.start(30)

Thank you in advance for your response!
Cheers!

[nkolban]

Howdy my friend.

In C++ ... if we declare a class as:

class MyClass {
   public:
      void myMethod() ....
}

Then if we create an instance ....

MyClass myClass = someFunction();
... do something;
return;   // At this point, the instance of myClass is destroyed.

Then we are saying that someFunction() returns an instance of MyClass and at the end of usage, it is destroyed.

while if we code:

MyClass *myClass = someFunction();
... do something;
return;   // At this point, the instance of the class is NOT destroyed.

Think of a class as a "template" of an object. When we return an instance of a class, that instance is a NEW instance ... while if we return a pointer to an instance, no new instance is created.

See also:

https://playground.arduino.cc/Code/Pointer
https://www.youtube.com/watch?v=W0aE-w61Cb8

In our BLE story, the BLE library is maintaining class instances. For example a BLE Service is maintained as an object that represents a BLE Service and a BLE Characteristic is maintained as an object that represents a BLE Characteristic.

These objects contain state data (the state of the thing they are modeling). If we passed around copies of those objects, a change in a copy would result in the a discontinuity for the state of the other objects. So we maintain only one copy of the object and pass references around to it.

I won't try and be presumptive and say that working with pointers to objects is a good practice, but by the same token, I can't say its a bad practice either. I don't know how common it is within "common" Arduino programming, but it feels common enough in other programming environments. If we can find some thinking (this community or elsewhere) that indicates that either working with pointers to classes is bad or that there is a better alternative, I'll be happy to change.

[jrickard]

Neil.

You both appear to be in violent agreement.

The convention in Arduino is actually quite common in C++ as well.

Myclass myclass ;

This simply creates an object myclass of class Myclass. It is not a funciton and it doesn't set it to anything. It simply creates an object.

At that point, we normally use C++ syntactic sugar to access public methods and even public variables directly.

myclass.begin(2, 5, 640);

This simply passes three input variables to the begin() function of the object.

By we can do any public method on the object. myclass.setManufacturerData("some shit here");

And indeed, we can access variables directly.

myclass.SomeVariableLIstedasPublic = 640*someothervariable/7;

This gets us out of the whole pointer thing ->. In reality it is just syntactic sugar. But we're all used to it.

Jack Rickard

[Dany-Boy55]

Thank you very much for taking time to reply to my comment, and also thank you for pointing me to a pointer explanation! (pun intended). I'll most definitely take a look at it. @jrickard Captured exactly what I was trying to say, and I now see that it is just a matter of learning what is happening to the instantiated object and syntax. Thanks agian

[nkolban]

Howdy guys.

Let's imagine that the BLE environment is maintaining "things" on our behalf. Those things are the services, characteristics and descriptors that we are either advertising (if we are a server) or are accessors to the remote items if we are a client.

Since these things are "rich" (i.e. they are objects) ... they have data associated with them.

Let us imagine we are a BLE Client and we connect to a remote BLE Server. We now wish to perform work on a service hosted by that remote BLE server. We now want to ask the BLE library to give me a reference to the object that represents that service. For example:

BLERemoteService *pMyService = myBleClient.getService(serviceId);

What we get back is a reference to the existing object.

Without C++ class pointers, what we might see would be:

BLERemoteService myService = myBleClient.getService(serviceId);

However ... there is a dramatic semantic different. In the pointer case, we have only one instance of the object that everyone agrees upon is the object that represents the service. In the second example, what we get is a copy of the object that represents the service.

When objects are relatively small, working with copies of objects isn't a problem but when they get bigger, every time we create and the destroy a copy, work has to be performed. However, in this case, that isn't the biggest concern. Rather it is the notion of state. When we create a new object ... such is the case when we create a copy, we now have two objects that don't share information. When we work with just one object and multiple references to it, the state is always consistent.

Does this notion make any difference to the story being told?

Again ... I'm delighted to discuss alternatives but I want us to share a common understanding of the story and knowledge. It is very possible I am missing something intrinsic. While I think we agree that many classes that are provided by Arduino libraries don't use pointers, it doesn't appear that anything in the Arduino world prevents or even dissuades their usage. When we introduce the usage of language features (C++ in this case) it obviously takes more time and effort to learn them. The question thus becomes (in my mind) not necessarily one of something being broken in the BLE C++ class implementation as opposed to something that could be improved to make usage easier.

If we eliminated class pointers, then we would need to give thought to what would the world look like if we didn't use them?

[nkolban]

Hmmm ... it now dawns on me that we could indeed use instances of classes that are merely wrappers around internally maintained pointers. For example:

BLERemoteService myService = myBleClient.getService(serviceId);

would work ... where the class BLERemoteService() was no more than a wrapper to hold an internal reference to a pointer to an object that is maintained by the BLE C++ classes. This would actually be a good thing from a consumers standpoint. However, now we have a puzzle in front of us. While we could rework this C++ class to achieve that goal, what about existing apps?

Do we leave all the APIs as they are and produce yet another set of APIs with different names or do we rework the API to change the semantics of the existing APIs breaking all apps that exist today?

Given that the functions work today ... and those who may be comfortable working with class pointers would be happy with status quo ... I think this will have to be a community choice as to what way we go.

[Sepp62]

I think you probably want to use references instead of pointers ?

Like this:

BLERemoteService & BLERemoteService::getService(int serviceId)
{...}

BLERemoteService & myService = myBleClient.getService(serviceId);

Also see: [(https://www.tutorialspoint.com/cplusplus/cpp_references)]

[nkolban]

I'd always understood that references were merely re-syntaxing for pointers to class instances. I'm not seeing the benefit.

If we believe that programmers are happier with:

MyClass c1 = functionThatReturnsAMyClassInstance();

as opposed to:

MyClass *c2 = functionThatReturnsAPointerToAMyClassInstance();

I'm not seeing how:

MyClass &c3 = functionThatReturnsAReferenceToAMyClassInstance();

dramatically changes the story?

To call a function in the above three we would use:

c1.myFunction();
c2->myFunction();
c3.myFunction();

However, semantically, there are again distinctions.

{
  MyClass c1 = functionThatReturnsAMyClassInstance();
  return;
}

The class instance is destroyed.

{
  MyClass *c2 = functionThatReturnsAPointerToAMyClassInstance();
  return;
}

The class instance is not destroyed.

{
  MyClass &c3 = functionThatReturnsAReferenceToAMyClassInstance();
  return;
}

The class instance is not destroyed (to the best of my knowledge).

Personally, I think the reference story is more confusing because we could end up with:

{
  MyClass A  = functionThatReturnsAnInstanceOfAClass();
  MyClass &B = functionThatReturnsAReferenceToAnInstanceOfAClass();

  A.func1();
  B.func2();
  return;
}

And other than the declaration, we don't know if we are working with a local class instance or a persistent class instance that exists wider than the local code scope.

I think we need to clear up the problem we are trying to solve and my guess is that there is a school of thought that doesn't like pointers to classes and class member access (->).

[jrickard]

Well I have to confess you have lost me entirely Neil. ``` MyClass c1 = functionThatReturnsAMyClassInstance(); ``` You are instantiating an object of MyClass here and naming it `c1`. Why are you setting it equal to a function at all? We would normally have all functions within the class defined as public or private, and as a class function, we would refer to them as methods. Public methods we call exposed methods. ONCE the actual object is created, it is simply referenced as `c1`. `c1` can have both public methods and public variables. ``` c1.setMyNameinObject("Jack Rickard"); ``` I actually prefer direct variable access though it is generally considered poor form. ``` c1.OwnersName="Jack Rickard" BLEDevice BatteryOne; BatteryOne.ServiceName="Jack's Battery"; BatteryOne.powerdB=10; BatteryOne.advertising=BattAdverisingStructure; BatteryOne.addService(battserv1, 0x3100); BatteryOne.battserv1.AddCharacteristic(battvoltage,0x3101); BatteryOne.battserv1.battvoltage.value=340123; BatteryOne.battserv1.battvoltage.properties=0x1A;//read/write/notify BatteryOne.battserv1.battvoltage.minLength=1; BatteryOne.battserv1.battvoltage.maxLength=4; BatteryOne.battserv1.battvoltage.DataType=3; //Integer BatteryOne.battserv1.battvoltage.UserDescription="Just voltage"; BatteryOne.battserv1.battvoltage.PresentationFormat=0x06; //UINT16 BatteryOne.battserv1.battvoltage.Exponent=-3; //Divide by 1000 to show three digits to the right of decimal. 340.123 BatteryOne.battserv1.battvoltage.PresentationUnit=0x2728;//Electric Potential Difference Volt BatteryOne.battsserv1.battvoltage.NameSpace=1;//Bluetooth SIG Assigned Number BatteryOne.battserv1.battvoltage.Description="This is just a big long text description used by the Client to present on screen"; BatteryOne.battserv1.AddCharacteristic(battCurrent, 0x3102); blah blah BatteryOne.battserv1.AddCharacteristic(battPower, 0x3103); blah blah ``` The object is `BatteryOne`. It persists until we remove power from the ESP32. So what get's destroyed? We can have UNLIMITED methods (functions) and unlimited variables. We can have entire data structures within the object for advertising data, service descriptions, and a really quite complex one for characteristics. And at the end BatteryOne.start(); And at any time later : ``` BatteryOne.battserv1.battvoltage.setvalue(375.245,Notify); ``` Here we use a setter exposed method because we have to do other actions besides just change the content of the variable in the structure. We would multiply the value by 1000 to turn it into an integer and send a notification to the client. ``` BatteryOne.battserv1.battvoltag ``` So I'm missing the whole part of how we set presentation formats, exponents, presentation units, properties, etc for characteristics as described by Bluetooth.org. And I find the whole pointer syntax confusing, opaque, and esoteric. Admittedly probably just a personal preference. But because of the kind of simple educational gestaldt Arduino originally derived from, you almost never see pointers used in main programs. They tend to get buried in the libraries if necessary at all. In fact, I have to tell you Neil, I'm not seeing them in most of the Arduino programs for ESP32 showing up on YouTube either. I do some work with a couple of guys on our Generalized Electric Vehicle Control unit software and they just love em and spew them in all directions. But I haven't seen any specific advantage to them ever. But you kind of have me here on this concept of destruction.... what gets destroyed? Why does it get destroyed? Jack Rickard

…

On Sat, Mar 10, 2018 at 5:37 PM, Neil Kolban ***@***.***> wrote: I'd always understood that references were merely re-syntaxing for pointers to class instances. I'm not seeing the benefit. If we believe that programmers are happier with: MyClass c1 = functionThatReturnsAMyClassInstance(); as opposed to: MyClass *c2 = functionThatReturnsAPointerToAMyClassInstance(); I'm not seeing how: MyClass &c3 = functionThatReturnsAReferenceToAMyClassInstance(); dramatically changes the story? To call a function in the above three we would use: c1.myFunction(); c2->myFunction(); c3.myFunction(); However, semantically, there are again distinctions. { MyClass c1 = functionThatReturnsAMyClassInstance(); return; } The class instance is destroyed. { MyClass *c2 = functionThatReturnsAPointerToAMyClassInstance(); return; } The class instance is not destroyed. { MyClass &c3 = functionThatReturnsAReferenceToAMyClassInstance(); return; } The class instance is not destroyed (to the best of my knowledge). Personally, I think the reference story is more confusing because we could end up with: { MyClass A = functionThatReturnsAnInstanceOfAClass(); MyClass &B = functionThatReturnsAReferenceToAnInstanceOfAClass(); A.func1(); B.func2(); return; } And other than the declaration, we don't know if we are working with a local class instance or a persistent class instance that exists wider than the local code scope. I think we need to clear up the problem we are trying to solve and my guess is that there is a school of thought that doesn't like pointers to classes and class member access (->). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#403 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADTc9NY5yCmsAV4j-XoGLFLWgSxqc6hbks5tdGOngaJpZM4SEdME> .

-- http://www.EVTV.me <http://EVTV.me> Electric Vehicle Television - KickinGas - One Car at a Time.

[nkolban]

Howdy Jack, this is ideally best conducted via a chat / whiteboard and we can easily get lost in the weeds here. I'm not (by far) saying my musings are in any way correct ... they just reflect my own understandings.

Let's just take one item at a time rather than boil the whole soup.

You asked about:

MyClass c1 = functionThatReturnsAMyClassInstance();

In this example, I am not setting c1 to be a function ... but I'm setting c1 to be the class instance returned from the function. Making it plain ... in the BLE land we have the concept of a BLE Service that is represented by an object instance of type BLEService. When BLE is running, the BLE service exists whether or not you have a reference to it. Sometimes you want access to that BLEService in order to ask the service to do something for you.

If we coded:

BLEService myBLEService = BLE.getService(uuid);

Then this would create a new instance of BLEService that would not be the same as the existing instance that ... well ... already exists. Today we return a pointer to the existing instance ... for example:

BLEService* myBLEService = BLE.getService(uuid);

This is a clue to the programmer (and a help to the implementation) that what you are getting back is not a copy of some object but a reference to an instance of an existing object.

We could have designed the interface to be:

BLEService& myBLEService = BLE.getService(uuid);

and again ... you would get a reference to the existing object instance (as far as I can tell).

Given these three styles, we obviously chose one ... the passing of class object instance pointers. The question in front of us is whether there is a better solution and, if there is, what are its attributes that make it better?

[Sepp62]

Assuming, that method one (creating a new instance) ist not what we want in most cases, the discussion is going towards "pointers or references". This article gives a little bit help:

https://www.geeksforgeeks.org/passing-by-pointer-vs-passing-by-reference-in-c/

I quote this part:

Difference in Reference variable and pointer variable

• References are generally implemented using pointers. A reference is same object, just with a different name and reference must refer to an object. Since references can’t be NULL, they are safer to use.

• A pointer can be re-assigned while reference cannot, and must be assigned at initialization only.

• Pointer can be assigned NULL directly, whereas reference cannot.

• Pointers can iterate over an array, we can use ++ to go to the next item that a pointer is pointing to.

• A pointer is a variable that holds a memory address. A reference has the same memory address as the item it references.

• A pointer to a class/struct uses ‘->'(arrow operator) to access it’s members whereas a reference uses a ‘.'(dot operator)

• A pointer needs to be dereferenced with * to access the memory location it points to, whereas a reference can be used directly.

[jrickard]

So that is the original question. Why are we doing that? BLEService myBLE; Why are we not just creating a new object of class BLEService titled myBLE and that BE the object. Then we can access all of its methods and public variables by reference. Alternatively, we have an existing USB port. But Serial.begin(115200) seems to work well enough. As well as Serial.println("some stuff"); For that matter int jack; jack=jill/258; Seems to work well enough. Assuming int is a class and jack is an object. So we can do anything to myBLE that we want. I would probably have two classes, BLEServer and BLEClient but whatever.

…

On Sun, Mar 11, 2018 at 5:04 AM, Sepp62 ***@***.***> wrote: Assuming, that method one (creating a new instance) ist not what we want in most cases, the discussion is going towards "pointers or references". This article gives a little bit help: https://www.geeksforgeeks.org/passing-by-pointer-vs-passing- by-reference-in-c/ <http://url> I quote this part: *Difference in Reference variable and pointer variable* - References are generally implemented using pointers. A reference is same object, just with a different name and reference must refer to an object. Since references can’t be NULL, they are safer to use. - A pointer can be re-assigned while reference cannot, and must be assigned at initialization only. - Pointer can be assigned NULL directly, whereas reference cannot. - Pointers can iterate over an array, we can use ++ to go to the next item that a pointer is pointing to. - A pointer is a variable that holds a memory address. A reference has the same memory address as the item it references. - A pointer to a class/struct uses ‘->'(arrow operator) to access it’s members whereas a reference uses a ‘.'(dot operator) - A pointer needs to be dereferenced with * to access the memory location it points to, whereas a reference can be used directly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#403 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADTc9K0wETK-uWpEvqLYCNVM5DKEcjqOks5tdPa5gaJpZM4SEdME> .

-- http://www.EVTV.me <http://EVTV.me> Electric Vehicle Television - KickinGas - One Car at a Time.

[jrickard]

Sepp62: "Overall, *Use references when you can, and pointers when you have to*." This from your referenced article in summary. Question becomes, why do we have to in creating a BLE library? Jack Rickard

…

On Sun, Mar 11, 2018 at 11:35 AM, Jack Rickard ***@***.***> wrote: So that is the original question. Why are we doing that? BLEService myBLE; Why are we not just creating a new object of class BLEService titled myBLE and that BE the object. Then we can access all of its methods and public variables by reference. Alternatively, we have an existing USB port. But Serial.begin(115200) seems to work well enough. As well as Serial.println("some stuff"); For that matter int jack; jack=jill/258; Seems to work well enough. Assuming int is a class and jack is an object. So we can do anything to myBLE that we want. I would probably have two classes, BLEServer and BLEClient but whatever. On Sun, Mar 11, 2018 at 5:04 AM, Sepp62 ***@***.***> wrote: > Assuming, that method one (creating a new instance) ist not what we want > in most cases, the discussion is going towards "pointers or references". > This article gives a little bit help: > > https://www.geeksforgeeks.org/passing-by-pointer-vs-passing- > by-reference-in-c/ <http://url> > > I quote this part: > > *Difference in Reference variable and pointer variable* > > - > > References are generally implemented using pointers. A reference is > same object, just with a different name and reference must refer to an > object. Since references can’t be NULL, they are safer to use. > - > > A pointer can be re-assigned while reference cannot, and must be > assigned at initialization only. > - > > Pointer can be assigned NULL directly, whereas reference cannot. > - > > Pointers can iterate over an array, we can use ++ to go to the next > item that a pointer is pointing to. > - > > A pointer is a variable that holds a memory address. A reference has > the same memory address as the item it references. > - > > A pointer to a class/struct uses ‘->'(arrow operator) to access it’s > members whereas a reference uses a ‘.'(dot operator) > - > > A pointer needs to be dereferenced with * to access the memory > location it points to, whereas a reference can be used directly. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#403 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ADTc9K0wETK-uWpEvqLYCNVM5DKEcjqOks5tdPa5gaJpZM4SEdME> > . > -- http://www.EVTV.me <http://EVTV.me> Electric Vehicle Television - KickinGas - One Car at a Time.

-- http://www.EVTV.me <http://EVTV.me> Electric Vehicle Television - KickinGas - One Car at a Time.

[nkolban]

This is going to turn into a shaggy dog story. Rather than discuss and design via what will be a lot of git hub posts and cross chats ... let me suggest the following.

If anyone wants to participate in a discussion on these topics, lets do it through skype of some other voice based mechanism and I'll be happy to take minutes of conclusions and post summaries. I'm happy to host as many of these as desired and will make myself available. I can be pinged by email at kolban1@kolban.com (to request a chat at a given time) or ping me by name at IRC #ESP32 channel. Hopefully you'll find me a friendly guy happy to explain any concepts I may have knowledge upon, beliefs about knowledge I think I have (that may be wrong), and explanations (that may be bogus) for why things are they way they are.