C vs C++

[3TXyhbRD]

antred wrote:

You're using a C library. You're not necessarily writing C just because you use a C library. Writing a server in C++ is perfectly viable and, I find, a heck of a lot easier and less error-prone than doing the same in C.

For iterative servers maybe, but for concurrent servers it becomes more difficult. You need an object to do a fork(), generally the server object. How is the child gonna get out of that? You need the child to stop the "server" by getting out of the server object method that realized the fork(), destroy the server object (why would the child be a server?), then somehow create a "child" object and call a method from that object.While in C you just do the fork(), if it returns 0 you are in the child code, if it returns above 0 you're still in the parent code. No object creation/destruction and exiting a method/calling a method in a weird way. With the check for -1 before all this ofc.

For me, using a C library means you're coding in C. It's a trick many use to skip a headache but still incorrect, if you program in C++ then do so, don't twist languages together, just my opinion.

[antred]

Even if we pretend for a minute that fork() is the only (or even just the best) way to go about writing a concurrent server, I completely fail to see how ANY of what you just wrote means that it can't be done in C++.

[3TXyhbRD]

Ofc fork() ain't the only available option for writing concurrent servers, I just took this case because I can't find a logic way for that particular function to work with C++.
I'm not saying it can't be done, I'm saying it's an odd way to go for it. The server "child" is not the server, then why does the "child" have a server object?

EDIT:
kbw, I just noticed your post

About try... catch, the exception "object" can always be stored via address in a void pointer and when a zone receives control it treats the respective pointer. About hierarchy you can decide to have more zones, each treating a specific object or use a switch... case where all your "objects" have a "method" that's test the hierarchy, or a function instead of a "method". Hierarchy testing is all dependent on how you make you "object".

About why I think C is better for servers than C++. Well in my previous statement I said that I personally don't like to mix languages. Other than that, it's been a long time since C++ came out, why are there no standard C++ classes specially made for sockets and IPCs? Why do I need to go into C coding use these things? Instead of encapsulating C functions into C++ classes and get something slower as run-time (need to treat all possible errors, flags etc. and throw exceptions based on those errors) I would rather be direct and only use C.

[o1vk4iN6]

antred wrote:

And what about RAII? I find it really hard to take seriously any language that doesn't offer such a trivial but immensely powerful thing. I'd hate be forced to adhere to something silly like single-entry, single-exit just because the language doesn't offer me a simple, reliable way of telling the compiler to "do-this-on-scope-exit".

Also, how is the fact that C++ supports runtime polymorphism NATIVELY not an advantage?

I was speaking strictly features that can't be done in C. Yes the feature isn't natively supported but that doesn't mean you can't add it yourself to C. As well if it doesn't have feature X, that doesn't mean there isn't another way to approach the problem.

[antred]

xerczi wrote

I was speaking strictly features that can't be done in C. Yes the feature isn't natively supported but that doesn't mean you can't add it yourself to C. As well if it doesn't have feature X, that doesn't mean there isn't another way to approach the problem.

Yes, but it does mean that your life just got harder than it would have if you had used the other language instead.

[rocketboy9000]

The main difference between C and C++ is the amount of stuff you have to fit inside your brain.
With C, the grammar is simple (even the order of operations, widely considered difficult, can be memorized.) and the standard library is very small (to the point which many people keep their own library of useful snippet functions). I can write in C with Allegro or SDL without looking up anything, and it will usually work as expected.
With C++, the grammar is complex, because of two things: First, references hide the valuable information about which operations we can expect to have side effects. Second, function overloading and operator overloading make it difficult to look up what any piece of code does, after a few weeks away. The C++ standard library is truly gargantuan, even in the 1998 version. Despite having some awesome things, (vector,string), it is littered with things that are unnecessary (bitset, functional), and things which are poorly designed (iostream).
Finally, C++ has some (but not total) backward compatibility with C. So when a person learns C++, they must also learn all of C, if they ignore the C parts, they will find code written partially in C incomprehensible.
C++ is good. But it is very difficult to use well, so unless you are working with a C++ code base or library, it's probably better to start a new project in C.

[rapidcoder]

Hmm. C smashes C++ in just one thing: portability. There are very few platforms for which you have a standard-compliant C++ compiler, and even on those platforms compiling C++ programs from source is usually much more of a headache than compiling an equivalent C program. Contrary, for any even most exotic hardware, if you get anything besides an assemler, there is a C compiler. If I write a program in pure C, I'll have a 99% probability I can compile it on anything and the only eventual problems would be libraries. It is also much easier to link code created with different C compilers, because ABI is simple.

[Abramus]

I noticed many people here seem to think that a programming language is a set of features. Therefore C++ must be better than C, as it has all the things C has, and some more.

Well, I don’t think it is true. C++ may have operator overloading, but what it does not have is: simplicity, consistency, elegance, portability. I believe C++ creators were too busy adding more and more duplicated features to stop for a while and think about what they actually try to accomplish.

[kbw]

but what it does not have is: simplicity, consistency, elegance, portability

Sadly, I have to grudingly agree.

Simplicity
C++ started out as C with Classes. It provided direct support for abstract datatypes with guaranteed construction/destruction of classes. Then came support for objects, the original aim. So far, so good.

Now it starts getting complicated.
Multiple inheritance was added early because it was said it couldn't be done efficiently; well it was implemented efficiently in C++. But what a thing! I think the industry believes the best use of multiple inheritance (of implementation) is to avoid it.

ADA Generics were added with a C twist in the form of templates. It's turned out that templates are a language in themselves. The obvious case of vector<int> or min<int>() is simple enough, but templates can get really powerful, complicated and neigh impenetrable to the uninitiated in their own right (see Loki).

And of course, there's exceptions. This wonderful feature (along with RTTI) is a feature that has a runtime cost (shock/horror!). And as beautiful as it is to use, even with it contrained to the termination model, it's rarely used well. So why bother?

Add all that together, and you've got a hugely complicated language. I'm sure the author never expected it to be this complicated, all those boundary conditions and tweaks in a drive to make it consistent. Ugh!

Compared to C or Objective-C or even Java, C++ is an incredibly complicated language. It takes a long time to become an expert and it's an engineering feat of staggering achievement to produce a compliant compiler.

elegance
C++ can be elegant, should be elegant, but most commercial code I've seen isn't. It may be the effort in refactoring designs and then having that ripple thru C++ implementions, or the difficulty in finding engineers who can maintain a standard within a subculture, but much commercial code tends to build entropy quickly.

portabilityThis is my biggest issue with C++ and to C99 too. Why does the language need to keep evolving? After 18 or so years of C++ compilers finally converging on the standard, the standard ups and takes a few more steps into the unimplemented. Why oh why? Can we just let it be? These extensions seem to be improvements where properly used, but maybe they should just have gone into a new language, call it C2 or something. The extension of C++ into the latest standard just destabilises the C++ environment, puts portability at risk (because it'll take years for vendors to catch up on all the relevant platforms), subjects us to years of non-compilant and buggy compilers.

Has someone forgotten that C++ is an engineering tool? At least you know where you are with C (pre C99).

[beginning]

both prefers.

[Cubbi]

After 18 or so years of C++ compilers finally converging on the standard, the standard ups and takes a few more steps into the unimplemented. Why oh why? Can we just let it be?

Just like in 1998, the bulk of the standard is in fact *standardization* of existing practices. Compilers are diverging, both in the way they handle the issues with the 1998 language and in the way they introduce language extensions and if you "just let it be", they will continue diverging.

At least you know where you are with C (pre C99).

In a museum? The C jobs I've seen lately all use C99, and I doubt one could remain competitive today otherwise.

[spaggy]

You can't really ever say C++ is better than C, and vice versa. The languages are tools. Which one is better depends on the problem, you're trying to solve. Some things lend themselves better to be written in C than in C++, servers for example, whereas it might be better to write a video game in C++. There's no point in saying C++ has more features than C or it's a superset of C, so it's definitely better. If I don't need those features to solve my problem or they don't make solving my problem easier, then it's likely they'll be more of burden and make it more likely for me write bad code. There's a reason I don't use a chainsaw to cut my bread