The enum hack used to be necessary because many compilers didn’t support in-place initialization of the value. Since this is no longer an issue, go for the other option. Modern compilers are also capable of optimizing this constant so that no storage space is required for it. The only reason for not using the static … Read more
Circular imports are not inherently a bad thing. It’s natural for the team code to rely on user whilst the user does something with team. The worse practice here is from module import member. The team module is trying to get the user class at import-time, and the user module is trying to get the … Read more
If you define a class without any constructor, the compiler will synthesize a constructor for you (and that will be a default constructor — i.e., one that doesn’t require any arguments). If, however, you do define a constructor, (even if it does take one or more arguments) the compiler will not synthesize a constructor for … Read more
If I create a class MyClass and it has some private member say MyOtherClass, is it better to make MyOtherClass a pointer or not? you should generally declare it as a value in your class. it will be local, there will be less chance for errors, fewer allocations — ultimately fewer things that could go … Read more
No, it makes no difference. However the reason is not because it is a member declaration inside an interface, as Jon says. The real reason is according to language spec (8.9) that Nested enum types are implicitly static. It is permissable to explicitly declare a nested enum type to be static. At the following example … Read more
I like to have a logger method available in my classes, but I don’t like sprinkling @logger = Logging.logger in all my initializers. Usually, I do this: module Logging # This is the magical bit that gets mixed into your classes def logger Logging.logger end # Global, memoized, lazy initialized instance of a logger def … Read more
What does your .h file end with? I’m guessing that the end of your class defnition does not have a “;”. The class is being interpreted as the return type of the first function in your cpp file.
Of the three, I prefer option #3. The Single Responsibility Principle makes me not want to put searching capabilities on my DTOs or models. Their responsibility is to be data, not to find themselves, nor should needles need to know about haystacks, nor haystacks know about needles. For what it’s worth, I think it takes … Read more
This is a bit of a tangent based on the response by “Mitch Wheat”. Generally, anytime I see people cite the framework design guidelines, I always like to mention that: You should generally ignore the framework design guidelines most of the time. This isn’t because of any issue with the framework design guidelines. I think … Read more
You can’t. The next best thing you can do is have using declarations in the files that use the class. For example, you could rewrite the dependent code using an import alias (as a quasi-typedef substitute): using ColorScheme = The.Fully.Qualified.Namespace.Outlook2007ColorScheme; Unfortunately this needs to go into every scope/file that uses the name. I therefore don’t … Read more