Time library also defies the usual C++ conventions

I was just looking at the source files of the Time library and it also defies the usual convention of c++ (as far as I am aware) of having your class defined in XYZ.h and the class functions defined in XYZ.cpp

It has the class definitions in TimeLib.h, the class functions implemented in Time.cpp and Time.h just includes TimeLib.h

Ultimately I don't give a rats as long as the library does what I want, but I would still like to understand why this sort of odd looking file naming is a bit a a 'thing' in Arduino libraries.

What would drive authors to have these sorts of arrangements over the stock standard c++ convention of XYZ.cpp and XYZ.h?

I could easily understand if the author had multiple classes defined in multiple XYZ.cpp/h file pairs and just wanted to include a single .h file in order to include all individual XYZ.h files in one line of code.

But Time.h:

#include TimeLib.h

End of file

I don't 'get' why you would bother doing this?

As I understand it, there was a clash with the avr-libc "time.h" header, so the prototypes were moved over into the "TimeLib.h" file. With the latest IDE version(s), from V1.6.10 I think, you have to include "TimeLib.h", not "Time.h" or you'll strike problems. "Time.h" is only there now for backward compatibility with earlier versions of the IDE.

In my case, using IDE V1.6.9, I can include either header without problems.

OldSteve:
As I understand it, there was a clash with the avr-libc "time.h" header, so the prototypes were moved over into the "TimeLib.h" file. With the latest IDE version(s), from V1.6.10 I think, you have to include "TimeLib.h", not "Time.h" or you'll strike problems. "Time.h" is only there now for backward compatibility with earlier versions of the IDE.

In my case, using IDE V1.6.9, I can include either header without problems.

Oh.

Well library clashes are also a bit of a thing with Arduino IDE that needs to be fixed.

This business of the library manager wanting to store libraries in c:\users\username\my documents..... is a bit of a bug bear for me.

I want to use a version of the SD library (in the traditional c:\program files\Arduino\libraries folder) that allows you to specify all the SPI pins in its begin function.

However than damn library manager keeps wanting to update the SD library in the other folder.

If I allow it to do so then my code will no longer compile because the library manager's version of SD overrides my preferred version of the SD library.

I think they should just have options in the library manager allowing you to specify which folder you want it to save the libraries to and a checkbox for each installed library specifying whether the library manager should check for updates or ignore them.

By the way, if it were me writing that Timer library, then I would have taken a consistent approach.

I.E. timelib.cpp, timelib.h and the library called timelib but also with time.h (#include "Timelib.h" and some comments re backward compatibility)

boylesg:
This business of the library manager wanting to store libraries in c:\users\username\my documents..... is a bit of a bug bear for me.

I want to use a version of the SD library (in the traditional c:\program files\Arduino\libraries folder) that allows you to specify all the SPI pins in its begin function.

However than damn library manager keeps wanting to update the SD library in the other folder.
If I allow it to do so then my code will no longer compile because the library manager's version of SD overrides my preferred version of the SD library.

I switched off the prompts for update checking on startup in >File Preferences. It's a PITA. I update manually, whichever libs I want when I want, (and where I want). I'd rather read release notes first anyway, before committing myself.

I think they should just have options in the library manager allowing you to specify which folder you want it to save the libraries to and a checkbox for each installed library specifying whether the library manager should check for updates or ignore them.

That might not be a bad idea, but in lieu of that it's easy enough to manually update libraries if necessary. Generally, I stick to what I have. I like the approach "If it ain't broke, don't fix it." :smiley: