Skip to main content

Timeline for Should I stop using the term C/C++?

Current License: CC BY-SA 3.0

22 events
when toggle format what by license comment
Jun 16, 2020 at 10:01 history edited CommunityBot
Commonmark migration
Oct 27, 2015 at 21:42 audit First posts
Oct 27, 2015 at 21:43
Oct 2, 2015 at 22:19 comment added supercat @cmaster: For situations where the thing being assigned is a simple variable, using that as the sizeof argument is fine, but if it's being assigned to myArray[i*16+j], foo->data, etc. duplicating the target lvalue can be irksome. Further, the fact that C has two good ways of writing malloc() which are pretty well equivalent and C++ only likes one of them doesn't violate Stroustrup's claim nearly as strongly as does the C++ inability (so far as I can tell) to declare enums that support the standard pre-defined arithmetic operators.
Oct 2, 2015 at 21:28 comment added cmaster - reinstate monica @supercat One more note on the malloc() call: The possibility of type mismatch is the reason why I used *bar (i. e. the dereferenced pointer that is being allocated) in the sizeof() expression instead of the plain type. This assures that the type of which the size is taken matches the type of the pointer, making the malloc() call almost as safe as the corresponding new statement. Unfortunately, one sees a lot of the inferior malloc(sizeof(someType)) in real code, though.
Oct 2, 2015 at 19:38 comment added supercat ...there are many cases where it makes sense for well-written C code to perform arithmetic on "enum" types [e.g. one might have many cases in a switch statement increment the state variable] but I don't know any way to declare a variable in C++ such that a debugger will regard it as an enumerated type and show its value symbolically, but it can be operated on without typecasts as though it were an integer type.
Oct 2, 2015 at 19:34 comment added supercat @cmaster: I think Stroustrup's claim was made before C99 added VLAs, and I favor someVar = (someType*)malloc(sizeof (someType)); since (1) the typecast will not prevent any decent compiler from squawking if no prototype for "malloc" is in scope, and (2) if someVar is a pointer to the wrong type, the above code will squawk. Without the typecast, it would compile but likely fail if the types are different sizes; further, even if the types are the same size now, changing the size of either type would make the code break. On the other hand...
Oct 2, 2015 at 18:38 comment added cmaster - reinstate monica Nice, balanced answer. However, I would disagree with Stroustrups assertion that "well written C tends to be legal C++ also". If only for ubiquitous Foo* bar = malloc(sizeof(*bar)); in a well written C-program (note that there is no cast, which would be required in C++, but which is contraproductive in C). Use of true VLA support in C is another point where well written C is most certainly not valid C++.
Oct 2, 2015 at 8:56 comment added BЈовић @R.M. I can live with that, as I never programed in C, except in high school ;)
Oct 1, 2015 at 19:11 history edited Ben CC BY-SA 3.0
added 917 characters in body
Oct 1, 2015 at 16:25 comment added R.M. @BЈовић If you're one to be pedantic about terminology, you should be aware that C is not "functional", but rather "procedural" -- a difference you may wish to understand before you sling accusations of incompetence at others.
Oct 1, 2015 at 15:22 comment added Ben @BЈовић Perhaps you did not understand what I wrote. Why don't you look here to see how in every case it is possible to adapt a C program so that it also compiles as C++. david.tribble.com/text/cdiffs.htm#C99-vs-CPP9
Oct 1, 2015 at 15:02 comment added BЈовић @Ben "almost"? "just not quite"? You claimed above that there is a such nonsense as "C/C++". Look at examples in the accepted answer - there are more. The fact that c++ provides classes, templates, exceptions, standard library and rest of things, makes it quite different from C.
Oct 1, 2015 at 14:15 comment added Ben @BЈовић You are making no sense. They are not "completely different". C++ is a much larger language than C, but it includes almost all of C within it. There are incompatibilities which prevent C++ being a proper superset but they are small, like additional reserved words, a few more casts become necessary, but that is pretty much it. It is almost a proper superset, just not quite.
Oct 1, 2015 at 14:08 comment added BЈовић @Ben People who are creating "C/C++" libraries tend to put various c++ keywords in headers (class, protected, new, ... ), making then C only. If you look at the languages, they are completely different : one is functional, other object oriented with functions. And yet there are incometent people who think they can use both in one program, although that is not possible. Now, is it play with words? No, it is not. Those people really think that the language is C/C++. Would you call OpenGL a C/C++/Python library?
Oct 1, 2015 at 13:53 comment added Ben @el.pescado Yes. You will find that people do in fact refer to PHP/JavaScript. Why not? The point is to be understood, not to play games with words.
Oct 1, 2015 at 13:53 comment added Ben @TheodorosChatzigiannakis C and C# do not have a subset which is a complete language. One cannot write a program which compiles both as C# and as C without using conditional compilation. With C and C++ you have all the functionality of C available if you add a few casts and ensure you declare function signatures and things like that.
Oct 1, 2015 at 13:46 comment added Ben @BЈовић They disagree with you about the acceptability of a small piece of terminology so you conclude they don't understand the difference and are incompetent. That's a pretty unreasonable thing to say.
Oct 1, 2015 at 13:21 comment added el.pescado - нет войне Regarding first paragraph, what about web applications? Can we call them e.g. Python/JavaScript?
Oct 1, 2015 at 13:06 comment added Theodoros Chatzigiannakis It's true that C and C++ share a common subset. But then, again, so do C and C#, C++ and C#, C and Java, and so on.
Oct 1, 2015 at 12:05 comment added BЈовић This answer is so wrong. It is either C or C++, but it can't be both. People who say "C/C++" are people who do not understand the difference, and who are incompetent in both.
Oct 1, 2015 at 10:13 history edited Ben CC BY-SA 3.0
added 143 characters in body
Oct 1, 2015 at 10:07 history answered Ben CC BY-SA 3.0