I found the code and it seems to support clock stretching indeed. What I hate about it is that the all the code is in the header file and the cpp file is empty 
IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back 
You know the difference between C source code and a C++ class regarding this issue?
What is the use of having a cpp file if it is empty? Also the cpp file is the one that gets compiled which is why you should put code into the cpp file and the definition in the .h(pp) file. If you look at how the compilation process works then you'd see that a .h file gets concatenated with the .c(pp) file before the c(pp) file gets compiled. Ergo every piece of code inside a .h file gets compiled for each file it is included in. That isn't very efficient!
Another point is that a .h file with a class definition and code combined doesn't make it easy to read which members the class has.
Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.
A source code comment says it does support it. But it doesn't support multi-master mode.
AFAIK, there are two clock stretching variants, i.e. inter-bit and inter-byte.
It's all the same.
Any time the master releases the clock line a slave is allowed to hold it low and the master must wait for it go high before continuing.
What I hate about it is that the all the code is in the header file and the cpp file is empty IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back
In 2017 we prefer all the code in the .h file and no .cpp file at all.
Some IDEs even insist on it.
Define "we"? And could you give your reasoning behind this, and why "in 2017" this is preferred, according to you? Which IDE's insist on this? Defining functions in the .h file implicitly inlines them, meaning your object code - should your compiler comply with this hint - gets copies of your functions wherever they are called. Now, this doesn't seem like a very good strategy, particularly in embedded development where space is generally at a premium. It can be done for very short functions, where the overhead of the call is larger than copying the function, or if you're working on some performance-critical part. But in general, function definitions should go in the .cpp file. Also in 2017.
In case you're joking and talking about the Arduino IDE: at least this isn't advertised as "C++", and note that viewers of something called "EEVacademy" may miss your sarcasm and actually implement your 'advice'.
Define "we"? And could you give your reasoning behind this, and why "in 2017" this is preferred, according to you?
a) Within a compilation unit, I know at least two IDEs that are very unhappy if you include anything that doesn't have a ".h" extension. Apple Xcode and Android Studio. Visual studio also frowns upon it - the autocomplete doesn't suggest anything that doesn't have a ".h" extension if you start typing #include.
b) If there's more than one compilation unit in your project then code like that should be wrapped/abstracted, it shouldn't be exposed everywhere. This means the code will be #included within a compilation unit's ".cpp" file and therefore should be in a header file.
In case you're joking and talking about the Arduino IDE: at least this isn't advertised as "C++", and note that viewers of something called "EEVacademy" may miss your sarcasm and actually implement your 'advice'.
If you're going to use "No True Scotsman" as a preemptive strike then there doesn't seem much point in taking this further.
a) Within a compilation unit, I know at least two IDEs that are very unhappy if you include anything that doesn't have a ".h" extension. Apple Xcode and Android Studio. Visual studio also frowns upon it - the autocomplete doesn't suggest anything that doesn't have a ".h" extension if you start typing #include.
b) If there's more than one compilation unit in your project then code like that should be wrapped/abstracted, it shouldn't be exposed everywhere. This means the code will be #included within a compilation unit's ".cpp" file and therefore should be in a header file.
You said
"In 2017 we prefer all the code in the .h file and no .cpp file at all.". Your above points say something very different, regarding some IDEs being unhappy about including files with extensions other than '.h'. Sure, you generally #include header files (.h), not source files (.cpp). Are you saying that because you cannot include '.cpp' files, you have to put your function definitions in the '.h' file? I'm afraid I'm not following. Do you have experience with C++?
To expand on why you include .h files and not .cpp files, it relates to defining and declaring: you can define (non-static) functions or variables only once, but you can declare them more than once. So, you put the definitions in the .cpp file, and the declarations in the .h file. So that, when you include header files (possibly more than once), you don't break this rule.
David in the 'SPI.h' on the repository left only the declarations, the definitions are in 'SPI.cpp'.
At least it could be agreed that there's no coding style consistency.
a) Within a compilation unit, I know at least two IDEs that are very unhappy if you include anything that doesn't have a ".h" extension. Apple Xcode and Android Studio. Visual studio also frowns upon it - the autocomplete doesn't suggest anything that doesn't have a ".h" extension if you start typing #include.
b) If there's more than one compilation unit in your project then code like that should be wrapped/abstracted, it shouldn't be exposed everywhere. This means the code will be #included within a compilation unit's ".cpp" file and therefore should be in a header file.
I think you got a few things mixed up here! IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.
Saw this:
"// yes, yes, yes, this is windows specific and silly"
(remember YT comment?)
I think you got a few things mixed up here!
Nope.
IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.
For libraries like this one it's much easier to copy a .h file over and #include it in the main file than it is to copy two files over and start messing around with the linker. This is especially true when you need to work on multiple platforms and would need to mess around with the linker multiple times.
Leave the "separate interface and implementation" for big, long-term development, not little projects where you just want to pull a few libraries together as fast as possible. I'll take a big #include ".h" file over "download 50 files along with an out-of-date makefile and try to turn then into a working .lib file" any day of the week.
I think you got a few things mixed up here!
Nope.
IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.
For libraries like this one it's much easier to copy a .h file over and #include it in the main file than it is to copy two files over and start messing around with the linker. This is especially true when you need to work on multiple platforms and would need to mess around with the linker multiple times.
Leave the "separate interface and implementation" for big, long-term development, not little projects where you just want to pull a few libraries together as fast as possible. I'll take a big #include ".h" file over "download 50 files along with an out-of-date makefile and try to turn then into a working .lib file" any day of the week.
Hmm.. well, if the act of copying files is the main bottleneck in your project, you may have a point. But as soon as you have to
use these files, it will quickly become a problem. For one, as I already mentioned before, your embedded project will quickly need an MCU with a bigger flash size as the implicit inlining can copy your functions wherever they are called from. Also, in case you need to include these files from multiple locations, you may alternatively run into multiple definition linker errors depending on if said .h file has any definitions outside of the class body.
Basically, giving up good coding practices for the sake of 'easy copying' is a really bad idea. What if your project evolves into something bigger: you want to then split up and rewrite all those .h files and add .cpp files? Maybe for hacking some throw-away stuff together it could be ok, but that's about it.
And your main statement about
"In 2017 we prefer all the code in the .h file and no .cpp file at all." is just plain wrong, sorry. If you change 'we' to 'I', then it's fine of course
I think you got a few things mixed up here!
Nope.
IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.
For libraries like this one it's much easier to copy a .h file over and #include it in the main file than it is to copy two files over and start messing around with the linker. This is especially true when you need to work on multiple platforms and would need to mess around with the linker multiple times.
Leave the "separate interface and implementation" for big, long-term development, not little projects where you just want to pull a few libraries together as fast as possible. I'll take a big #include ".h" file over "download 50 files along with an out-of-date makefile and try to turn then into a working .lib file" any day of the week.
See, you are mixing things up! You can copy the .c files from the 'library' into your project and include the toplevel.h file into your own toplevel.h to make it work.
See, you are mixing things up! You can copy the .c files from the 'library' into your project and include the toplevel.h file into your own toplevel.h to make it work.
It's much easier to
not even have a toplevel.h for this sort of work. Just put the 'modules' in .h files and #include them all in main.cpp.
See, you are mixing things up! You can copy the .c files from the 'library' into your project and include the toplevel.h file into your own toplevel.h to make it work.
It's much easier to not even have a toplevel.h for this sort of work. Just put the 'modules' in .h files and #include them all in main.cpp.
It is not easier but you just aren't at the point where you see this way of working is asking for major problems if your projects get bigger. It also shows a severe lack of insight in how a C compiler works and how to leverage the power an IDE provides. You don't need to concatenate/include everything in one file to make life easy. The way you work the compiler has to compile all the code if you make one change. When working on a big project this can take a while.
When I first started programming in a commercial environment, it was using IBM assembler on a mainframe. (Don't worry Dave, I'm not about to claim you can write applications faster in assembler than you can in higher level languages. You can't. You can write tight code, fast code in the smallest possible executable - if you are good enough - but you can't write it more quickly.)
What I will say is that, back then, you HAD to be disciplined to have any chance of a practical solution. The first company I worked for was a national concern with branches across the country - and their entire company database was held on a single disk pack of 70MB capacity.
These days - you have microprocessors that are insanely cheap and can run rings around what was available back then. Space is not nearly as much of an issue - and efficiency of code is not as essential as it once was.
The bottom line is - for many applications, you don''t HAVE to be disciplined or efficient ... and in those cases, a less than Fortune 500 "one-up compile" approach is quite adequate.
Where you will get into trouble with a less disciplined approach is where you have a complex system of multiple functional units that get used in varying combinations and/or cross platform. In environments such as that, a structured, disciplined approach is essential. Could you imagine version control without it?