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, ...
C predates many of the other languages you're thinking of. A lot of what we now know about how to make programming "safer" comes from experience with languages like C.
Many of the safer languages that have come out since C rely on a larger runtime, a more complicated feature set and/or a virtual machine to achieve their goals. As a result, C has remained ...
Coding style is ultimately subjective, and it is highly unlikely that substantial performance benefits will come from it. But here's what I would say that you gain from liberal use of uniform initialization:
Minimizes Redundant Typenames
Consider the following:
return vec3(x, y, z);
Why do I need to type vec3 twice? Is there a point ...
Exceptions do not contain useful details because the concept of exceptions has not matured yet enough within the software engineering discipline, so many programmers do not understand them fully, and therefore they do not treat them properly.
Yes, IndexOutOfRangeException should contain the precise index that was out of range, as well as the range that was ...
It's all about the memory (not the JIT). The JIT 'advantage over C' is mostly limited to optimizing out virtual or non-virtual calls through inlining, something that the CPU BTB is already working hard to do.
In modern machines, accessing RAM is really slow (compared to anything the CPU does), which means applications that use the caches as much as ...
My coworkers says that you should always know what exceptions are to be thrown [...]
Your coworker, I'd hate to say it, has obviously never worked on general-purpose libraries.
How in the world can a class like std::vector even pretend to know what the copy constructors will throw, while still guaranteeing exception safety?
If you always knew what the ...
The default choice for a floating-point type should be double. This is also the type that you get with floating-point literals without a suffix or (in C) standard functions that operate on floating point numbers (e.g. exp, sin, etc.).
float should only be used if you need to operate on a lot of floating-point numbers (think in the order of thousands or more)...
You pick C when
you need portable assembler (which is what C is, really) for whatever reason,
your platform doesn't provide C++ (a C compiler is much easier to implement),
you need to interact with other languages that can only interact with C (usually the lowest common denominator on any platform) and your code consists of little more than the interface,...
Metaprogramming is OK. What you are trying to do is not OK.
I use metaprogramming all the time in my job. It's a powerful tool which can be used to do a lot of things in a more readable and maintainable way. It's also one of the harder to comprehend styles of programming out there, so it really needs to earn its keep. I like it when I can reduce 1000 ...
C was never a subset of C++. The most obvious example of this is int new;. This has been true since C89 and C++98, and the languages have only grown further from each other as new standards have come out.
Should I stop using the term C/C++
If the answer to #1 is yes, how would I call a program that use a mix of C and C++?
A source file is ...
Readability is a valid reason to learn to use whitespace:
const MyObject& obj,
const string& s1,
const string& s2,
const string& s3
Located over there the parameters won't get confused with the body of the function. By locating them on a different line you won't ...
There needs to be some way of telling where the condition ends and the branch begins. There are many different ways of doing that.
In some languages, there are no conditionals at all, e.g. in Smalltalk, Self, Newspeak, Io, Ioke, Seph, and Fancy. Conditional branching is simply implemented as a normal method like any other method. The method is implemented ...
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 ...
All answers so far have focused on the topic of your question as stated, which is "what is the difference between c and c++". In reality, it sounds like you know what difference is, you just don't understand why you would need that difference. So then, other answers attempted to explain OO and encapsulation.
I wanted to chime in with yet another answer, ...
final expresses intent. It tells the user of a class, method or variable "This element is not supposed to change, and if you want to change it, you haven't understood the existing design."
This is important because program architecture would be really, really hard if you had to anticipate that every class and every method you ever write might be changed to ...
Employ the least astonishment principle.
Is it you and only ever you who is going to use this code, and are you sure the same you in 3 years is not going to be surprised by what you do?
Then go ahead.
In all other cases, use the standard way; otherwise, you and your colleagues are going to run into hard to find bugs.
For example, my colleague was ...
On a home page of a Google-scale website, it is not acceptable. Keep the things as quick as possible.
In a part of an application which is used by one person once a year, it is perfectly acceptable to sacrifice performance in order to gain code readability.
In general, what are the non-functional requirements for the part of the code you're working ...
Hand rolled C/C++ done by an expert with unlimited time is going to be at least as fast or faster than Java. Ultimately, Java itself is written in C/C++ so you can of course do everything Java does if you are willing to put in enough engineering effort.
In practice however, Java often executes very fast for the following reasons:
JIT compilation - although ...
It's a case-by-case situation.
It sometimes makes code harder to understand, sometimes not. Take, for instance:
void foo(const std::map<int, std::string>& x)
for ( auto it = x.begin() ; it != x.end() ; it++ )
is definitely easy to understand and definitely easier to write than the actual iterator declaration.
If you felt compelled to expand a one liner like
a = F(G1(H1(b1), H2(b2)), G2(c1));
I wouldn't blame you. That's not only hard to read, it's hard to debug.
Some debuggers will only highlight the whole thing at once
It's free of descriptive names
If you expand it with intermediate results you get
var result_h1 = H1(b1);
var result_h2 ...
This is a stone-cold classic X-Y problem.
Your real problem is performance issues. However your question makes it clear that you've done no profiling or other evaluations of where the performance issues actually come from. Instead you're hoping that splitting your code into DLLs will magically solve the problem (which it won't, for the record), and now you'...
Strangely, the history of C-style programming language doesn’t start with C.
Dennis Ritchie explains well the challenges of C’s birth in this article.
When reading it, it becomes obvious that C inherited a part of its language design from its predecessor BCPL, and especially the operators. The section “Neonatal C” of the aforementioned article explains how ...
First, most JVMs include a compiler, so "interpreted bytecode" is actually pretty rare (at least in benchmark code -- it's not quite as rare in real life, where your code is usually more than a few trivial loops that get repeated extremely often).
Second, a fair number of the benchmarks involved appear to be quite biased (whether by intent or incompetence, ...
Variables (or more generally: “objects” in the sense of C) do not store their type at runtime. As far as machine code is concerned, there is only untyped memory. Instead, the operations on this data interpret the data as a specific type (e.g. as a float or as a pointer). The types are only used by the compiler.
For example, we might have a struct or class ...
Basically because the designers of Java and similar languages didn't want undefined behavior in their language. This was a trade off - allowing undefined behavior has the potential to improve performance, but the language designers prioritized safety and predictability higher.
For example, if you allocate an array in C, the data is undefined. In Java, all ...
Short answer: More completely, my current opinion on auto is that you should use auto by default unless you explicitly want a conversion. (Slightly more precisely, "... unless you want to explicitly commit to a type, which nearly always is because you want a conversion.")
Longer answer and rationale:
Write an explicit type (rather than auto) only when you ...