![]() ![]() Which means that they’re oblivious to the semantics of the code they’re operating on. As long as you #include it, all your As become Bs.Īnother issue is coming from the fact that operate at the level of the text of the source code. cpp is not even aware that they include aHeader.hpp, or even who this aHeader.hpp is to begin with.Ĭontrary to a function, an object or a type, you can’t confine a macro to a class or a namespace. If it says #define A B for example, then the preprocessor will replace every A by a B in those files even if they remotely #include the culprit aHeader.hpp. Whether they like it or not.Īnd that’s a big impact, since that macro is going to change their code. This means that if a file, say aHeader.hpp, declares a #define directive, then the rest of that file along with every line of every other files that include aHeader.hpp, directly or indirectly, are impacted by this #define. One of them is that they don’t have scope. Why are macros bad, to begin with? Indeed, Effective C++ item 2 recommends to stay away from #define directives, and show how other basic features of C++ can do the same job, only better. Indeed, even if a lot of macros end up making the code confusing, some macros constitute an improvement to the code, and can make it more expressive and still correct. ![]() ![]() It implies that this rule itself has exceptions too, which means that there exists a rule somewhere, that doesn’t have exceptions. But that rule isn’t “don’t use macros”. There is a rule that says that every rule has its exceptions. Well, except the macros that are good, that is. Macros are bad, it’s a well known fact, they’re vestiges from the past that really, really don’t fit well with the ever-growing modernity of C++. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |