undefined | Better HN

0 pointsinterestingcpp8y ago0 comments

Interesting; i think it’s fairly clear by now engaging with C++ is not going to lead to reduced complexity at all. When was the last time it removed support for a feature? That’s not what the language needs because it’s more interested in preserving existing code bases than it is at improving them (the latter being a huge effort, truly massive, so i understand the decision and don’t mean it as a slight in the least).

0 comments

mattnewport8y ago

Major influential figures in the C++ community (notably Bjarne Stroustrup and Herb Sutter) are very explicit about having a goal of simplifying everyday usage of C++ (make simple things simple). Watch any of Bjarne's talks over the last few years to see this is one of his main focuses. It's also recognized that backwards compatibility / not breaking existing code are very important however. Yes, that's a hard set of requirements to meet but I find it bizarre when I keep seeing people state that the C++ standards committee and the community in general don't care about simplicity and ease of use when those are literally the major topics of keynotes at every C++ conference of the last few years.

mattnewport8y ago

Complexity of the language is a much discussed topic. In the trivial sense it is true that the language will inevitably get "more complex" as new features are added but backwards compatibility is largely maintained. I don't believe that is a very relevant metric for usability however. Higher level features are generally added to languages to make them simpler to use but they also make that language more complex by some metrics. You can argue that assembly language is "simpler" than C++ because it lacks "complex" higher level abstractions but I'd rather wrote code in C++98 than assembly most of the time and I'd rather write code in C++17 than any previous version of C++ because it continues to get more usable and simple things get simpler.

catnaroek8y ago

Complexity doesn't come from abstraction, but rather from the lack of simultaneously short and precise descriptions of how things work. C++ isn't complex because “it's flexible enough to support several programming styles” or whatever nonsense. It's complex because its features are all bolted on, rather than parts of a coherent design from the ground up.

1 more reply

interestingcppOP8y ago

Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.

mattnewport8y ago

My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautologically "increasing complexity" are not interesting. Specific concerns about particular features not carrying their weight in terms of simplifying usage are interesting (and a big part of what the C++ standards process is engaged in).

2 more replies

kccqzy8y ago

C++17 removed trigraphs. C++17 removed dynamic exception specification which is deprecated since C++11. C++17 removed operator++ for bool which is deprecated since C++98. C++17 removed the “register” storage class.

a_e_k8y ago

C++11 removed the original meaning of "auto".

jcelerier8y ago

> When was the last time it removed support for a feature?

why should it ? Adding features is enough for simplifying stuff.

eg take the following code:

    for(auto& val : {1,3,12,17,20}) { val++; }

it leverages three new features: auto, range-based for, and braced initialization.

How would it look in cpp03 ? Two possibilities:

    std::vector<int> v;
    v.push_back(1); v.push_back(3); ... v.push_back(20);
    for(std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) {
      (*it)++;
    }

    int v[] = {1,3,12,17,20};
    for(int i = 0; i < (int)(sizeof(v)/sizeof(int)); i++) {
      v[i]++;
    }

j / k navigate · click thread line to collapse

0 comments

mattnewport8y ago

catnaroek8y ago

1 more reply

interestingcppOP8y ago

mattnewport8y ago

2 more replies

kccqzy8y ago

a_e_k8y ago

C++11 removed the original meaning of "auto".

jcelerier8y ago

> When was the last time it removed support for a feature?

why should it ? Adding features is enough for simplifying stuff.

eg take the following code:

    for(auto& val : {1,3,12,17,20}) { val++; }

it leverages three new features: auto, range-based for, and braced initialization.

How would it look in cpp03 ? Two possibilities:

    std::vector<int> v;
    v.push_back(1); v.push_back(3); ... v.push_back(20);
    for(std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) {
      (*it)++;
    }

    int v[] = {1,3,12,17,20};
    for(int i = 0; i < (int)(sizeof(v)/sizeof(int)); i++) {
      v[i]++;
    }

j / k navigate · click thread line to collapse