bool = c++?

Quote:

---

Originally Posted by zacs7

"Don't use new as an identifier you say?" Why the hell not, it's valid C -- C was around for years before C++ (people can't usually predict the future).

---

That's irrelevant. Do it in proper C++, avoid new and all will be happy. Less bugs, less mistakes.

If you seriously considered using C++/C, you can even use some C++-only elements such as access modifiers in structs, or something else, that would still keep it in the realm of C inside C++.

The thing is that we seem to love clinging to the past. C++ surpasses C is every possible way, plus the two standards seem to clash sometimes, delaying features, etc.
If everything was integrated into one standard, one language, we wouldn't have this problem. C++ can do C just as well as C. No, it may not support everything, such as reserved keywords, but then again, who cares about that? Do C++ devs cry because they can't name a variable "new"? I think not. Then I don't see why C devs can't sacrifice that and use C++/C instead.

Again, I do NOT see a point to using C besides embedded systems where C++ isn't possible. Make a small sacrifice, gain a lot.

Quote:

---

Aside from that, I could just say "don't use C when you can use C++/C," meaning stay away from the C standard altogether if you can use C++ to compile your C code.

---

Why do you recommend "C++/C" over C++? Is this "C++/C" somehow better than C++?

Quote:

---

Again, I do NOT see a point to using C besides embedded systems where C++ isn't possible.

---

I still do not understand: you claim that the only reason to use C is where a C++ compiler is not available. Consequently, "C++/C" is useless, since it is only applicable where a C++ compiler is available, and if so, there is no reason to use C, by your own statement.

Quote:

---

Originally Posted by laserlight

Why do you recommend "C++/C" over C++? Is this "C++/C" somehow better than C++?

---

The language C is still in use today and it is necessary - it has its purposes. But the C compilers are very poor due to the poor standard C itself.
Therefore, if you need to write C code, you can compile it using a C++ compiler instead of a C compiler, and you will get what I call C++/C. Essentially, C code compiled with a C++ compiler.
So when you need to compile C code (speed!), then do it in a C++ compiler and you have C++/C.
If you can do it in C++, by all means, do so. If it must be done with C code, then do it in C++/C.

Quote:

---

I still do not understand: you claim that the only reason to use C is where a C++ compiler is not available. Consequently, "C++/C" is useless, since it is only applicable where a C++ compiler is available, and if so, there is no reason to use C, by your own statement.

---

Yes, but the statement is:
"Use C++/C when possible."
Or in other words, consider the scenario:
- You are writing C code because you need the speed and the control it gives you, so C++ is not an option.
- You finish the code and need to compile it.
Now let's split that scenario.
- We are writing for an embedded system which only supports C (only has a C compiler).
- You compile using a C compiler.
Scenario 2:
- We are writing for a PC architecture. This obviously has a C++ compiler available.
- You compile using C++ to get C++/C.

If there's a better tool available, use it! That's the moral of the story.

Type-safety is a very small portion of "secure code". In nearly all cases doing stupid things (such as your int *p; int **p2 = p; example) it will be immediately obvious that the code isn't doing what it should do when it's being executed, so the only problem with this particular construct is that it's not detected by the compiler as an error during compile time (and we are assuming that the coding standard doesn't prescribe -Werror or its equivalent). Likewise for not using the appropriate prototypes - it is most often immediately obvious that the floating point number got converted to an integer. There are cases where these things are perhaps less noticeable, but any C programmer worth his/her salt should at least pay SOME attention to warnings.

C++ still allows you to use gets(), go past the end of arrays and all the other things that most often cause serious problems with code.

[1] Yes, I know, there are situations when broken code only gets executed on tuesday afternoon with an odd date, when the moon is in a waning phase and the elevator is on the 6th floor on it's way down.

--
Mats

Quote:

---

Therefore, if you need to write C code, you can compile it using a C++ compiler instead of a C compiler, and you will get what I call C++/C. Essentially, C code compiled with a C++ compiler.
So when you need to compile C code (speed!), then do it in a C++ compiler and you have C++/C.
If you can do it in C++, by all means, do so. If it must be done with C code, then do it in C++/C.

---

The language is determined by the standard, not the compiler. I repeat: "C++/C" does not exist. The code is either C, C++, or both (or neither).

If you want to recommend checking C code by compiling it as C++, by all means go ahead. But then when the C++ compiler raises a diagnostic, one has to determine if the diagnostic genuinely signals a problem, or is due to a difference between C and C++.

In other words, you have to pick a language. If you say: this is C++ code, then yes, you can get away with using C++ specific constructs even though the code is mostly in a C style. If you say: this is C code, then no, you do not get the "bool" data type for free, even though you compile the code in a C++ compiler.

Quote:

---

If there's a better tool available, use it! That's the moral of the story.

---

Programming languages are tools too. So if C++ is available, and you consider C++ to be better than C, then use C++, not C, even if you mainly use the C subset of C++. But if you insist on using C, then use C, even if you only use the common subset of C and C++.

Seriously what is C++/C?

laserlight makes a good point, "The code is either C, C++, or both (or neither)."

And C should come before C++ ;)

Knowing C++ does not mean you know C. If everyone dropped C, what about the thousands of projects already written in C? The Linux Kernel for example.

You can use a hammer to bang screws in, but wouldn't you rather use a screw-driver?

Quote:

---

Originally Posted by matsp

C++ still allows you to use gets(), go past the end of arrays and all the other things that most often cause serious problems with code.

---

That's because it's C++/C.

Quote:

---

Originally Posted by laserlight

The language is determined by the standard, not the compiler. I repeat: "C++/C" does not exist. The code is either C, C++, or both (or neither).

---

I repeat this:
C++/C is C++, BUT it is a term I use to differentiate between full C++ (classes, polymorphism, templates, generics) and typical plain C code. C++ is backwards compatible, so C code can compile within it. Therefore it isn't "full" C++, and therefore I use the term C++/C (just as some like to use the term "C+").

Quote:

---

If you want to recommend checking C code by compiling it as C++, by all means go ahead. But then when the C++ compiler raises a diagnostic, one has to determine if the diagnostic genuinely signals a problem, or is due to a difference between C and C++.

In other words, you have to pick a language. If you say: this is C++ code, then yes, you can get away with using C++ specific constructs even though the code is mostly in a C style. If you say: this is C code, then no, you do not get the "bool" data type for free, even though you compile the code in a C++ compiler.

---

This is the case why I call the code "C++/C". It is C++ code, but it is not full C++ code that takes advantage of C++, it's still mostly C. But it can still take advantages of some C++ features, so yes, it's C++, but it's still essentially C, so the term "C++/C" applies nicely I think.

Quote:

---

Programming languages are tools too. So if C++ is available, and you consider C++ to be better than C, then use C++, not C, even if you mainly use the C subset of C++. But if you insist on using C, then use C, even if you only use the common subset of C and C++.

---

So if we consider tools, reliability, security, etc, then we can categorize code as:
- C
- C++/C
- C+
- C++
In that order, it it preferable to go from the top to the bottom (C++ and down), and choose the right tool for the job.
If you choose C, then you must compile using a C compiler, because C++ can only compile C++/C.

I do hope that makes sense.

Quote:

---

Originally Posted by zacs7

Knowing C++ does not mean you know C. If everyone dropped C, what about the thousands of projects already written in C? The Linux Kernel for example.
You can use a hammer to bang screws in, but wouldn't you rather use a screw-driver?

---

Not suggesting anyone should drop it, just prefer writing C++/C instead of C when/if possible, because it's more reliable and secure.

Quote:

---

C++/C is C++, BUT it is a term I use to differentiate between full C++ (classes, polymorphism, templates, generics) and typical plain C code. C++ is backwards compatible, so C code can compile within it. Therefore it isn't "full" C++, and therefore I use the term C++/C (just as some like to use the term "C+").

---

Excellent. Therefore, do not suggest C++/C in the C programming forum, or your suggestion shall be edited out or deleted.

*thread closed*

EDIT:
Sorry, technical mistake: suggesting a switch to another language, including C++ (and consequently "C++/C"), is acceptable. What I meant is that giving non-C code examples and help in the C programming forum is not as it would be off topic.