That is true, but the concepts in the Lakos book can be applied to both C and C++. Splitting units of code based upon physical dependencies and having a strong naming system are the basic underlying points. (Disclaimer: I work with John Lakos)
Thank you. The other guy appears to have been thinking I was stating that flippantly, when really a book that is about C++ file organization has to be trying to also be about C file organization.
C++ techniques don't apply to C only projects that often.
Had you said "C or C++" instead of C++, I might not have said that.
Many many many C++ users act like we just don't know C++ or something when use C in systems programming instead of C++, and assume "We just need to upgrade to C++" or the whatever.
If a book only had C++ techniques, it wouldn't be speaking to the topic of this post (which is large scale C programming)
And the comment at the same level at the guy who knows the author directly speaks to how it ALSO applies to C, showing the relevance of your post to the topic
What's this "we"? In the past I've worked on C++ code bases with millions of lines of code. But at RAD we almost exclusively work in C (and assembly, for dozens of platforms). C++ inherited C's broken model for separate compilation with all that implies about physical design for large code bases. As I suggested in the second sentence of my original post, C++ aggravates that problem and therefore calls for special solutions, but there is still plenty of overlap.
None of the context of your experience was in your original comment that talked about C++ organization in a thread about C organization. Sorry there was a misunderstanding.
Comments
C is not C++. They have different issues, namespaces, abi linkage, libraries, various other things. They also have different application domains.
That is true, but the concepts in the Lakos book can be applied to both C and C++. Splitting units of code based upon physical dependencies and having a strong naming system are the basic underlying points. (Disclaimer: I work with John Lakos)
Thank you. The other guy appears to have been thinking I was stating that flippantly, when really a book that is about C++ file organization has to be trying to also be about C file organization.
C++ techniques don't apply to C only projects that often.
Oh, hey, you're _that_ guy! Every thread needs one of you. Thank you so much for putting me in my place by stating the obvious!
Had you said "C or C++" instead of C++, I might not have said that.
Many many many C++ users act like we just don't know C++ or something when use C in systems programming instead of C++, and assume "We just need to upgrade to C++" or the whatever.
If a book only had C++ techniques, it wouldn't be speaking to the topic of this post (which is large scale C programming)
And the comment at the same level at the guy who knows the author directly speaks to how it ALSO applies to C, showing the relevance of your post to the topic
I wasn't being flippant
What's this "we"? In the past I've worked on C++ code bases with millions of lines of code. But at RAD we almost exclusively work in C (and assembly, for dozens of platforms). C++ inherited C's broken model for separate compilation with all that implies about physical design for large code bases. As I suggested in the second sentence of my original post, C++ aggravates that problem and therefore calls for special solutions, but there is still plenty of overlap.
None of the context of your experience was in your original comment that talked about C++ organization in a thread about C organization. Sorry there was a misunderstanding.