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
I've been told before (rightly or wrongly) that I should be using various older standards of C and C++. For example in a Uni module I did on C this year we had to use ANSI C (which I believe is C89?). Other times I've been told to use C99.
Every time I'm told either of these, the reason given is that C11 is not safe to use, due to new features that may not be supported by every compiler etc. (I'm not a massive expert on this so explanation would be great).
It seems ludicrous to me that a standard is still not widely used 3 years after its release. Are these people wrong or is it genuinely a bad Idea to use C11 and C++11?
Neither, both... the bane of legacy.
No you should use the newest tools available on your platform and that are compatible with the other elements in the system. New tools allow for "better" programming, safer programs, more concise programs, etc.
Yes you should use older tools, well, very simply, a lot of work is maintenance. Some of it will be on very old systems... being familiar with the issues of the tools will help when changes need to be made.
Your target audience (people and systems) will dictate what tools to use and what tools to support. The lowest common denominator almost always wins.
For the same reasons, I think this is the principle motivation for backwards compatibility. If the new tools don't break the old code, then the progression forward is eased.
In general, it is a good idea to use the newer language features with new compilers. There is a general move within the industry to support newer languages (even before the standard is final, e.g. clang and gcc with the upcoming C++14).
One of the major C compiler vendors, Microsoft, have stated that they do not intend to support the evolving C standard; they supply a C90 compiler and their C++ compiler will compile the C subset of the current C++ standard.
If you do not need your C code to compile on Windows, or you can use a non-Microsoft compiler, then you should feel free to use C11.
In any case, since the C subset of C++11 is closer to C11 than it is to C90, it makes more sense to learn the current C standard and the subset of that standard that is compatible with the current C++ standard.
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 4 years ago.
Improve this question
I used to program in C++ professionally, but that was ages ago. Now I'm returning to it. Boy, has C++ evolved!
I've been studying up on the latest features introduced in C++11, including lambda expressions, good multi-threading support (stuff that previously only boost supported), etc.
Lately, on my Ubuntu 16.04 LTS machine, I've been compiling like this:
g++ -std=c++11 filename.cpp
However, apparently there's also C++14 and C++17. If I want to be fully up-to-date with modern C++ programming practices, should I be compiling like this instead?
g++ -std=c++17 filename.cpp
Assuming my code compiles either way, is there any reason why I shouldn't just compile all of my new code using C++17?
I'm already delving into stuff like shared_timed_mutex, which is in C++14, but haven't yet played with even newer stuff, like atomic, which is in C++17. So, in some respects, I suppose I'll need C++17 eventually.
I'm just trying to understand if there's any harm in me just using C++17 always when compiling.
To provide more context, I'm only compiling for one platform (Ubuntu Linux). There's no need to think about backward compatibility, or other operating systems. When you take that into account, with my desire to learn the latest C++ features, is there any reason why I shouldn't just always compile with C++17?
Or, restated another way, as of today's date, April 11 2018, can I assume that compiling with -std=c++17 uses fully released features, nothing of which is experimental?
The answer depends on many factors, but the main question is what is target of your library or application?
What platforms are you planing to support?
There are some platforms which do not have the newest version of C++ compiler. In fact there are some platform which can you provide only C++03.
Since new version of C++ introduce some new cool features and standard library API, it the best to use the newest C++ which will cover all platforms which you are planing to use.
If you do not know what platform to use, think about features of C++ you whish to use and use minimal version of C++ which can provide them. This way you can postpone decision of supported platforms for a later 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 5 years ago.
Improve this question
We expect that converting old sources from using TR1, to not using it, will be straightforward work such as fixing #includes, changing a few names, and patching the build system, but cannot find a definitive statement that this is so for everything in TR1.
I know C++14 through language enhancements and a new standard library now provides many nice things that were in TR1. Even C++11 took over quite a lot from TR1.
But have all things in TR1 been made available as language and library features? What in TR1 hasn't been eaten by C++14? (Things we don't use, we hope.)
As for TR1 features now in C++14, do any require more effort than simple name changes?
C++ Technical Report 1 (TR1) is the common name for ISO/IEC TR 19768, C++ Library Extensions, which was a document proposing additions to the C++ standard library for the C++03 language standard. The additions include regular expressions, smart pointers, hash tables, and random number generators. TR1 was not a standard itself, but rather a draft document. However, most of its proposals became part of the later official standard, C++11. Before C++11 was standardized, vendors used this document as a guide to create extensions [1].
Generally, most of the features from TR1 passed to C++11, except some minor exceptions and some renamings in <random> header, shown below:
<random>
variate_generator didn't make it.
linear_congruential made it as linear_congruential_engine
mersenne_twister made it as mersenne_twister_engine
subtract_with_carry made it as subtract_with_carry_engine
subtract_with_carry_01 didn't make it.
discard_block made it as discard_block_engine
xor_combine didn't make it.
uniform_int made it as uniform_int_distribution
uniform_real made it as uniform_real_distribution
Also note that from the <type_traits> header in C++17 result_of was replaced with invoke_result.
[1]: C++ Technical Report 1
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 6 years ago.
Improve this question
How to compensate the differences between the syntax of different compilers of the same programming language? How could I know which one is standard and used worldwide to make projects?
For example: I worked 4 months on Borland C++ compiler to learn C++ but now I saw the syntax of Borland, Visual C++ and Developer C++ is different. I am confused, need some guidance...
The first solution is to not use parts which are specific to one compiler or another. Before you use a feature of the language, check on the internet to see if it's specific to any one compiler. If it is, then don't use it.
Other than that, actually making a C/C++ program which is compilable by different compilers is a task which takes effort. It doesn't "just happen", because the compilers each have their own quirks, their own level of support of the standard etc. Even writing compliant C99/C++11 code you might still see issues. So one solution is to actually compile the program with different compilers on a regular basis (say, as part of testing before pushing code to the central repository) and make sure that all of them can compile the code, and the resulting software can run.
As for "standard" compilers, on Linux and Mac gcc and clang can be considered "gold". On Windows, the compilers by Microsoft are standard.
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 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 am new to C++11, and found it is a difficult and tedious work to find alternative ways to make my code compatible with both Clang and Visual C++.
What's the reason behind this fact? Is that technique difficulties? Compatibility with old non-standard language extensions? Different priorities? Or any other possibilities?
The reference page: https://wiki.apache.org/stdcxx/C++0xCompilerSupport
Why most of the modern C++ compilers only support limited C++0x features, while Clang supports all of them?
clang was designed much later than most of the other major compilers, and was built in a way that makes it easier to support some of the modern features. Many other compilers, such as MSVC and GCC, support many other targets than clang, and have a large legacy code base. Changes to these compilers tends to come more slowly over time.
and found it is a difficult and tedious work to find alternative ways to make my code compatible with both Clang and Visual C++.
In general, I've found that if you stick to the subset (in this case, write for Visual C++), then clang will typically support the code with no changes, provided you avoid the Microsoft language extensions. Moving the other direction is often more challenging.
Because the changes on Visual seems to take time, like in GCC. GCC almost support everything.
But also it is a question of priority. In fact GCC was full C++11 complete before CLang oficially (even if this was just because CLang was waiting for the official release date with everything ready).
Visual takes more time because they also spend energy in making the IDE better. And they have less developers.