What Would You Change About C/C++ if You Had The Chance? (For Novices and Experts)

This question goes out to C/C++ novices and the experts.

If you could change something about C/C++ what would it be?

Novices - You know the things that annoy you right from the start that an expert might have gotten used to and forgotten.

Experts - You have detailed knowlege of the language and know what is lacking and what should be changed.

I am collecting this information to help in the development of LightFusion™. It is a programming lanuage being created by VBF's very own Jacob Roman, Penagate, ChemicalNova and myself (eyeRmonkey). Any and all input you have will help us a lot. :)

1. Some things I would change about C++, or that would be in my ideal programming language:
- native support for strings, tuples, lists and maps
- get rid of the header/source file separation
- get rid of unneeded braces and parentheses
- add a for-each loop
- type inference
- closures, i.e. inner functions with access to the parent scope, these are very,very,very usefull. For example:

Code:

---

    button.onclick = function(Event e) { i += 1; };
    Bool sortUp;
    list.sort(function(Item a, Item b) {
        if (sortUp) a.size() < b.size()
        else        a.size() > b.size();
    });

---

- garbage collection, at least good support for it.
- still be compatible with existing C and C++ code (you don't realize how important this is until you try to do without)
- allow adding of custom operators, haskell style named operators would also be very nice and usefull: a `cross` b, c `dot` d, hash `bitwise_rotate_left` 10
- perl 6 style junction operators: if (a == 1 | 2 | 3) { cout << "a is 1 or a is 2 or a is 3"}
- a good meta programming system (look at lisp macros)
- one idea I have been toying with: get rid of member functins of classes. In C++ there are two ways to write a trim function:
trim(string) or string.trim(). It would be great if they are just a single function, and that there are just two ways of defining and calling functions. While you are at it you could probably get rid of one (hint: it's the string.trim() version)

2. I have actually attempted to do this, it works fairly well, but it is nowhere near completion. The language has a lot of the features listed under 1, and it compiles to C++. Have a look, copy as much of it as possible ;)

3. I am not really interested anymore in C++, VB, C# (although the 2.0 stuff is looking real nice), etc. Have a look at ML and Haskell, they are functional programming languages. They are cleaner and more ellegant then any imperative language can ever dream of being.

4. When making a new language you should have a clear goal in mind. IMHO making "a better C++ and VB" is not really useful, those languages already exist, they can even be combined (in .NET). And there are already a lot of better languages.
Of course I have to admint I have been guilty of this myself... :o. My original goal was to "make a better C++", where better specificly means "as easy as possible to use for me, with as little typing as possible"

5. lambda the ultimate == Must read link for anyone doing serious programming language work. Most of the stuff there is very hard and technical, but there is also a lot of usefull ideas there. Browse the forums and archives a little, and look for interesting topics.

6. Good luck with your project.

Thanks very much for your input :)

Custom operators are in.

I don't know much about tuples etc., I'll have to read up on that.

I like for-each too :)

I don't like type inference, but I think that can be resolved with function overloading (Unless I have misunderstood what type inference is, I did look that one up)

Can you explain closures a bit more? I don't really see what you achieve there that you can't do by writing the code into the function itself.

What would I change?
A few syntax changes, especially in the area of declarations.
Type inference as twanvl mentioned would be nice, although I think he'd go further than me. What I want is already supported by some compilers.
Make it possible to overload the pointer and reference declaration operator, and find some good way to overload the direct member access operator. This way, very good garbage collection can be implemented, without forcing it. (I don't like GC.)
Overhaul the compilation system. Employ a powerful pre-linker.

Tuples
Tuples can be considered as simple classes or structs with a nicer syntax. In C++ there is a std::pair class, which is a 2-tuple, i.e. a container for two values. An example use of tuples is returning multiple values from a function:

Code:

---

(bool, string) parse_file() { ... }
(success, result) = parse_file(some_file);

---

Type inference.
A simple example is this:

Code:

---

var x = 123;
var y = "this is a string";

---

it saves you from having to think about the type of a variable. This becomes especially usefull with complicated template types, such as in the boost spirit and lambda libraries.
C++ already uses some type inference with templates, if you have a template function you don't have to know the type of the arguments:

Code:

---

template <typename T>
void write(T value) { ... }
write( expression_with_a_very_complicated_type );

---

Closures
Closures have an effect that is very hard to accieve without them. The first thing you need are first class functions, functions you can pass as parameters and store in variables. This is already possible in C++ using function pointers, although the syntax is somewhat strange.
A lot of STL algorithms (from the <algorithm> header) take a function as an argument, for example the sort function:

Code:

---

template <typename Iterator, typename Function>
void std::sort(Iterator begin, Iterator end, Function comparison);

---

By default this comparison is std::less, which is a function object that takes two parameters and returns true if the first one is smaller then the second one, i.e. it is a function for the < operator.
But you don't always want to compare your items using this operator, say you want to sort a list of employee records, you could sort them by first name, last name, income, etc. Using C++ this is all possible by creating a comparison function and passing that to std::sort.

Now consider another algorithm std::filter, which filters a sequence by only keeping elements that match a certain predicate. The predicate is a function that returns true if an element should be kept, and false if it should be removed. Now lets make a 'emplyees that earn more then ...' function:

Code:

---

std::vector<Employee> employees_that_earn_more_then(int min_salary) {
    std::vector<Employee> emplyees = get_employees();
    std::filter(emplyees.begin(), employees.end(), earn_more_then_min_salary);
}

---

Here we have a problem, how do we define the earn_more_then_min_salary function? The function depends on min_salary. The C++ solution is as follows:

Code:

---

class earn_more_then_min_salary {
    int min_salary;
    bool operator () (Employee e) {
        return e.salary >= min_salary
    }
    earn_more_then_min_salary(int min_salary) : min_salary(min_salary) {}
};
std::filter(emplyees.begin(), employees.end(), earn_more_then_min_salary(min_salary));

---

That is a lot of work just to define a simple function. Now closures come into play:

Code:

---

bool earn_more_then_min_salary (Employee e) {
    return e < min_salary;
}
std::filter(emplyees.begin(), employees.end(), earn_more_then_min_salary);

---

That is a lot easier to read. Haskell has an even easier notation when using operators, say we have a list of salaries, and want to keep the ones that are greater then or equal min_salary:

Code:

---

filter salaries (>= min_salary)

---

Here "(>= min_salary)" is a function that returns whether its argument is greater then or equal min_salary.

Another area where closures, or at least first class functions can be very usefull are GUI libraries, specificly in event handling. One such 'library' that uses this today is DHTML, i.e. dynamic web pages with javascript, CSS and DOM. For example in javascript you can do this:

Code:

---

function add_pop_up_menu(button, menu) {
    button.onmouseover = function() { menu.style.visibilty = 'visible'; };
    button.onmouseout  = function() { menu.style.visibilty = 'hidden'; };
}

---

As you can see the menu variable is not explicitly stored anywhere, only the event functions can still use it. If add_pop_up_menu is called multiple times, each button could refer to a different menu.

Well, C++ has std::bind1st/bind2nd, std::tr1::bind and boost::bind, or boost::lambda, and introspection iterators or bind expressions for lambda. So the earn_more_than_min_salary example:

Code:

---

std::filter(emplyees.begin(), employees.end(), earn_more_then_min_salary(min_salary));

---

could be written like this (assuming correct namespace import):

Code:

---

std::filter(employees.begin(), employees.end(),
  (bind(&Employee::salary, _1) < min_salary));

---

The Boost lambda library is brutal on the compiler, but it works pretty much like you'd expect it to.

Oh, and JavaScript closures have a high chance of leaking lots of memory in IE.


I agree with twanvl about treating built-in operators as functions, though. That would be useful in many situations.

The most useful one I can think of it:
calling functions by their name!!!
MATLAB has a rather nice function, f_eval("function_name", parameters) which is the same as calling function_name(parameters). This would be very useful as well in C++. Unfortunately, passing around function pointers can get rather nasty, and if you want many of them, all which have a different type, then you can't stick them in a vector.
However, if you could have this f_eval() thing, then you could just store each as a string.
I guess you could macro #define f_eval(x, y) x(y), but i'm not sure if this does the same thing, or works with multiple parameters.

I think a better solution then having a specific call-by-name feature, would be to have the language support reflection, then you can easily implement it yourself:

Code:

---

template <typename Fn>
void call_by_name(String name) {
    for-each(fn in __all_functions_of_type__<Fn>) {
        if (fn.name == name) {
            (fn.pointer)();
        }
    }
}

---

There is also a very good reason why you can't put functions of different types in a single vector, because then you can't know how to call one of those functions. Most often you either have functions of the same type, so you make a vector<int(int)>; or you have functions that can be of any type, in that case use something like vector<boost::any>.

Coming from VB and doing a C++ course I find it really annoying!
Constructors and destructors seem like a waste of typing ;)
Lack of string type is a pain, although you can use std::string you cant use it in a switch statement :rolleyes:
I feel "Dim intDemo as Integer" is better than "int intDemo;" because when you have class types of strange names it is not always obvious when you are defining something.
Not being RAD is frustrating.

Quote:

---

Originally Posted by agmorgan

Constructors and destructors seem like a waste of typing ;)

---

Errm ... no! Just wait until you're actually using C++. Lack of predictable destructors is one of the worst things about Java and C#.

Quote:

---

Lack of string type is a pain, although you can use std::string you cant use it in a switch statement :rolleyes:

---

So what? Truth be told, switches on strings are usually a bad idea anyway.

Quote:

---

I feel "Dim intDemo as Integer" is better than "int intDemo;" because when you have class types of strange names it is not always obvious when you are defining something.

---

And what else would a line consisting of two identifiers be? Since function calls always need parentheses, it can't be anything else.

Quote:

---

Not being RAD is frustrating.

---

RAD is a capability of the development environment, not the language. Borland C++ Builder is a RAD tool for C++. There are RAD tools for C/GTK+ or C++/GTK--, for C++/Qt, ...
Even Visual C++ supports some RAD with C++/MFC.

If I had my way with C++, there wouldn't be much left of it to call C++.
One thing though that always annoyed me: templates.

I'd probably do away with the :: namespace separator. I simply find it annoying, no better reason than that :D

Also I'd force it to have more meaningful compiler error messages.

I am a VB developer and a novice user of C/C++. The main thing now annoying me is the case sensitivity.

Case sensitivity is a good thing, VB annoys me because it isn't.

Probably ReDeclaration of Variables, like Redim in VB. it helps in saving memory.

I was in the BASIC way form old GWBASIC to the latest VB2005. That may be why case sensitivity is annoying me. As Harsh Gupta wrote, C++ should have a ReDim like thing.

What exactly would the ReDim do?

increase/decrease size of array by preserving (if preserve keyword is used and if size is increasing) the data

Quote:

---

Originally Posted by CornedBee

What exactly would the ReDim do?

---

Dim is used to declare variables. e.g.

VB Code:

Dim var1 As Integer

Dim is used (necessarily) when you want to declare variables. Other ways are Public, Private, Static (similar to declaring variables in C++), Preserve (i dont remember its function). Dim is used whenever you are not sure about its identifier.

Consider an array in VB

VB Code:

Dim arr() As Integer

the array in this example doesnot have any upperbound and will take a lot of space. later while coding you see that you need to take atmost 10 indices of the array (which i think is wastage of memory) you can code it like this:

VB Code:

ReDim arr(1-10) As Integer
'or
ReDim arr(9) As Integer

this will reinitialise the array with 10 indices.

I know what ReDim does in VB. I want to know what you would have it do in C++ that a vector, deque or list can't.

Arrays in VB are crap, they occupy at least 10 bytes with no elements. VB has a dynamic indexing of arrays, but a one size fit all paradigm costs memory and cycles. Redim may make life easier for the programmer, but the same could be done by erasing or copying elements on the STL containers. On the other hand annoying languages like C++ cost a programmer gray hair. There ought to be a convenient way to end fence post errors and memory leaks already. A good language ought to provide both efficiency and flexibility without throwing safety out the window.

Quote:

---

Originally Posted by kedaman

A good language ought to provide both efficiency and flexibility without throwing safety out the window.

---

Precisely my thoughts.

As for saving memory using Redim in VB, I don't think that VB would be used in an environment where memory is an issue. However, performance is ALWAYS an issue, and Redim is very slow. Hence, if you can't predict how big an array you will need from the start (which is rare, but occasional) you should just allocate approximately the maximum that you will need in most situations. If necessary you can increase this later, also by a large amount. This will vastly cut down on your ReDim usage.

Quote:

---

Originally Posted by penagate

Precisely my thoughts.

As for saving memory using Redim in VB, I don't think that VB would be used in an environment where memory is an issue. However, performance is ALWAYS an issue, and Redim is very slow. Hence, if you can't predict how big an array you will need from the start (which is rare, but occasional) you should just allocate approximately the maximum that you will need in most situations. If necessary you can increase this later, also by a large amount. This will vastly cut down on your ReDim usage.

---

True, but unlike with STL vectors this has to be done manually. Memory becomes an issue though as soon as you want to do anything beyond the regular UI programming.. :lol:

Indeed :D

One thing I think would be great would be if c++ was more friendly for web development.

Adding a mail() function like PHP would be good. So we wouldn't have to go around our elbow to get to our butt when sending out email.
Also, having URL un-encoding (like PHP) built in would be great so we wouldn't have to use a parsing function or a cgi class to separate variables with into name=value pairs. PHP does this automatically and it would be NICE if C++ did it too.

And this final one is a personal compaint of mine. Data conversion in C++ sucks. Get rid of the cstrings. strcpy should be done away with and thisVar=thatVar should be sufficient for all strings AND char pointers. You'd have to rewrite a lot of code for that to work. Like the fstream class which takes a cstring as the datatype when opening a file. I get tired of errors because I had a string that I passed to a function and converted it to a csting using .c_str() and then I get an error because it is now a constant pointer (array of string) and I didn't pass it as a const char[] but only a char[] so I get compiler errors. You can't do myCharPointer = thatString but you have to convert it to a c_string then use strcpy etc... etc... That mess is annoying! :mad: Correct it!

c++ seems to me like an old house that was big and nice at one time. Then they come along and added a bedroom, then a bathroom, then a patio, then another bedroom. The result is a one house that you can tell has been patched together and it looks pretty bad.

It is interesting to note the difference in suggestions between those that understand C++ itself, and those that do not... :)

Quote:

---

Originally Posted by darth vador

Data conversion in C++ sucks.

---

Unfortunately (or not), it reflects how computers work. Don't like it? You can build your own string class that works exactly the way you want. Or you could just use std::string or one of many others.

http://www.cppreference.com/cppstrin...operators.html

Also, there is a clear difference between C and C++ : the two terms are not interchangeable, they refer to separate languages (although C++ is an extension of C). strcpy(), and its friends, are functions used in C. If you are using C++ over C, why not take advantage of what it has to offer?

Quote:

---

I get tired of errors because I had a string that I passed to a function and converted it to a csting using .c_str() and then I get an error because it is now a constant pointer (array of string) and I didn't pass it as a const char[] but only a char[] so I get compiler errors. You can't do myCharPointer = thatString but you have to convert it to a c_string then use strcpy etc... etc... That mess is annoying! :mad: Correct it!

---

That's your job.

Quote:

---

c++ seems to me like an old house that was big and nice at one time. Then they come along and added a bedroom, then a bathroom, then a patio, then another bedroom. The result is a one house that you can tell has been patched together and it looks pretty bad.

---

Not surprising considering you are using a mixture of C and C++.

Quote:

---

Originally Posted by Harsh Gupta

Dim is used whenever you are not sure about its identifier.

---

"Dim" declares a local variable. With a nod to older BASIC dialects, it can also be used to declare a module-level variable, although it is considered bad style to do so now - you should use the more obvious "Private" instead. I suppose by "identifier" you mean scope, but the scope is NEVER ambigious in any case. As the programmer, if you are unsure about something, it shouldn't be there.

Quote:

---

Consider an array in VB

VB Code:

Dim arr() As Integer

the array in this example doesnot have any upperbound and will take a lot of space.

---

Eh, no. arr(), at the point of declaration, is undimensioned, and will occupy merely the size of the SAFEARRAY description header (I forget how much, 24 bytes or something). Correct, it has no bounds as such, but you are implying that you can then use it as an unbounded array - in fact you can't use it at all.

For the reference of others that don't know this - Arrays in VB are heap-allocated. ReDim allocates a new block, of the size that you specify, on the heap for your array to occupy. Redim Preserve additionally copies any exisiting contents of your array to the new location - which is why it is slow, and especially noticeable with larger arrays.

Quote:

---

Originally Posted by jain_mj

I am a VB developer and a novice user of C/C++. The main thing now annoying me is the case sensitivity.

---

Fair, it's annoying when you are used to case insensitivity. You get used to it however. And you can't do this in VB:

Code:

---

Button button = new Button();

---

you'd throw the compiler into a right loop. It's a trivial point however.

Quote:

---

Originally Posted by kedaman

One thing though that always annoyed me: templates.

---

Why do templates annoy you?

Quote:

---

Originally Posted by penagate

Eh, no. arr(), at the point of declaration, is undimensioned, and will occupy merely the size of the SAFEARRAY description header (I forget how much, 24 bytes or something).

---

sheesh, was it that big :sick:

Quote:

---

Originally Posted by penagate

Why do templates annoy you?

---

I was fearing this question would be asked. Templates are messy and and compilers don't like them. I was developing a template library about 3 years ago running to all sorts of problems, until i realized what the actual problem was. Templates exist merely because OOP sucks, and C++ is basically C + OOP which is a step back from C, so a counterweight is required, namely templates. If OOP could have been implemented better templates wouldn't be needed, but in the end its all because compilers aren't simply good enough, which is because there aren't any good programmers who can write a decent compiler.

Quite the fatalistic view you have there, keda :)

Quote:

---

Not surprising considering you are using a mixture of C and C++.

---

I disagree. I'm not using a mixture of c and c++.

It wasn't until recently that c++ even had a strings class. Originally, in order to use strings in C++ you had to use an array of characters. - Just like C. It was the only way you could use strings in C++. Its not like cstrings were made for c and c++ had the <strings> header file. Both languages used cstrings alone. The strings class is an addition to the c++ language. They're trying to make it easier to manipulate strings in c++, and they have. But now you have now have different versions of strings that don't work well together. That's why I gave my anaology of a house that keeps having things added to it. FYI, I've never learned c. I started with C++ in college. If I know anything about c, it because it's a basic part of C++ and c++ requires it. :mad:

Quote:

---

If you are using C++ over C, why not take advantage of what it has to offer?

---

And not use any c functions? Simply because the language has been patched together and you can't! Even in you want to use strings, and I do, there are few times you can write a useful C++ program without using the <cstrings> header file etc...having to convert a string to a cString etc...

Quote:

---

Unfortunately (or not), it reflects how computers work.

---

No. Its a reflection of how c++ works. Data conversion issues, especially of different types of 'strings' is unique to C++. You noted that I could write my own class that can do exactly what I want ... and that is the whole point. It can be done in spite of how a computer works. If I can do it, so can the developers of the language.

You prove precisely the point I intended - it has nothing to do with the language itself. Languages and libraries are two entirely different things.

Quote:

---

No. Its a reflection of how c++ works.

---

Maybe you find C++ confusing because it permits work at a lower level than many other languages, hence with less layers of abstraction to shield the machine-level operation. The pointers and arrays etc. that you complain about are exactly how computers work. If you find it confusing, try learning assembly - maybe working right at the CPU level can clear up any difficulties you have with its operation. But, as I said, you don't HAVE to do any of that if you work in straight C++.

Quote:

---

Maybe you find C++ confusing because it permits work at a lower level than many other languages, hence with less layers of abstraction to shield the machine-level operation.

---

I think you're right about that. (So I guess I was suggesting that they make c++ a little higher level of a language, which is probably not a good idea. :eek: )

Having said that, it still doesn't mean that data coversion is C++ doesn't suck. ;)

You have a peculiar notion of "recently". The <string> header has been available in, for example, Visual C++ since version 6, i.e. early 1998 (not 100% complete).

CB: not necessarily ;) Otherwise i would have stopped being annoyed with them ;)