What features would you like to add to /remove from C++?

[ithelp]

Hi Experts,
Please share your thoughts, it was asked to me in a job interview, I said I would remove "multiple inheritance" , but I was not prepared for the interview question.
Your ideas please.

[Bench]

If you were asked in another interview, which words would you remove from the English language, and why, how might you answer?

Then ask yourself what you think people who spoke the language would do after those words had been "removed" ?

[Ancient Dragon]

If I had to choose something it would be to remove everything in iostream and fstream IMO it is clumbsy and difficult to learn/use.

[ShawnCplus]

I would like to add two things, simple sockets and simple multi-threading, the latter of which is already in discussion. Sockets in C++ are a nightmare whereas in Java it's Socket mySocket = new Socket(3000); and bam, you have a socket.

[Narue]

>What features would you like to add to /remove from C++?
I can't think of anything off the top of my head that I would remove. Redesign perhaps, but not remove. Additions are a problem because the language and libraries are bloated enough as it is. My answer would be that I'd remove classes, because C++ is C with classes and C is a kewler language[1].

>I said I would remove "multiple inheritance"
Why? Most people who suggest removing a feature are the ones who have never seriously used it. They follow the logic of "if I don't need it, nobody else does".

>If I had to choose something it would be to remove everything in
>iostream and fstream IMO it is clumbsy and difficult to learn/use.
Assuming it's okay to break all of the existing code that uses iostreams, this removal would only make sense if you already had a provably superior replacement.

[1] Which is, of course, a joke. But since I perceive interviews as me interviewing the company, it gives me insight into how laid back the environment is.

[Ancient Dragon]

>>Assuming it's okay to break all of the existing code that uses iostreams
That would be true of anything that we would like to remove.

>>this removal would only make sense if you already had a provably superior replacement.
There already is a superior replacemenmt -- its the functions in stdio.h. There are a few (very few) things I like about iostreams but for the most part fprintf() is a lot easier to use.

[Narue]

>That would be true of anything that we would like to remove.
It's especially devastating with iostreams.

>There already is a superior replacemenmt -- its the functions in stdio.h.
That's what I was afraid you'd suggest.

>There are a few (very few) things I like about iostreams
>but for the most part fprintf() is a lot easier to use.
Except when you want type safety. Except when you want to extend the standard interface (adding your own user-defined type to fprintf, for example). And of course, except when someone points out that format strings are a bitch to get right for all but the most twisted aficionados.

[Salem]

> I would like to add two things, simple sockets and simple multi-threading
So be damned to the portability to lesser machines which lack say a network connection?
All because you can't be bothered to write your own simple reusable network class.
Besides, in order to be "simple", it would have to leave out a lot of features. Which of course would make it instantly useless to everyone else.

Next people will be wanting graphics, sound, blah blah blah. All of which are far from platform neutral.

One thing I would like to see fixed are the parts of fstream which depend on C-style char arrays to represent filenames for example.

> but I was not prepared for the interview question.
Perhaps that was the point.
Most companies want people who can adapt and think for themselves, usually with less than complete information. They don't want walking encyclopaedias incapable of thinking for themselves.

[ShawnCplus]

OK, if a system lacks a network connection why the heck would it be using a program or programming something that is supposed to connect to the internet anyway. That was an extremely strange comment.

[Jessehk]

>>this removal would only make sense if you already had a provably superior replacement.
There already is a superior replacemenmt -- its the functions in stdio.h. There are a few (very few) things I like about iostreams but for the most part fprintf() is a lot easier to use.

Boost.Format maybe? :)
http://www.boost.org/libs/format/index.html

#include <iostream>

#include <boost/format.hpp>

int main() {
    int age = 17;
    std::cout << boost::format( "%d years old!" ) % age << std::endl;
    
    double amt = 42.1294;
    std::cout << boost::format( "$%.2lf" ) % amt << std::endl;
    
    std::cout << boost::format( "%1% %2% %2% %1%" ) % "a" % "b" << std::endl;
}

17 years old!
$42.13
a b b a

[Ancient Dragon]

>>Boost.Format maybe?
Yes, that's a good alternative, but unfortunately that isn't standard c++ (yet) either. I have never used boost but I have heard many of their classes will be in the next version of c++ in one for or another.

[ithelp]

If you were asked in another interview, which words would you remove from the English language, and why, how might you answer?

Then ask yourself what you think people who spoke the language would do after those words had been "removed" ?

Not that way, but in job interview they have got all the liberty to ask you whatever interview questions they like.

[Salem]

> OK, if a system lacks a network connection why the heck would it be using a program or
> programming something that is supposed to connect to the internet anyway.
Because my car/microwave/camera/digital watch/toaster/fridge/etc etc are all likely to have a micro processor, but very unlikely to have a network connection.
C and C++ are used for programming far more different kinds of machines than the box you're sitting at typing away.

The portable core of the language has to cater for a very diverse audience.

Things like STL and BOOST only assume processor time and memory. You as a developer have a simple choice of whether to use them or not, and a compiler developer can simply adopt pre-existing implementations. As soon as you start adding other physical devices then things get a whole lot messier a whole lot quicker. All of a sudden, vendors can no longer pass the conformance tests if they don't support the 'foo' hardware you're so keen on supporting.

Also, since it takes about 10 years to turn around a standard, this is far too glacial for the fast pace at which hardware is evolving.