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 5 years ago.
Improve this question
I understand that, in C++, we should never use:
using namespace std;
The two possible alternatives are:
1) adding using std::cout; at the beginning of the file and just type cout whenever required
2) type std::cout every time we need to use cout
My understanding is that the second method is the best. However, is this always followed in professional environments? Is it practical to follow in highly fast paced environments? I am used to the first alternative. Is it an advantage to switch?
Note: I originally posted this in Code Review and I was told that this topic belonged here. Kindly let me know if not.
So I have done a little bit with C++, but I would say the problem falls under the problem of namespaces in all languages. The real problem is that if you have multiple namespaces with the same function, it makes it much more difficult to read whats going on and can cause undesired results.
For example if you have two functions with the same name in two name spaces, how will the code know which one to use? Also another problem comes when you have multiple namespaces added and call a function. How does someone reading the code know which namespace the code is coming from? Having the namespace in front of the function helps make your code more readable.
Related
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 1 year ago.
The community is reviewing whether to reopen this question as of 1 year ago.
Improve this question
I am slowly writing an emulator for a gameboy using C++, I am currently working on the CPU side of things. I have written a generic function that takes any two registers of the CPU and returns as a Word data type. As it is necessary to access individual registers and also a combination of registers.
const Word get_word(Byte *registerOne, Byte *registerTwo)
{
return ((*registerOne << 8) | *registerTwo);
};
calling this function gets tedious as you have to specify each register
get_word(&this->registers.h, &this->registers.l)
My question is if it okay to define a macro like so
#define get_HL() get_word(&this->registers.h, &this->registers.l)
since now I can call it using
get_HL()
The reason why I want to do it like this since I don't want to create more private/public functions that just perform function calls.
I have tried compiling and it seems to work as it should since its just a pre-processor macro but I am not sure of the design implication
EDIT:
Okay I mean there are glaring flaws with this and you should just make a function, just as much work to make a function or write a macro.
const Word get_HL() { return this->get_word(&this->h, &this->l); };
Let this be a post for people who had the same idea and hopefully stop making the same mistake
No, this isn't OK in my opinion. It hides what arguments you're passing into the function, and macros don't respect scopes and as such are highly susceptible to name conflicts. This seems like an ideal use case for a non-static member function.
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 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 8 years ago.
Improve this question
I am wanting to have a go at a C++ parser for a formatter I am making.
You can obviously open a file and use getline(..) or get(), is this reasonable way of starting things off and then working out a system using vector arrays and hence creating loads of arrays and somehow structuring out and processing what you are doing from there. For example say I wanted to find ever function in a source file, all functions have the common syntax, "(){" once whitespace has been removed, so do you just look for common delimeters to parse out the sections into arrays. I suppose I will learn as I go.
Or I also assume there are tried and tested ways of doing this, and I would likley just be reinventing the wheel as they say.
C++ is a language that is quite hard to parse in the first place. So if you want anything other that really trivial C++ code to be "understood" by your parser, you are definitely better off starting with an existing product.
The Clang frontend library would perhaps be a good starting point.
There are also a number of "source to source" conversion examples based on clang. Here's one of them: http://eli.thegreenplace.net/2012/06/08/basic-source-to-source-transformation-with-clang/
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
It's a simple question. I'm documenting my code following the documentation of the Doxygen, but I have a question: Where I need to document? On the header, on the source or both of them? I know that this is not a rule, but I want to know your opinion about this and what you do on your code and why you do that. For example: I'm documenting the header, and it's nice, the appearance of the code increased, but when I look the source (.cpp) file, I got scared, because there's no documentation and the code is not beautiful, I mean, not the logic, but in beauty (indentation). And everybody knows that even though the code not beautiful (which is difficult in C++) with a documentation it get coolest and easier to read.
Thank you all. (And remember, before you start writing a moral lesson, know that I know that it's not a rule, I'm just wondering what you do)
Personally I prefer documenting the h file with that sort of thing. People who need to use your APIs might need your header, but not your cpp. People will never need your cpp without the header. Keep the documentation in one place where everyone who needs it gets it.
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
So, in the process of taking a data-structures class (in C++), my professor wanted us to manipulate a linked list of playing cards. That doesn't matter however, what I am interested in is why she did not use an enumerator to represent the suites.
In her code, she used strings to hold the suite of a card. This seemed inefficient because she wanted us to sort them based on suite, under the circumstances, it would have been considerably easier if she had used an enumerated type instead of a string. The string did not offer any help either, because in printing the suite, she output a Unicode character, roughly doubling the length of her function, simply because she did not use an enum.
Is there any reason for her to have done this, or does she simply have strange preferences when it comes to code style?
If you really want to know what your professor's reasoning is, you have to ask your professor. I can only speculate.
But if I were to speculate, I would guess that there are two possible reasons why your professor chose to use strings as descriptors for these attributes.
She is trying to keep the code simple and easy for newbie C++ programmers to understand. Whether the means meet the goal is debateable.
(Personal bias alert) Professors and others in academia, with no real-world experience, often do and teach things that I would consider to be highly sub-optimal.
My guess would be that she either had not considered that approach or that she wanted to test your ability to work with sorting strings.
Code examples might help in that they might clarify what she did and what you think she should have done.
The likely answer is that she just didn't think about the problem she was using to demonstrate whatever she is trying to teach you. That is, she wanted you to focus on sorting (for example), and probably took some code written by someone else and just adapted it to that purpose without much thought.