Hot answers tagged

262

No. This is woefully and terribly misguided. Java features are not somehow better than C++ features, especially in a vacuum. If your programmers don't know how to use a feature, train or hire better developers; limiting your developers to the worst of your team is a quick and easy way to lose your good developers. YAGNI. Solve your actual problem today, ...


117

Just because the syntax seems similar on the surface doesn't mean that the two languages are compatible. 1, 4 and 5 are really the same question: Now, I'm no fan of C++, but saying "Code without C++ specific features is usually more maintainable" is just ridiculous - do you really believe that Java got everything right, and took all the good features while ...


73

I will answer your questions in order. If Java doesn't provide a feature that C++ has, it means that the feature is not good, so we should prevent using it. Yes, any feature not present in Java is anathema on the hard drive. It must be burned from your code base. Those who do not obey will be scrounged, their souls used to placate the RAID gods. C++ ...


60

Because the standard writers don't want to actually assert an implementation. They want to define what it does, but not necessarily how it does it. So, for example, if you look at the GNU C++ version of find_if, you will see that the implementation is slightly different from what you give, which is based on the C++ standard: template<typename ...


54

I'm just gonna answer your reasons: I don't understand how you come to that conclusion. Different languages have different features. Depends on scope, architecture of language, sometimes preferences of creators and many more reasons. Some features of a language may be bad, but your generalization is plain wrong IMHO. Writing C++ just like Java may lead to ...


26

Java has features that C++ doesn't, like a built-in, fast, reliable garbage collector, a single-root object hierarchy, and powerful introspection. Java's other features are designed to work together with the Java-exclusive features, and many of Java's omissions of C++ features are possible because the new features make up for the lack. For example, Java ...


26

The main reason for not letting exceptions escape from main is because otherwise you lose all possibility to control how the problem gets reported to your users. For a program that is not intended to be used a long time or distributed widely, it can be acceptable that unexpected errors are reported in whatever way the OS decides to do it (for example, ...


25

I've debated whether to bother posting another answer when you already have a number that reach what seem to be entirely reasonable conclusions: that your idea is basically a disaster waiting to happen. I think, however, they've failed to point out some highly relevant reasons behind that conclusion. The differences between Java and C++ run much deeper than ...


20

One problem with letting exceptions go past main is that the program will end with a call to std::terminate which default behavior is to call std::abort. It is only implementation defined if stack unwinding is done before calling terminate so your program can end without calling a single destructor! If you have some resource that really needed to be restored ...


20

I have a question regarding the use of exceptions at the highest level of a program. I have seen programs using this strategy and I have also seen posts considering this bad practice. However, the posts considering this bad practice have been written in c# or some other programming language, where there are some error handling built in. ...


10

volatile means two things: The value of the variable may change without any code of yours changing it. Therefore whenever the compiler reads the value of the variable, it may not assume that it is the same as the last time it was read, or that it is the same as the last value stored, but it must be read again. The act of storing a value to a volatile ...


10

If you're going to write code in language X, spend the time to properly learn the language and use all the features it offers to help you solve the problem. Bad things happen when you try to do a "word for word" translation from one language to another, whether that's Japanese to English or Java to C++. It's far better to start with a good understanding of ...


9

TL;DR: What does the specification say? A technical detour... When an exception is thrown and no handler is ready for it: it is implementation defined whether the stack is unwound or not std::terminate is called, which by default aborts depending on your environment setup, aborting may or may not leave a crash report behind The latter can be useful ...


8

volatile means some other processor or I/O device or something can change the variable out from under you. With an ordinary variable, your program's steps are the only thing that will change it. So for instance if you read 5 from a variable and you don't change it, it'll still contain 5. Since you can rely on that, your program doesn't have to take the time ...


7

That's not how pointers work. A pointer is, essentially, a record of a memory address. If dereferenced, you can read (or write) the value that lives at that address. Pointers can point to anything that lives in memory. In particular, they can point to other pointers. They can even point themselves (although that is pretty useless). However, the action of ...


7

Why doesn't the compiler understand I want the result to be a decimal number? The C++ compiler is simply following well-defined and deterministic rules as set forth in the C++ standard. The C++ standard has these rules because the standards committee decided to make it that way. They could have written the standard to say that integer math results in ...


6

All of your reasons can be disproved: If Java doesn't provide a feature that C++ has, it means that the feature is not good, so we should prevent using it. It doesn't mean the the feature is not good (no feature can be inherently bad). It only means that the feature was frequently misused (or impossible to implement due to fundamental concepts, like ...


6

Clearly in your main () function you don't have a chance to handle the exception in any meaningful way. If an exception reaches main (), all you know is that something went badly wrong. You can of course decide how you want to handle the situation that "something went badly wrong". That's not at all a bad practice. You may of course decide that you handle ...


6

No, you should definetely not abandom namespaces! Instead, you should organize your code better, and maybe check your architecture again. First, you should not use using namespace MyLibrary::MyModule1; or using MyLibrary::MyModule1::MyClass1; in a header, to avoid namespace polution, since there is no way to undo that (see this question and answers). ...


5

This is due to the evolution of hardware. Back in the early days of computers, not all machines had a floating point unit, the hardware was simply not able to understand the notion of a floating point number. Of course, floating point numbers can be implemented as a software abstraction, but that has significant downsides. All of the arithmetic on these ...


5

For this answer, I'll assume that the C++ code is ONLY well-tested and perfect security wise. If if would be actually be perfect then you wouldn't have asked this question anyways... This is a general compilation of the first things that came to my head, not a complete list. technical disadvantages of using C++: (or basically any external language addon) ...


5

What about creating a class to hold your arguments? This class would contain both open and close parameters and either of them could be NULL. Then, there will be only one strip method with above class as argument and method will decide if it wants to use open/close if they are set.


4

There are many options, it's your tradeoff which to take: Decision at runtime: Add a defaulted bool argument: QString MyClass::strip(QRegularExpression regex, bool close=false); // Mimic the two-regex-variants interface as good as possible Use scoped enum's and no default as a variant on 1 which is more descriptive: enum class option { open, close }; ...


4

The function in your example looks quite complex, and it may be better to move it to the header, for the purpose of unit testing. what's the point of putting functions and constants into the anonymous namespace, if it makes them unusable in tests? To make them isolated from rest of the world. And it is not only functions and constants that you can put ...


4

Assuming I have a parent class and a child class, with no virtual functions, and I have a parent-class-pointer to a child object Then you are using it polymorphically. Though I don't see much point in doing that. Without virtual members, the subclass does not have much opportunity to affect the program behaviour compared to using just the base class. ...


4

Suppose I am limited to use C++ by the environment in the project. Is it good to prevent the use of some language features that C++ has but Java doesn't have (e.g.: multiple inheritance, operator overriding)? No. If "by the environment of the project" you are limited to using C++, then there is little, if any, point in even thinking about any other ...


4

No, you should generally not write C++ like it was Java, and you should definitely not omit C++ language features that aren't present in Java. For one thing, Java is garbage collected, and thus has no equivalent of the C++ "delete" keyword. Okay, so you implement a program without delete, because per your rules, it's not allowed. Congratulations, you now ...


4

Your scope guard has interesting behaviour, and a quick code review could find various issues or possible issues (using the macro takes more code than not using the macro; your macro is flawed because it is a macro and is unnecessary; the gensym macro can't be used two times on the same line, which could happen in macros; many types are not ...


4

The moment you know you have to abort, go ahead and call std::terminate already to curtail any further damage. If you know you can wind down safely, do that instead. Remember that stack-unwinding is not guaranteed when an exception is never caught, so catch and rethrow. If you can safely report/log the error better than the system will do it on its own, go ...



Only top voted, non community-wiki answers of a minimum length are eligible