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
Which is the most common in C++? Is it different between member functions and free functions? Obviously the standard lib uses snake_case for everything, but almost nobody uses that.
A lot of people (including me) prefer the underscore_style. I think from my 20+ years of experience, currently working in a 100.000+ employees company, having reviewed other company's code, etc. I would expect the underscore style to be the most commonly used style. Why? The STL uses it and almost everyone uses the STL. Also, large parts of Boost use it. Of course, there is no way to prove this.
In some domains other style guides or habbits are in place with different naming conventions, but this might be misleading you if you are in such environment to think that it is also common in other places.
To answer your question about member- vs. free functions: I don't think there is a difference wrt the style used.
What I think is most common in C++ is:
Template parameters: They are usually PascalCase.
Macros: They are usually UPPERCASE_UNDERSCORE_STYLE.
Most everything else, including function-, method-, variable- and parameter-names are underscore style.
There are also studies about the underscore style, here's an except from a study from 2010:
Although, no difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style.
These studies will IMHO lead to even more adoption of the underscore style in the future. But again, there is no way to prove this (or to predict the future).
It depends. If you're working alone, I'd recommend picking a standard and going with it. If there's some code you're interfacing with, it may make sense to follow that code style.
On projects without a defined style guide, I default to the Google C++ style guide (https://google.github.io/styleguide/cppguide.html).
Related
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 3 years ago.
Improve this question
I've somehow implanted in my head the idea that a C++ compiler can perform certain optimizations that a C compiler cannot. I (think I) remember hearing this in a conference talk, perhaps regarding the use of C++ in embedded programming.
If I recall correctly, I think these optimizations had to do with the idea that you can qualify the use of pointers (and other means of indirection, like references) with more information at compile-time.
For instance, "const" is an example of such a compile-time human-supplied tag available both C and C++. Is there similar information that only C++ has?
Some things that spring to mind are the different types of iterators and their requirements, but I'm not sure if that allows for C++ to make some optimizations.
EDIT: I think the talk I had in mind was Dan Saks's cppcon 2016 presentation, but I realize now that (from what I understand) he mainly mentions how C++'s type system allows for better compile-time type-checking.
I think some of the examples I would enjoy hearing more about are things closer to how C++'s std::sort can be optimized more readily than C's qsort (thanks to multiple commenters). Explanations to when this sort of scenario occurs would be greatly appreciated.
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 7 years ago.
Improve this question
Well, i was learning, again, a little bit of c and was with a little curious about how did the C++ inventor made it. And some facts lead me to the information, that he created it using pure C(obviously), so i was thinking if there is any source or anything that could help me to do things in C, that i can do in C++, like templates, namespace, class, reference and others it doesn't matter how difficult it is, i want to at least have more notion, so if anyone know a reliable source and well written i would be glad.
Yes, many, many years back, the first C++ compiler, by Bjarne Stroustrup was a "frontend for a C compiler".
Today, it certainly isn't anywhere like that. Modern C++ compilers generate code directly from C++ constructs in intermediate form for the backend to process into machine code for the target. This allows the compiler to do a more direct job, and not rely on the C compiler "understanding" what is going on.
This page contains some reference material on the cfront:
http://www.softwarepreservation.org/projects/c_plus_plus/index.html#cfront
That page also has links for the 3.0.3 archived sources as unpacked and compressed form.
Note however that this release is 21.5 years old, and would thus, if it was a person be able to order alcohol in a US Bar after showing ID. This is NOT the modern standard C++ by any measure (and it may or may not generate code that is suitable for a modern C compiler, I have no idea)
With this quote to go with the 3.0 release from 1991:
Bjarne Stroustrup notes, "A warning that Cfront 3 is pre-standard and
emphatically not recommended for use or further development might be
in place."
Edit:
I did download the code in the (compressed) link above. It certainly doesn't compile on Linux without effort. More effort than I am willing to spend, really. One of the problems is that it's pre-ANSI C, so the compile complains about various functions not being declared (for example strcpy, strcat, etc), and there are OS choices, none of which is Linux.
I also don't think it is necessarily the best place to start learning compiler techniques.
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 7 years ago.
Improve this question
After learning about c++ through a couple different sources, I found conflicting advice concerning the use of cout/printf(). One source said that printf(), and I quote:
... does not provide type safety, so it is easy to inadvertently tell it to display an integer as if it were a character and vice versa. printf() also does not support classes, and so it is not possible to teach it how to print your class data; you must feed each class member to printf() one by one.
So, the more important thing to me would be the readability factor of using printf(). On the other hand, another source mentioned that cout, with its use of the overloaded operator <<, uses more instructions to execute and can therefore be more expensive in terms of memory over a large program. Although, the person who said this was a systems programmer, in which every bit of performance is vital. But say I wanted to go into game or application development.
Would the performance differences between printf() and cout matter all that much?
In general, does it really matter what I choose to use in an application program?
Thank you for any input.
You would measure the differences on your particular implementation for your specific use case and determine that for yourself.
I would say both lines of reasoning in the question have merit, but you can't generalise about performance.
If you want to go into game or application programming, printf/cout won't be needed too much. The only use in these cases is for debugging.
If you really need to use printf/cout a lot, the difference will be when writing a huge amount of data, otherwise you don't need to bother.
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
My title is rather self-explanatory. I've done research on that before asking this, and hope that I'll receive an informational response. I realize that, of course, it depends on the job, but as an enthusiast C++ programmer (along with a few other languages) I just don't like OOP. I don't like anything about it. So I'm wondering if I'll just have to get over it in order to move into a professional level of C++, or if I'll be okay without it.
You can write programs in C++ and do not use OOP, but professional programmer will have to deal with some one else's code all the time, including your coworkers, using third-party libraries etc. And most of the time OOP is used in C++. So yes, you need to know OOP very well and you will be forced to use it again and again if you stick to C++ in your career.
Most, but not all, of the difference between C and C++ is regarding OOP. Constructors, memory allocation, operator overloading, run-time library, templates -- all are designed with OOP in mind. Having using C++ and not mastering OOP would be difficult.
OOP is not that bad, you may think that OOP is all about:
class customer {
String name, phone;
void sellSomethingTo();
}
but in fact even basic parts of the language are OOP, strings, vectors, matrices, growing arrays, input/output etc.
As ptic12 mentioned, the C++ parts that make it different to C but are not OOP are namespaces, function overloading, stricter type checks, advanced variable scope and declaration.
If you're a brilliant C++ programmer but just hate OOP, you could still probably get hired depending on the job. However a professional C++ programmer should be knowledgeable in OOP and you should make an effort to learn it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I had the impression that there was a paper or article somewhere that claimed every sufficiently large project (not written in a Lisp variant) contained a poorly implemented Lisp interpreter. Google turns up nothing and a quick search of SO doesn't either. Is this something well known and documented somewhere I have forgotten, or just a figment of my imagination?
An actual document or link to such an article would be appreciated, if it exists. Otherwise, I will remove the question.
What Greenspun meant when he uttered this quip was that Lisp provides a great many foundational technologies for writing good software, and that programs written in other languages informally (and inferiorly) reproduce a number of them as they grow.
Yes, this claim is Greenspun's tenth rule (actually the only rule):
Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of
Common Lisp.
It is making a valid point about the expressiveness of Lisp-style features (particularly its kind of macros). However, it isn't serious to the degree you would write a paper on it.