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.
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 4 years ago.
Improve this question
Today I was listening to a number of talks about dark sides of C++. One them was held by a man who was participating in the creation of the new C++ standard (Nikolai Jossutis). I'm fascinated by the many things in language, which make it easier to misuse. And for me personally it seems that C++ is actually fine if there wasn't backward comparability, which didn't allow to fix "bugs in the standard".
Hypotethically let's say I want an language dialect of C++ that is not backward compatible with the standard C++. It removes components considered dangerous, it doesn't compile something which is almost always results in UB.
I don't want to give any concrete examples, but I'm fine with everyhing which will make code safer. I already treat warnings as errors in the strictiest provided by the compiler way and use static analysis, along with ASan, etc..
UPD: I'm speaking about something very similar to C++ and it's characteristics. If I think about Java, it isn't suitable for me, because of VM. I'm asking about dialect of C++, not very different language, like Java or Rust. Rust is fine, because it compiles to native code, but I'm asking about dialect, not new language.
you could try D https://dlang.org/...
Or have a look at the Misra C++ rules https://www.perforce.com/resources/qac/misra-c-cpp, there are also code checkers available
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 8 years ago.
Improve this question
I stumbled across polymorphic engines and I don't know anything about them. However, I am curious about how they are written. Every example that I've looked up writes them in assembly, my assembly is not good at all; I know just a few instructions here and there but not that well. On the other hand, I am good in C and C++.
I am familiar with the concept of polymorphism in C++ but after reading about polymorphic engines, I am assuming that they are different from the polymorphism in C++.
How can techniques such as using virtual keyword in C++ be used to obfuscate or encrypt the code in an application?
If a program has to be modified you can go either modifying the source code or modifying the compiled executable.
The first approach is awful (in my opinion) because:
A source file is subject to a lot of optimizations in the compilation processes. So two source files slightly different from each other could produce the same object code.
If you need your program to be self modifying you will have to carry with all the tools needed to build it. (Something like carrying a candy factory with you just for the case you want a candy of a different flavor in your trip)
...
Notice that I'm talking here about compiled languages as the use of C or C++ in your question suggests. For interpreted languages the first approach is the obvious one.
In your case, the second makes more sense but it is strictly related to the machine code of the target machine.
So my point is: if you want to implement a program or routine that is able to produce a modified version of other program or a modified version of itself you can implement it in Assembly, C, C++ or any other language but in all cases you have to be proficient in your target machine's assembly language and machine code.
I recommend you to research more. This topic is broad. In the case you decide to go on, I can say that Assembly won't be the biggest dragon to beat.
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.