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
This question was brought to me because I was watching this talk
A large part of the second half of the talk is spent kinda going back and fourth about exception vs non exception handling in c++.
I am working mainly with c but I would like to get some experienced programmers help understanding this.
I haven't written any code that really did anything with exceptions, I have done java code and that basically forces you to add try/ catch blocks etc.
When he says exception handling vs non exception handling does that mean the way java almost forces you to add those blocks around any unsafe code while in c basically if you don't remember to do it your app will just crash?
You have to take into consideration that exceptions are usually constructs of Object Oriented programming - That's why Java, C#, C++, etc. often talk about exceptions and try/catch blocks.
In C, this isn't the case. Usually errors need to be caught by the programmer by ways of return values (The C standard uses the errno to keep track of any errors values returned by certain functions).
If something goes really wrong, C will either crash or have an unexpected behaviour - This is where exceptions come in. They are fancier constructs to determine where, how, and why something went wrong.
There is no way of making exceptions in C, but something similar could be done with POSIX signals - though not recommended unless you really know what you are doing. Preferably, use return values to determine when someone goes wrong/right.
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.
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.
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 2 years ago.
Improve this question
I asked a question about this topic and people say that there is something wrong with my university for teaching me these ancient library. Is it really true and what should I be using instead? Sorry I am still quite new I am in the first year.
Raw C strings are responsible for a significant percentage of security flaws in real world software.
Properly handling buffers is hard, and getting it wrong is depressingly common. There is a use for low level raw memory buffer manipulation of strings, but teaching it first is questionable.
One way of teaching C++ is to teach it as C, then add on some C++ features. Another is to teach it first as C++, and then add on the C compatible sub dialect.
The criticism you are hearing is objecting to the teach C then C++ option.
Learning how to program in C is great; trying to learn both C and C++ at the same time makes you a bad C and bad C++ programmer.
When C++ was first invented, this was a reasonable way to do it. There were C experts but no C++ experts. It has been a few decades since then, and best practices in C++ are no longer that similar to best practices in C, and vice versa.
Knowing what they do is useful since you may encounter ancient code that uses them.
But no, there is no need to use them in modern C++. By modern, I mean something that is being written now or has been written during this millennium.
One of the functions you mentioned, std::strlen is fairly OK to use. Technically you dont need it, but neither is it terribly bad to use.
what should I be using instead?
Most of the time: std::string and std::string_view and their member functions.
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 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 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
the idea I have about using exceptions and try {} catch {} blocks is that those are used for error handling.
I was reading Bjarne's Strostrup FAQ page section about exceptions and I came across this
There are other uses of exceptions - popular in other languages - but
not idiomatic in C++ and deliberately not supported well by C++
implementations (those implementations are optimized based on the
assumption that exceptions are used for error handling).
What are other usages for exceptions in other languages (C# or java for example)?
In Python, in the spirit of "ask for forgiveness, not permission", exceptions are frequently used as part as the normal control flow of the application. For instance, when looking up an element in a dictionary (think std::unordered_map in C++):
try:
my_value = my_dict["the answer to life, the universe and everything"]
except KeyError:
my_value = 42
In C++, this is not considered an "erroneous" situation; exceptions should only be used in interaction with "unpredictable" things like hardware devices and (to some degree) the operating system.
One other use is InterrutedException in java. It allows waiting on monitors or sleeping threads step out of wait or sleep.