Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
In much different projects, I got sooner or later some errors/warnings/problems while using global variables. Is there style a good program design to use global variables right in my projects or to avoid it completely
I read much articles about this issue and all are telling the same: Replace global variables with local variables, context objects, different patterns (singleton) and such things, but there are no explicit examples and descriptions how to use it right.
Do you have some good hints or references about that theme?
singletons are very similar to global variables in the problems they cause. Try looking at the "Parametrisation From Above" pattern instead.
It is a though task to get rid of global variables. Obviously there might be some strictly necessary, those will most likely be declared in your main or in header files.
A good example of global variable is a "struct" for parsing options from a configuration file: you load it once at the beginning of the execution and then you can keep accessing it from everywhere else. Or, you could also do the same with an object with set/get methods to retrieve those same config options (but still, the object would be declared global).
Also do not underestimate the power of macros. Whatever you decide to do, never forget the basic principle: DRY, Don't Repeat Yoursef. Keep things simple and keep them stored one place only.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Which .dll file contains "std::chrono::system_clock" method?
I can't find any useful information in the documentation.
EDIT:
I want to create my own version of the function, so I wanna rebuild the file and replace it in the import table of my own application
All you need is to #include <chrono>. No further deployment needed.
Well, without knowing your actual goal ("knowledge over rules", you said) it is impossible to tell you the right way to achieve it. I can only tell you that this is not it.
I just want to do that if it is possible
For some value of possible, maybe.
It's possible that the code for this type is defined right there in the header, rather than built into the runtime. So, you would only "need" to modify the header. But then what about the rest of the runtime that expects the type to look a certain way? You've just violated the one-definition rule at the first hurdle.
It should go without saying:
DO NOT DO THIS.
Your program has undefined behaviour when you modify the standard library, even if you can somehow manage to get enough controls of your implementation's internals to make it work without crashing and/or catching fire.
To do this "properly" you would have to fork and rebuild the entire standard library implementation so that its contents are consistent. Good luck with that.
Instead, if you want to use a type that looks like std::chrono::system_clock (it is not a "method", or member function — it is a class) but acts differently, then define such a type yourself in your own namespace.
People have been doing this, when mocking implementation functions, for many years. Your unit testing framework should come with some documentation that teaches you how to mock functionality successfully and reliably.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I realize this might be a controversial topic, but as a prospective developer who is entering industry in a couple of weeks, I'm trying to get an idea of the do's and dont's when writing code.
One of the things that even my professors seem to be at odds on is where should local variables be declared. I've had professors insist that the only way is to declare them all at the start of the function. This has the benefit of not reconstructing a new object every time a loop is entered, for example. But it has the draw back of making logic harder to follow since you don't know which variables are used in which scopes.
Other professors say that it is good practice to declare them when you use them. Even if it's in the middle of the lines of code. This seems to be more of a Python style of coding and could possibly clutter the code with, verbose, and unnecessary type information. Also, this could incur a performance penalty since the object will get constructed and then destructed in every iteration of the loop.
Then I had another professor say to declare them at the start of their respective scopes. So ideally, after each { there would be declarations for all the variables used in that scope. This seems to offer the best readability, and the worst performance since now the object could potentially be constructed and then assigned to (two separate, possibly expensive operations) in every loop iteration.
I hope you can see how a new programmer can get confused about what format to follow. So is there consensus in the work field about which style is the "best"?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am new to C++ and I have a general question. In order to solve any question in the exercises of the book I am learning from, while I am able to successfully solve the questions, I usually end up creating a lot of new variables within functions in addition to the ones that I have already initialised. For some reason, this worries me because I feel that I am writing inefficient code that might hog resources if I follow this practice for more complex programmes. Am I wrong in thinking this way? Are there any best practices regarding initialising and declaring new variables?
EDIT: I forgot to add, before resolving any question, I tend to convert the solution into plain English and then attempt to draw the program structure.
Normally compilers do liveness analysis of variables during the compilation of your code. Variables are considered live only starting from their assignment till their last use - optimizing compilers are capable of reducing the amount of local storage on the stack that is required by sequentially used variables (sometimes they even can eliminate their use entirely or keep them in registers only for a short period of time).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Many times I hear "Singleton is a bad practice, static methods are bad practice" all I can see for reason is "hard to test".
But I do think sometimes its really good if an operation can be done without instantiate a class.
EDIT: just because of testing, anyone can find out that "private methods are bad too, they cant be tested" for example
It is a question about semantics and expressing intent.
A static method is not inherently bad, apart from that it is hard to test. The bad part is confusing other programmers by using static methods just to avoid creating new instances.
If the method relates to the class itself and not to individual instances (Like a factory method for example), then by all means use a static one. But if the method semantically belongs to an individual instance, then use a non static method.
Static methods are generally frowned upon for much the same reason as global variables, in addition to testing issues:
Static methods do not relate to a specific class instance so will not always be thread safe.
Systems with lots of statics methods often do not scale well.
Confusion due to the mixture between calling static methods of a class and members of an instance of a class can lead to maintenance issues.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a project that contains several classes. I added to this project several functions that are used by one of the classes, let named MainClass. I put all these functions in a file stuff.h. To use these functions I include the stuff.h file at the beginning of the implementation of the class MainClass. I am wondering if this is a good style of programming or if it would be better to create a new class and add my functions to this class. Then I instantiate this class in the MainClass.
Not so good style. Starting from the fact headers are not actually intended to have real code but declarations of things defined somewhere else.
If your 'external' functions are used only by MainClass why not to do them class methods? Even maybe private so they are only visible inside class? Keep things as encapsulated as you can. If you're trying to follow C++, try not to use 'plain C functions'. It's different language. If you absolutely need plain routines, use namespaces instead. But please try to keep your code inside modules (.cpp), not in headers.
Regarding other classes. It depends if you know why you need other classes. If you don't know why, you don't need them. BTW OOP is not always 'best' approach, especially in things like balance between inheritance and composition. You should understand what you really want to achieve to select proper technique.
Indeed you need good C++ book. Chapters about project composition, compilation process, translation units so you will understand logics behind this. This Q&A site cannot explain you everything. Just give some points.
Good question here for you
I think it would be better to create a new class, or several new classes that are ordered by the different ways the functions will be used. That's more in line with classic OO.