easyMesh Library for ESP8266.

Using Arduino Programming Questions
1

I am using Easymesh in Arduino IDE to program ESP8266.
I get error in using some functions provided. I have some questions.

when I Download and include easyMesh.h in my program, what happens to the parameters of the function, functions which are not defined in easyMesh.h but in other files like easyMesh.cpp in the same folder? Will the compiler automatically search those things?

Some functions like the one below has 2 different names, which one should I use?

###void easyMesh::setReceiveCallback( &receivedCallback ) Set a callback routine for any messages that are addressed to this node. The callback routine has the following structure…

void receivedCallback( uint32_t from, String &msg )

2

Will the compiler automatically search those things?

No. The compiler is not a search engine. What you pass to a function is defined in the header file. The implementation of the function should be of no concern to you.

Some functions like the one below has 2 different names, which one should I use?

The functions that you listed do completely different things. They are NOT two different names for the same function. You use the name that does what you want to do.

3

The compiler is not a search engine

HAHAHA.... That's a good answer...

The implementation of the function should be of no concern to you

Then how can the compiler give right results.. if it doesnot see the implementation? Why it doesn't give error?

4

Then how can the compiler give right results.. if it doesnot see the implementation? Why it doesn't give error?

If I give you a deck of cards with blue backs and ask you to shuffle the deck, you don't have any problem doing that, do you? Even when I also have a deck of cards in my pocket with green backs?

When the compiler compiles the sketch, it cares ONLY that the variables being passed to a function exist and are of the type that the function expects. The header file defines what types the functions expect.

When the compiler compiles the source file, it sees the same header file, with the same function names, arguments, and types. So, it can determine that the implementation matches the definition.

When the compiler is done with both files, independently, it is the linker's job to fit the pieces together into a hex file that can be uploaded.

When compiling the sketch, the compiler is not concerned that the implementation will be syntactically correct. When compiling the source file, the compiler is not concerned that there will be a caller, or that the caller will be calling the functions correctly.

5

When the compiler compiles the sketch, it cares ONLY that the variables being passed to a function exist and are of the type that the function expects. The header file defines what types the functions expect.

Okey. I got it.

it is the linker's job to fit the pieces together into a hex file that can be uploaded.

Oh...!! So Linker has answer of my doubt. So fro example, if I have function which multiplies and adds two variables then header will only check the types and prototype of the function. and then Linker will do the math on them, Am I somewhat right?

Then Linker should be watching all the function implementations in details, Isn't it?

6

The linker knows nothing about what the functions actually do, they are in machine code,
just an opaque bunch of bytes. The only thing it understands is how to relocate addresses
in the code, because the compiler tells it where they are.

The linker links all the code together: the output is a complete executable that can be run,
with no outstanding unfulfilled references to variables or functions.

The compiler is the only thing that knows what a function does (and only partially, and
only if its an optimizing compiler that does code/dataflow analysis).

7

Oh...!! So Linker has answer of my doubt. So fro example, if I have function which multiplies and adds two variables then header will only check the types and prototype of the function. and then Linker will do the math on them, Am I somewhat right?

If you have a header file, test.h, containing

  int add(int a, int b);
   int multiply(int a, int b);

and a source file, test.cpp, containing

#include "test.h"
int add(int a, int b)
{
   return a+b;
}

int multiply(int a, int b)
{
   return a * b;
}

and a sketch, stuff.ino, containing

#include "test.h"
void setup()
{
   int c = add(3, 4);
   int d = multiply(c, 5);
}

void loop()
{
}

there will be two compile operations. In the first one, stuff.cpp (created by the IDE from stuff.ino) will be compiled, and the compiler will check that the functions are known, and that the arguments to the calls match what the header file says that they should be (or that the values can be promoted to the appropriate type). That will result in stuff.o being created.

The second compile, for test.cpp, will result in the compiler checking that the functions are known, and that the implementation exactly matches the definition. That will result in test.o being created.

Then the linker gets called, with stuff.o and test.o, and a bunch of other stuff. It will find the add() function in test.o, and copy it into the hex file, reserving memory, translating addresses, etc. It will find the multiply function in test.o, and copy it into the hex file, making the same adjustments.

It will find main(), init(), setup(), and loop() in stuff.o, and other stuff in other files, and will copy them into the hex file, reserving memory, translating addresses, etc.

If, when the linker gets done, all the needed functions were found, the uploader is invoked to put the hex file on the Arduino, and it works. Well, it doesn't really do anything, because you have no proof that it didn't assign "The moon is a harsh mistress" to c and 4.5678902335643354677 to d. But, if you added Serial.begin() and Serial.print() calls, those functions would be added to the hex file, and you could have the proof you need.

8

The second compile, for test.cpp, will result in the compiler checking that the functions are known, and that the implementation exactly matches the definition. That will result in test.o being created.

That means compiler have to see during this compilation other files than header when functions are actually implemented.

9

That means compiler have to see during this compilation other files than header when functions are actually implemented.

Functions defined in test.h are usually implemented in test.cpp, but they don't have to be. The compiler doesn't care that functions are defined in the header file but not implemented in the source file.

10

Thank you for your explanation till now but that is what my doubt is. Then how compiler produce the correct results?

for example, in my sketch I have add function like this..

#include "test.h"
void setup()
{
   int c = add(3, 4);
  
}

void loop()
{
}

It will see it in header and test.h that it is there. good. but it should give c=7 is in test.cpp. which it doesn't care.

The compiler doesn't care that functions are defined in the header file but not implemented in the source file.

11

I'll try... in this case, add() is implemented in the source file test.cpp.

Perhaps you are confusing "implemented" and "called".

12

yep anyways thank you @PaulS