correct logic while writing a library

hello,

i have a few question since i am writing a lib

  1. where should i add the include for other lib (like SPI.h) in .h or .cpp or both?
  2. i have been using libraries where i could access function just writing "someFunction()" and other that needs "library.someFunction()" which is the difference?
  3. why do i need to declare public and private variables/function? just to procect the user from changing them?

i guess that for now it is all!
thanks

EDIT: 4) in the .cpp i need to include the .h but not vice versa, correct?

  1. if they are needed for declarations in .h then in .h. otherwise in .cpp
  2. it is no the library name. it is a name of the object defined in the library. look at the end of .h and .cpp for example in the Wire library
  3. the 'user' can't use private members (if he doesn't change the library).
  1. That's a bit hard. In general in the .cpp and try to forward declare in the .h. Nice article about it: Headers and Includes: Why and How - C++ Forum

  2. The second probably is object orientated. Aka, (in most cases) you can create multiple objects which all have a method someFunction(). Object oriented programming is what you want to look for. If you're talking public and private (and class) you're doing object orientated.

  3. Public vs private/protected, yes. If you make them public a user can change them. For example, if you make an object with time of day, if you restrict the user from accessing the hour variable directly (making it protected/private) but only via getHour() and setHour() you could for example stop the user from setting it to 164 which would not make sens because a day only has 24 hours.

  1. great i will put the include in .cpp if possible!

2)i guess that doing "object orientated programming" is more elegant so until my abilities allow me to do it i will try

  1. great explanation!

Curious: what is your library for?

For #1 it depends on the version of the IDE being used.
Only the newer IDEs will look for library referenced header files by libraries.
With older IDEs you have to put the headers for ALL libraries used in the users sketch even if the library is being used by a library and not directly by the sketch.

I think it was IDE 1.6.6 that added support for looking for libraries by libraries.

The reason that this can be important, is if you are creating a library that is used by others, you have to decide if users should be able to use it with older IDEs, if not, then you need to document what versions of the IDE are required for use.

--- bill

bperrybap:
For #1 it depends on the version of the IDE being used.
Only the newer IDEs will look for library referenced header files by libraries.
With older IDEs you have to put the headers for ALL libraries used in the users sketch even if the library is being used by a library and not directly by the sketch.

I think it was IDE 1.6.6 that added support for looking for libraries by libraries.

The reason that this can be important, is if you are creating a library that is used by others, you have to decide if users should be able to use it with older IDEs, if not, then you need to document what versions of the IDE are required for use.

--- bill

ahhhhhh finally i understood why there where people who put all in the .ino and other that just include the minimum stuff without redundancy!

Power_Broker:
Curious: what is your library for?

i took one lib to interface with the mpu9250 and made some small modificaqtion
then i took another two lib and mixed them in one with a small optimization
https://github.com/aster94/SensorFusion

aster94:
i took one lib to interface with the mpu9250 and made some small modificaqtion
then i took another two lib and mixed them in one with a small optimization
https://github.com/aster94/SensorFusion

Sounds interesting, but the link is broken.

Here's the fixed link:

I should have made some copy error, ops!
anyway it is not anything new i just used some libraries i found online after a few research then i put them in one

If i do something like

#include"test/library.h"

Shouldn t it work?

How did you upload the library into the IDE?

Power_Broker:
How did you upload the library into the IDE?

What do you mean by upload? I just copied the folder there
This is the structure i would like to use since i have two lib with the same name, the one i would like to use is in the folder test
Libraries/test/lib.h

aster94:
If i do something like

#include"test/library.h"

Shouldn t it work?

aster94:
This is the structure i would like to use since i have two lib with the same name, the one i would like to use is in the folder test
Libraries/test/lib.h

No, you can't do that. I believe you can specify the full path to the library.

pert:
No, you can't do that. I believe you can specify the full path to the library.

you believe it right pert, i just tried and it worked, thank

pert:
No, you can't do that. I believe you can specify the full path to the library.

well i didn t dream about it
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/Wire/src/Wire.cpp
It seems to be possible to add a .h inside a folder but i don t understand why it doesn t work

in Wire.cpp the include is a relative path into subdirectory in the folder of the library.

you used the libraries folder in your include path. but the libraries folder is not a part of a library it is a configured folder for searching for the libraries

Juraj:
in Wire.cpp the include is a relative path into subdirectory in the folder of the library.

you used the libraries folder in your include path. but the libraries folder is not a part of a library it is a configured folder for searching for the libraries

okk so if i wanted to to that i should modify the arduino library patch? i am not going to do that but i think it could be did, i found it useful

Please explain exactly what you're trying to accomplish. Generally it's a very bad practice to specify paths to external dependencies, whether relative or absolute, because it makes your code very fragile. If that dependency is moved to a different location your code breaks.

A perfect example is one of the many libraries named LiquidCrystal_I2C. Some dummy added this line:

#include "../../Wire.h"

That assumed:

  • That the user had installed the library to the same folder as the Wire library, which is a terrible idea since that library is bundled with the IDE/Arduino AVR Boards and everything at that library folder is lost every time you update the IDE version/Arduino AVR Boards. Also, it prevents use of the "Add .ZIP Library" installation technique, which correctly puts the library in the sketchbook.
  • That Wire.h is in the root of the Wire library folder, which it no longer is due to being converted to the 1.5 library format.

So now we get a steady stream of people confused why their code that includes that library doesn't compile. If the author of that library would have simply done this instead:

#include <Wire.h>

the library would work no matter where it was installed and would be immune to any folder structure changes. That syntax is guaranteed to always work.

Sometimes libraries will put some of their source files in a subfolder. According to the Arduino Library Specification:

in general, the only header files in the root src/ folder should be those that you want to expose to the user's sketch and plan to maintain compatibility with in future versions of the library. Place internal header files in a subfolder of the src/ folder.

So generally I'd say there should be no need for the user to include any of the files in a subfolder. The only exception I can think of is there is a header file in the Ethernet library: utility/w5100.h that has a couple useful functions. To include that file you need to do this:

#include <Ethernet.h>
#include <utility/w5100.h>

If you don't first include Ethernet.h the IDE doesn't know where to find utility/w5100.h.

I would like to organzie my libraries in subfolders like LCD, IMU, ecc but i don t really need it especially if this could bring to complexity
Thank you anyway