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.
Improve this question
Unreal Engine 4 controls some runtime aspects of the application, such as having its own Garbage Collector and a unique metadata ("reflection") system.
The question is: is it correct to say UE4 makes the C++ code "managed" in the context of "managed" and "unmanaged" languages (as in C# is a managed language and C++ is an unmanaged language)?
If by "managed" you mean "managed memory" meaning "garbage collected" then C++ allows you to opt-in to that if you so wish, but by default it does not offer such a thing.
C#, like Java and many others, forces garbage collection on you, there is no way around it.
In C++ you can use things like std::shared_ptr to wrap around any objects you want to be garbage collected.
Remember that in C++ there's many ways to allocate and initialize. In situations where performance must be optimized at the expense of complexity it's not uncommon to write a custom allocator that can cut a lot of corners so long as it's used a very specific way.
So in other words C++ is "managed" if you want and how you want it to be managed. Management in C++ is a process you're an active participant in.
C++ is not a managed langue. There is C++/CLI in visual studio that's managed, but it's not really C++. Things like garbage collection can be implemented in C++ code with some work and is useful for some applications (I've had to do that). Even reflection is possible with a lot more work but it's not natively supported. Reflection does not really mean calling the compiler in your code. You can even do that in C.
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 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 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
I'm very new to software development and really loving it.
Currently, my work involves C++ programming in an OOP implementation (basically, the guys who started the framework for the software used OOP approach in everything). I jumped in and inherited what's already there.
Hobby-wise, I would like to develop a framework also for an embedded application.
Basically programming Embedded C on a microcontroller.
Is it wise to do the framework in OOP approach also?
I was thinking it is more organized.
Thanks in advance for the answers!
I would say that it depends on your microcontroller specifications (and how many resources you have).
In my experience (as Olaf says it's a subjective opinion):
OOP approach is usually clearer, avoids some mistakes for common variables and allows other person to use the framework without a painful learning process.
However... it usually require more resources as you need to encapsulate everything and that leads into more functions.
So... it depends...
It depends on your Embedded applicaton.
In some scenarios some c++ features costlier.
for e.g. run time polymorphism. .
Hope this link helps.!
http://www.embedded.com/design/programming-languages-and-tools/4424383/A-guide-to-C--for-C-programmers
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 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.