C vs C++

Please compose all posts in Emacs.

Moderators: phlip, Moderators General, Prelates

Which one?

C
15
36%
C++
27
64%
 
Total votes: 42

User avatar
chasesan
Posts: 6
Joined: Thu Oct 13, 2011 3:53 pm UTC
Location: Walking the orbits of electrons.

C vs C++

Postby chasesan » Tue Apr 15, 2014 9:29 am UTC

There was no "C vs C++" thread. Despite being a classic debate.

I am personally a C guy. I generally got sick of C++ at one point. It took me some heavy thinking to figure out why.

I realized that if you write C++ code, you are expected to write C++ code. That means templates, classes, inheritance, new and new[], public/private members and fields, the diamond, STL, C++ Streams (the horror), name mangling, special cast operations, and figuring out what that operator they overloaded actually does. You really don't need all that to write a good program. In fact I found much of it rather harmful to my productivity.

Sure, program structure is a bit different without language level OOP. But you can do pretty much anything you can do in C++.

The only thing I wish standard C had, that it doesn't, is anonymous functions. I like Clang's implementation of them, but that is a holy war in and of itself.

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Tue Apr 15, 2014 10:25 am UTC

All Turing-complete languages can do the same. Brainfuck can do everything that C++ can do, too. That doesn't make them equally good. What really matters when comparing programming languages is the expressive power.

C++ offers much more powerful tools to separate concerns, to check types and to not repeat yourself than C. It does so using features that can be abused. I think the solution to the latter problem is "don't do that".

If you're such a fan of printf et al, C++11 actually makes it trivially easy to wrap those in a type-safe and memory-safe interface using variadic templates.

Generic programming in C++ is a more important improvement over C than OOP.

C does have one advantage over C++: it has a smaller standard library. But that's a bleak advantage, in most cases it isn't important.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: C vs C++

Postby EvanED » Tue Apr 15, 2014 12:49 pm UTC

There are situations in which I would use more or fewer C++ features (e.g. disable exceptions in the core of an OS kernel, or embedded code), but there is absolutely no situation in which I would freely choose to use C over C++. The ability to do RAII alone is enough to seal that deal.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: C vs C++

Postby ahammel » Tue Apr 15, 2014 2:25 pm UTC

They both strike me as having rather narrow applications, to be honest.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Tue Apr 15, 2014 2:30 pm UTC

Seriously? What languages have wider applications?
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: C vs C++

Postby ahammel » Tue Apr 15, 2014 2:40 pm UTC

Well obviously in practice they're both extremely widely used. What I meant was that C++ strikes me as being slightly weird because on the one hand it's high level enough to have concepts like protected pure virtual static friends and a functional programming library and on the other hand it's low level enough that you could just about compile it to assembly with pen and paper and you can do ridiculously evil pointer hacking if you really want to. It seems like a weird combination of language features to me.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6282
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: C vs C++

Postby Thesh » Wed Apr 16, 2014 12:02 am UTC

I can't imagine willingly doing something in C++, unless I am writing a library specifically to target C++. C I use all the time for various small projects, just because it's so simple and fast compared to something like Python or C#.
Summum ius, summa iniuria.

Great Justice
Posts: 54
Joined: Sun Aug 15, 2010 5:28 am UTC

Re: C vs C++

Postby Great Justice » Wed Apr 16, 2014 5:06 am UTC

ahammel wrote:It seems like a weird combination of language features to me.

I still don't see what you're on about.
Doing whatever you want in the way you want to do it == "narrow application" ??

I'd say the opposite is the case:
a language which forces you to use one sacred paradigm is a tutor language which will lead to forcing octagonal pegs into triangular holes.

C++11 and clang really got me enthused about hacking again.
It usually isn't Congress or the State that tries to abridge free expression or free speech, [...] actually, in the present situation, the main threat to expression comes from public opinion.
~Christopher Hitchens

User avatar
Xenomortis
Not actually a special flower.
Posts: 1422
Joined: Thu Oct 11, 2012 8:47 am UTC

Re: C vs C++

Postby Xenomortis » Wed Apr 16, 2014 9:52 am UTC

C++
Classes are useful.
RAII is useful.
Image

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: C vs C++

Postby ahammel » Wed Apr 16, 2014 1:47 pm UTC

Great Justice wrote:
ahammel wrote:It seems like a weird combination of language features to me.

I still don't see what you're on about.
Doing whatever you want in the way you want to do it == "narrow application" ??
Yeah, that was not the most clear way of putting it.

C++ gives you lots of low-level-ness and high-level-ness, but I don't come across very many situations where I need both of those things. And I think that if you don't need both, you'd probably be better served by a tool that only does one or the other.
He/Him/His/Alex
God damn these electric sex pants!

Nyktos
Posts: 138
Joined: Mon Mar 02, 2009 4:02 pm UTC

Re: C vs C++

Postby Nyktos » Wed Apr 16, 2014 6:06 pm UTC

Given the choice between the two I'd pick C, because C++ is terrifying and insane. Some of that insanity serves a purpose, for sure, but I can get the useful parts that in a language that I may actually hope to understand some day.

There are C++ features I'd like to have in C, for sure, but despite C++ people often claiming "you can use it like C with some extra stuff" as an advantage, everyone seems to look down on code that's actually written that way.

User avatar
Flumble
Yes Man
Posts: 2073
Joined: Sun Aug 05, 2012 9:35 pm UTC

Re: C vs C++

Postby Flumble » Wed Apr 16, 2014 7:32 pm UTC

I'm inclined to vote for C++ because of the generic methods it allows you to use, as Jplus has said. On the other hand I'm not sure whether this leads to better or worse management for big projects and the true masters of generic programming are languages like Haskell.

Nyktos wrote:There are C++ features I'd like to have in C, for sure, but despite C++ people often claiming "you can use it like C with some extra stuff" as an advantage, everyone seems to look down on code that's actually written that way.

Sure there are people looking down on you coding style, no matter which it is.
I, for one, will not condemn you for writing C with a dash of C++ STL. :) That's partly due to the fact that I've never seen (let alone worked on) a large C project, so I don't know what C libraries you "should" use instead of C++.

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Wed Apr 16, 2014 10:20 pm UTC

ahammel wrote:C++ gives you lots of low-level-ness and high-level-ness, but I don't come across very many situations where I need both of those things. And I think that if you don't need both, you'd probably be better served by a tool that only does one or the other.

The entire STL is a great example of a combined use case for both. It's generic and at the same time terribly efficient thanks to the use of pointers under the hood. Since the STL can be used anywhere data need to be stored or manipulated, I think this shows that having both at the same time has a value.

(This distinction is false anyhow. Pointers are "low-level" in the sense of being close to what's going on at hardware level. Classes and templates are "high-level" in the sense of conceptual abstraction, but both actually have pretty direct interpretations at hardware level. So in terms of hardware abstraction C++ is entirely low-level while in terms of conceptual abstraction it goes very far up.)

Nyktos wrote:There are C++ features I'd like to have in C, for sure, but despite C++ people often claiming "you can use it like C with some extra stuff" as an advantage, everyone seems to look down on code that's actually written that way.

You can "use C++ like C and take benefit from the additional features in C++". Sure. But that's just programming in C++.

Suppose you are writing new code and you're telling people "I'm using C++ like C with some extra stuff". This means that you can choose, among other things, between malloc and new. Is it really that strange if people snort at this

Code: Select all

int * some_bare_array = (int*) malloc (1000 * sizeof(int));

when the following is freely available to you?

Code: Select all

int * some_bare_array = new int[1000];  // can be fine
auto some_smart_array = vector<int>();  // often better

Or are you actually afraid that somebody will snort at you because you happen to not have any use for exceptions/classes/operator overloading/namespaces in your code? Because screw such whiners.

Flumble wrote:I'm inclined to vote for C++ because of the generic methods it allows you to use, as Jplus has said. On the other hand I'm not sure whether this leads to better or worse management for big projects and the true masters of generic programming are languages like Haskell.

Given that generic programming helps you to not repeat yourself, how can it not help to manage big projects?

Also, Haskell and Ocaml are actually strictly less powerful in terms of generic programming since C++11 got variadic templates. C++11 allows efficient, generic, concise implementation of tuples in a library, in Haskell et al they have to be provided as a builtin type. Those languages do have other strengths compared to C++, though.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

Derek
Posts: 2179
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: C vs C++

Postby Derek » Thu Apr 17, 2014 2:03 am UTC

Unfortunately for C++ the syntax for templates is bad and the compiler errors are even worse. This definitely puts a damper on getting too template-happy.

If you had asked me two years ago I probably would have answered C, but having seen from my job that C++ can be used very well, producing very clean and readable code while still being efficient, I'll vote C++. There are definitely parts of the language that you should stay away from unless absolutely necessary though. And the decision to overload the shift operators for streams is still inexcusable.

User avatar
Xenomortis
Not actually a special flower.
Posts: 1422
Joined: Thu Oct 11, 2012 8:47 am UTC

Re: C vs C++

Postby Xenomortis » Thu Apr 17, 2014 9:27 am UTC

Derek wrote:And the decision to overload the shift operators for streams is still inexcusable.

I've heard the complaint before.
So what should Stroustup have picked instead?

Honestly, my biggest complaint from C++ (as someone who is still very much in the "learning beginner" stage) is that it is far too easy to start doing the dangerous thing over the idiomatic and safer thing.
It's so much easier to create raw pointers, use new [], etc than it is to use smart pointers, instantiate STL containers and RAII.

I get it, we don't want to lose these things in C++, but I feel as though the language has these things inverted.
Image

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Thu Apr 17, 2014 12:57 pm UTC

Xenomortis wrote:I get it, we don't want to lose these things in C++, but I feel as though the language has these things inverted.

Actually I agree on this point. Not that I would want C++ to offer std::vector as a builtin or anything like that, but it does feel sort of upside-down to have to #include at least five STL headers to do the idiomatic thing while the stuff that is only meant for library implementers is available out of the box.

I think the blame is also partly on the tutorials, though. I don't really understand why pointers and raw arrays need to be among the first things that a C++ rookie learns about. I think the tutorials should start with pass-by-(value|reference|const reference|rvalue reference) and the STL. And then specializing std::swap, using std::swap in the implementation of the assignment operator, etc. I learnt about those things only several years after I started programming in C++ (well except for argument passing semantics).
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: C vs C++

Postby EvanED » Thu Apr 17, 2014 1:59 pm UTC

Derek wrote:And the decision to overload the shift operators for streams is still inexcusable.
I never even really understood what the objection was in the first place about << and >> for streams. It's not like, say, vector multiplication where a * b could legitimately mean a couple different things and so there's confusion.

Using the syntax that was available at the time, overloading an operator was by far the best choice for creating an IO library; it arguably still is. Short of creating new operators, << and >> were very reasonable choices I think, and I think I can count the number of times when I've been confused between stream insertion vs bit shifting on zero hands.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: C vs C++

Postby ahammel » Thu Apr 17, 2014 2:02 pm UTC

Jplus wrote:I think the blame is also partly on the tutorials, though. I don't really understand why pointers and raw arrays need to be among the first things that a C++ rookie learns about.

Sort of like how when you're learning to drive the first thing they teach you is how to jump a motorcycle over ten busses that are exploding.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Thu Apr 17, 2014 3:44 pm UTC

EvanED wrote:
Derek wrote:And the decision to overload the shift operators for streams is still inexcusable.
I never even really understood what the objection was in the first place about << and >> for streams. It's not like, say, vector multiplication where a * b could legitimately mean a couple different things and so there's confusion.

Using the syntax that was available at the time, overloading an operator was by far the best choice for creating an IO library; it arguably still is. Short of creating new operators, << and >> were very reasonable choices I think, and I think I can count the number of times when I've been confused between stream insertion vs bit shifting on zero hands.

I've long held this opinion and I still kind of agree to it, but lately (since variadic templates joined the show) I'm starting to think the type-safe memory-safe printf family variant might actually be better. At the very least it would remove a lot of OO overhead and if I'm right it would even allow us to reduce the size of the C++ stdlib. AFAICT all the nice I/O iterators etcetera would still be perfectly possible. I'm thinking of I/O prototypes like the following:

Code: Select all

template <class... Args>
void print (std::file target = std::cout, const Args &... args, separator = "", end = "\n");

template <class... Args>
void format (std::string fmt_str, const Args &... args);  // type-safe and memory-safe

template <class... Args>
void scan (std::file source = std::cin, Args &... args);

// and so on


ahammel wrote:
Jplus wrote:I think the blame is also partly on the tutorials, though. I don't really understand why pointers and raw arrays need to be among the first things that a C++ rookie learns about.

Sort of like how when you're learning to drive the first thing they teach you is how to jump a motorcycle over ten busses that are exploding.

Exactly.

I'm glad to learn other people had such adventurous driving lessons too.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
chasesan
Posts: 6
Joined: Thu Oct 13, 2011 3:53 pm UTC
Location: Walking the orbits of electrons.

Re: C vs C++

Postby chasesan » Thu Apr 17, 2014 5:12 pm UTC

I am a little behind on the posts, but using a vector in place of a raw array because its "often better" is just the problem with many C++ programs. If you only have 20 elements and you will only ever have 20 elements, the you really shouldn't be using a vector. Except many programs do anyways.

I know they implemented the array class in C++11, but the point is that all the extra features of C++ means people use them when they really shouldn't, because it is expected you will use them.

Which brings me back to "that if you write C++ code, you are expected to write C++ code..." even when you really shouldn't.

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6282
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: C vs C++

Postby Thesh » Thu Apr 17, 2014 5:29 pm UTC

Honestly, I don't think there is a good reason to ever use an array type that doesn't do bounds checking, and this includes raw pointers. The problem with C++ is every single feature it adds is literally an afterthought. Vectors and Arrays could be replaced by a simple native type without the wordy syntax in any other language.

Code: Select all

int a[10]; //fixed array
int[] b; //dynamic array
Summum ius, summa iniuria.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: C vs C++

Postby EvanED » Thu Apr 17, 2014 5:33 pm UTC

Thesh sort of won but I'll post too. :-)

chasesan wrote:I am a little behind on the posts, but using a vector in place of a raw array because its "often better" is just the problem with many C++ programs. If you only have 20 elements and you will only ever have 20 elements, the you really shouldn't be using a vector.
I semi-disagree with this. I strongly believe you should be using something that supports at least debug-mode bounds checking until you have concrete performance data that you need something faster. In C++98/03, that means either write your own array class, use boost::array, or use std::vector. Of those, std::vector is a very reasonable default choice, and it comes with no extra dependencies.

Edit: I actually wish that vector's operator[] was always bounds checked, and then there was an .unsafe_at function that didn't. Most of the time safety is more important that speed, so the easy, convenient, familiar, and concise thing (myvec[j]) should be the safe thing.
Last edited by EvanED on Thu Apr 17, 2014 5:54 pm UTC, edited 4 times in total.

User avatar
Xenomortis
Not actually a special flower.
Posts: 1422
Joined: Thu Oct 11, 2012 8:47 am UTC

Re: C vs C++

Postby Xenomortis » Thu Apr 17, 2014 5:40 pm UTC

chasesan wrote:I am a little behind on the posts, but using a vector in place of a raw array because its "often better" is just the problem with many C++ programs. If you only have 20 elements and you will only ever have 20 elements, the you really shouldn't be using a vector. Except many programs do anyways.

std::vector does more than just allow you to dynamically grow/shrink an array.
It's this ready made dynamic container that is exception safe and bounds checked.

You could achieve these things yourself. You can write your own class that manages the memory allocation and accesses; it wouldn't even take that long.
But why bother when one already exists?

Ninja's got there first.
Image

User avatar
chasesan
Posts: 6
Joined: Thu Oct 13, 2011 3:53 pm UTC
Location: Walking the orbits of electrons.

Re: C vs C++

Postby chasesan » Thu Apr 17, 2014 5:57 pm UTC

Well you should never have a program that needs to access an array beyond it's known bounds when those bounds don't change. Though to be fair (to me), that was just an example.

User avatar
Xenomortis
Not actually a special flower.
Posts: 1422
Joined: Thu Oct 11, 2012 8:47 am UTC

Re: C vs C++

Postby Xenomortis » Thu Apr 17, 2014 6:20 pm UTC

I wish I were as awesome as you.
Image

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: C vs C++

Postby EvanED » Thu Apr 17, 2014 6:30 pm UTC

chasesan wrote:Well you should never have a program that needs to access an array beyond it's known bounds when those bounds don't change. Though to be fair (to me), that was just an example.
You should never have a program that accesses beyond its bounds period. But people write them all the time.

Derek
Posts: 2179
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: C vs C++

Postby Derek » Thu Apr 17, 2014 6:45 pm UTC

chasesan wrote:Well you should never have a program that needs to access an array beyond it's known bounds when those bounds don't change. Though to be fair (to me), that was just an example.

Programs and designs change. What once may have been a fixed size array may need to become dynamic in the future.

Thesh wrote:

Code: Select all

int a[10]; //fixed array
int[] b; //dynamic array

D and Go do something like this, where the first example is an array and the second is a slice of an array, where the slice may create a new underlying array if necessary as it grows.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: C vs C++

Postby ahammel » Thu Apr 17, 2014 7:03 pm UTC

"Why do you need [language feature]? Why don't you just never make mistakes?" <- C programmers.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6282
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: C vs C++

Postby Thesh » Thu Apr 17, 2014 8:04 pm UTC

To be fair, I hardly ever get segfailts in C, but get out of bounds errors in C# all the time.
Summum ius, summa iniuria.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: C vs C++

Postby EvanED » Thu Apr 17, 2014 8:06 pm UTC

Thesh wrote:To be fair, I hardly ever get segfailts in C, but get out of bounds errors in C# all the time.
That just means your C overruns are silently corrupting state instead. (I am... actually I'm not sure how much I'm kidding there. :-))

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6282
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: C vs C++

Postby Thesh » Thu Apr 17, 2014 8:33 pm UTC

Everything I write is GPL or MIT license, so I'm sure it's fine.
Summum ius, summa iniuria.

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Thu Apr 17, 2014 9:41 pm UTC

Thesh wrote:Honestly, I don't think there is a good reason to ever use an array type that doesn't do bounds checking, and this includes raw pointers. The problem with C++ is every single feature it adds is literally an afterthought. Vectors and Arrays could be replaced by a simple native type without the wordy syntax in any other language.

Code: Select all

int a[10]; //fixed array
int[] b; //dynamic array

C++ is full of afterthoughts, but IMO std::vector is not one of them. The C++ standard committee does follow a few principles quite faithfully (as beforethoughts, so to speak), and one of them is that new features should be added as a library rather than a builtin whenever possible. I think it's pretty cool that C++ can provide std::vector, tuples, DSELs (sufficiently powerful for implementing an entire functional sublanguage with lazyness) and continuations all as libraries. New builtins should only be added if they enable a whole new range of libraries, as was the case with variadic templates. For this reason, builtin features in C++ tend to be highly orthogonal. Just adhoc adding a builtin dynamic array (which is the kind of approach you find in languages like Go and Rust) is rather short-sighted compared to that, I think.

Come to think of it, high orthogonality is a pretty good description of what I like in programming languages. It explains why I also like Lua, Forth and Lisp. It also explains why I'm a little bit disappointed in Haskell (which is mostly due to an oversight in the design of its standard libraries). (Don't take me wrong, I still find Haskell impressively orthogonal and it's still one of my favourites).

Thesh wrote:Everything I write is GPL or MIT license, so I'm sure it's fine.

I see what you did there.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
chasesan
Posts: 6
Joined: Thu Oct 13, 2011 3:53 pm UTC
Location: Walking the orbits of electrons.

Re: C vs C++

Postby chasesan » Fri Apr 18, 2014 3:01 am UTC

ahammel wrote:"Why do you need [language feature]? Why don't you just never make mistakes?" <- C programmers.


Or, you know, you could fix your mistakes.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: C vs C++

Postby EvanED » Fri Apr 18, 2014 3:15 am UTC

chasesan wrote:
ahammel wrote:"Why do you need [language feature]? Why don't you just never make mistakes?" <- C programmers.


Or, you know, you could fix your mistakes.
That requires discovering them first. Hopefully before killing a substantial number of HTTPS websites, for example.

Or you could use a language or an API that excludes the possibility of mistakes like that without you having to think about it.

Edit: Oh yeah, and I meant to respond to a couple of JPlus's comments:

Jplus wrote:I've long held this opinion and I still kind of agree to it, but lately (since variadic templates joined the show) I'm starting to think the type-safe memory-safe printf family variant might actually be better.
Yeah, this is one thing I haven't decided on either. OTOH, I did say "arguably". :-)

What I like about printf is that I think a lot of the time if you have a mixture of fixed output with fields, it gives a better scan of what the fixed output is because it's all in one place in the format string instead of being spread out between potentially-complex expressions. What I don't like is that I feel like it has too much DRY violations -- printf("%d", x) -- why do I have to tell you it's an int? Oh, you change your typedefs and it's now a long? Now you have to change your printf strings, or else do something like printf(PRI_MY_TYPDEF, x) instead, but that's vaguely horrendous. I think the right API (which you could definitely still do using templates! don't get me wrong, I'm talking about just a straightforward transliteration of printf to C++11) is something like Python's str.format where you can just drop {} in there and only care about the format specification if you, well, care. That also leaves open the door extensibility, which is THE thing that makes (I think) iostreams way better than raw C printf.

The other thing is that I'm not sure how much variadic templates really matter -- you could do an acceptable approximation by doing the normal variadic-template-approximation thing of having a function with 20 defaulted parameters or something like that. If you put more than 20 things into a single format string I think I hate you anyway. :-)

(And of course, I don't actually use C++11 except very rarely, so there's that as well...)

Jplus wrote:C++ is full of afterthoughts, but IMO std::vector is not one of them. The C++ standard committee does follow a few principles quite faithfully (as beforethoughts, so to speak),
Take lots of acid? :wink:

(I guess that was more Denis Ritchie when he was inventing function pointer syntax for C.)

and one of them is that new features should be added as a library rather than a builtin whenever possible.
I tend to agree here -- I think it's pretty amazing what people have done with language features. But it does come with the downside of syntax that falls between annoying and awful depending on the use case and other tooling issues. (I'll get back to this, I promise!!!)

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

Re: C vs C++

Postby KnightExemplar » Fri Apr 18, 2014 5:30 am UTC

If C++ is "terrifying and insane", why not just use the C parts of C++?

Core GCC has been ported to C++ for this very reason. They are finding uses of References and other minor C++ features quite useful. Unless you've got like... variables named "try" or something, well-written C code basically compiles as C++. The main problem in compiling C code as C++ is the stricter type system (C++ requires more explicit casting)... but that is generally a minor problem in comparison to the benefits.

The whole "References can't be null", and "bool" type help out a lot. (Yeah yeah yeah, C99 added "boolean"). Besides, the C-based "qsort" is slower than "sort". Any C++ library that takes advantage of minor template-metaprogramming optimizations will be faster than the C-equivalent library. So it is often possible to write more efficient C++ code than C code.

Sure, C++ Classes and virtual functions are universally going to be slower than a typical C function... but you're not going to get the same kind of highly-optimized inlining that the "sort" standard template function will get you. (The C qsort callbacks are basically virtual calls, which trash the cache. "sort" is a template function on the otherhand, and can fully inline the callback function during compile time on high optimization settings)
First Strike +1/+1 and Indestructible.

Derek
Posts: 2179
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: C vs C++

Postby Derek » Fri Apr 18, 2014 8:48 am UTC

EvanED wrote:Yeah, this is one thing I haven't decided on either. OTOH, I did say "arguably". :-)

What I like about printf is that I think a lot of the time if you have a mixture of fixed output with fields, it gives a better scan of what the fixed output is because it's all in one place in the format string instead of being spread out between potentially-complex expressions. What I don't like is that I feel like it has too much DRY violations -- printf("%d", x) -- why do I have to tell you it's an int? Oh, you change your typedefs and it's now a long? Now you have to change your printf strings, or else do something like printf(PRI_MY_TYPDEF, x) instead, but that's vaguely horrendous. I think the right API (which you could definitely still do using templates! don't get me wrong, I'm talking about just a straightforward transliteration of printf to C++11) is something like Python's str.format where you can just drop {} in there and only care about the format specification if you, well, care. That also leaves open the door extensibility, which is THE thing that makes (I think) iostreams way better than raw C printf.

Tons of languages have adopted the {} syntax, usually alongside but sometimes as a replacement for the traditional %s, and it wouldn't even be particularly hard to implement in C++. The main problem is that the obvious implementation relies on everything being an object with a toString or equivalent function (or at least only a fixed set of exceptions), which C++ does not guarantee.

Core GCC has been ported to C++ for this very reason. They are finding uses of References and other minor C++ features quite useful. Unless you've got like... variables named "try" or something, well-written C code basically compiles as C++. The main problem in compiling C code as C++ is the stricter type system (C++ requires more explicit casting)... but that is generally a minor problem in comparison to the benefits.

Another notable difference between C and C++ is that C allows variable length arrays on the stack (like "char s2[strlen(s1)+1]"), while C++ does not (and will not, apparently for safety reasons). The closest thing in C++ is a proposal for a dynamic array class, but I don't know if it's gone anywhere.

User avatar
Jplus
Posts: 1711
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: C vs C++

Postby Jplus » Fri Apr 18, 2014 9:31 am UTC

Derek wrote:Tons of languages have adopted the {} syntax, usually alongside but sometimes as a replacement for the traditional %s, and it wouldn't even be particularly hard to implement in C++. The main problem is that the obvious implementation relies on everything being an object with a toString or equivalent function (or at least only a fixed set of exceptions), which C++ does not guarantee.

That's why we have generic programming. Just define operator std::string for a type and you're set.

Although a more flexible approach would probably be to have custom types specialize the function that interprets the formatting syntax. For example something like this:

Code: Select all

template <class T>
string format_apply (string specifier, T value);  // specialize this for your custom type to define
                                                  // your own format specifier syntax and to remove
                                                  // the need to define operator string

// corresponding implementation of format
template <class Arg1, class... Args>
string format (string fmt, const Arg1 & arg1, const Args &... args) {
    string plaintext_head, first_specifier, fmt_remainder;
    tie(plaintext_head, first_specifier, fmt_remainder) = split_fmt_specifier(fmt);
    return plaintext_head + format_apply(first_specifier, arg1) + format(fmt_remainder, args...);
}
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
chasesan
Posts: 6
Joined: Thu Oct 13, 2011 3:53 pm UTC
Location: Walking the orbits of electrons.

Re: C vs C++

Postby chasesan » Fri Apr 18, 2014 1:07 pm UTC

Okay, I relent, there are a number of nice features in C++. I didn't realize people had such a hard time keeping their indexes within bounds of their arrays. I suppose without some kind of check, that you could get yourself into trouble without noticing it.

C++ does have useful features. But speaking personally, I still find C nicer to work with, since there is a lot less I have to actively worry about doing right. So if I am not busy worrying about the extra features of C++, I can instead make sure my arrays stay in bounds.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: C vs C++

Postby ahammel » Fri Apr 18, 2014 2:21 pm UTC

chasesan wrote:Okay, I relent, there are a number of nice features in C++. I didn't realize people had such a hard time keeping their indexes within bounds of their arrays.
It's not that it's hard to do bounds-checking. It's that unless it's impossible not to do bounds-checking, you will fuck it up eventually.
I suppose without some kind of check, that you could get yourself into trouble without noticing.
No need to suppose anything if you've read the news in the past couple of weeks :)
He/Him/His/Alex
God damn these electric sex pants!

User avatar
chasesan
Posts: 6
Joined: Thu Oct 13, 2011 3:53 pm UTC
Location: Walking the orbits of electrons.

Re: C vs C++

Postby chasesan » Fri Apr 18, 2014 5:53 pm UTC

I don't think that counts. That isn't so much a internal program issue as it was someone not properly checking their inputs. You can't claim for certain that the bug wouldn't have occurred if they had written it in C++.


Return to “Religious Wars”

Who is online

Users browsing this forum: No registered users and 4 guests