Thanks to Bob Steagall for this. At 26:20, there's an example that shows how large the intermediate translation unit would be for separate main.cpp and hello.cpp files. The size of main.i would be considerably smaller by not #including in hello.h, and only in hello.cpp. I think it's pretty important to not include headers from other headers unless the declarations are necessary for the interface. In this case, is only needed for the implementation of hello.cpp, and not the interface exposed by hello.h. This example could have been used to clarify this important difference.
That's a good point. As an addition to that, if the header needs to define a function that takes a stream reference, the header can #include , which just has forward declarations of the things defined in .
The Basics talks have nothing basic about it, and that's what we need. This information is needed. Well Done. I would like to see in the basics series: Zero cost abstractions for bare metal hardware. For example we don't want to use too many of any Virtuals, Dynamic Memory allocations. What can we use?
Great talk... a lot of 'basic' topics very well explained... by the way: topics like 'declaration vs definition', 'linkage types,' 'one definition rules' and so on, could also be considered 'basic' as the same title specify, but not so easy to find on an online course or tutorial... so it's worth watching, definitely... thanks Bob
Around minute 39, the linkage of g is never mentioned, even though it feels important to mention that it has *external* linkage, even if there is no header for it: it is neither static nor in an anonymous namespace nor inline. Having a second compilation unit with another g like that will have multiple definitions upon linking. This is kind of implicitly explained later in ODR rules with example 2, but seeing this is a very common issue it feels important to highlight.
Bir programın yapısının nelerden oluştuğunu, derlenen programlama dilleri (C ve C++) ile ilgili temel konuları anlatan harika bir sunum. Özellikle programlamayı ilk kez #Python dili öğrenerek başlayan ve ileride C/C++ dillerini öğrenmek isteyenler için faydalı bilgiler içeriyor
you can, but don't have to, however I would argue you never want to do this with a mutable global variable, mutable global state has many drawbacks, but if you decide to use global state anyway (there are legit usecases) then use a meyers singleton. However if you have const global state and dont want a copy in every translation unit where you want to use that state, you can (have to) define them in a .cpp file something like (or use that singleton): extern const type name{ctor args}; because const makes the object have internal linkage, and by adding extern you can override this to have external linkage anyway and you'll be able to refer to it from other translation units. And be aware that having a copy of the global state in several places can be faster than not having a copy (e.g maybe less cache misses), or not.. you'd have to measure (I think, I never have measure this usecase, it seems probable to me with my current experience/knowledge level).
Most of the time you're using c++, you don't even need to think about all these language lawyer ideas. All you need is your compiler, linker, and runtime (ld.so).
As a newbie to c++ I’m finding these “back to basics” lectures very informative
Great to hear!
Thanks to Bob Steagall for this. At 26:20, there's an example that shows how large the intermediate translation unit would be for separate main.cpp and hello.cpp files. The size of main.i would be considerably smaller by not #including in hello.h, and only in hello.cpp. I think it's pretty important to not include headers from other headers unless the declarations are necessary for the interface. In this case, is only needed for the implementation of hello.cpp, and not the interface exposed by hello.h. This example could have been used to clarify this important difference.
That's a good point. As an addition to that, if the header needs to define a function that takes a stream reference, the header can #include , which just has forward declarations of the things defined in .
@@davidfong Thanks for the tip!
The Basics talks have nothing basic about it, and that's what we need.
This information is needed. Well Done.
I would like to see in the basics series: Zero cost abstractions for bare metal hardware. For example we don't want to use too many of any Virtuals, Dynamic Memory allocations. What can we use?
Great talk... a lot of 'basic' topics very well explained... by the way: topics like 'declaration vs definition', 'linkage types,' 'one definition rules' and so on, could also be considered 'basic' as the same title specify, but not so easy to find on an online course or tutorial... so it's worth watching, definitely... thanks Bob
Your talks are just oozing with good information. Thank you very much for your work Bob!
Thank you for taking the time to present this.
Back to basics is always my favourite!
Very clear and concise talk.
Around minute 39, the linkage of g is never mentioned, even though it feels important to mention that it has *external* linkage, even if there is no header for it: it is neither static nor in an anonymous namespace nor inline. Having a second compilation unit with another g like that will have multiple definitions upon linking.
This is kind of implicitly explained later in ODR rules with example 2, but seeing this is a very common issue it feels important to highlight.
Thank you Mr. Bob. Great talk.
Great talk on very important, and very underappreciated, topic.
Thank you for your comment, which is much appreciated!
Wonderful presentation! Thanks for your work
Thanks Bob! Very good and informative video lesson!
Bir programın yapısının nelerden oluştuğunu, derlenen programlama dilleri (C ve C++) ile ilgili temel konuları anlatan harika bir sunum.
Özellikle programlamayı ilk kez #Python dili öğrenerek başlayan ve ileride C/C++ dillerini öğrenmek isteyenler için faydalı bilgiler içeriyor
thank you very much. it was very informative 🙂
Great presentation!👏🏻
Great talk!
32:00 shouldn't we remove the extern keyword for the actual definition?
you can, but don't have to, however I would argue you never want to do this with a mutable global variable, mutable global state has many drawbacks, but if you decide to use global state anyway (there are legit usecases) then use a meyers singleton.
However if you have const global state and dont want a copy in every translation unit where you want to use that state, you can (have to) define them in a .cpp file something like (or use that singleton):
extern const type name{ctor args};
because const makes the object have internal linkage, and by adding extern you can override this to have external linkage anyway and you'll be able to refer to it from other translation units.
And be aware that having a copy of the global state in several places can be faster than not having a copy (e.g maybe less cache misses), or not.. you'd have to measure (I think, I never have measure this usecase, it seems probable to me with my current experience/knowledge level).
thanks.
Thanks 💐🙏
Will we ever see the standardization of dynamic linking? The differences between .so in Linux and .dll in Windows adding a lot of headache.
What an abomination of a language...
What do you recommend?
Most of the time you're using c++, you don't even need to think about all these language lawyer ideas. All you need is your compiler, linker, and runtime (ld.so).