4 ms·

Oh great. More magic syntax that makes one thing look and behave like another, while not actually being that other. Every time C++ gets new features, I feel li

• kensai 12y ago
  I really don't understand this kind of bash every time C++ gets some cool new feature. A developer that does NOT want to use a feature can always not use it. But why should we deny it to those who are interested and use it at their own risk?
  • sagichmal 12y ago
    A good language is not one which maximizes the number of "cool new features", but rather one in which all features interoperate coherently.
    • pjmlp 12y ago
      There aren't that many examples of such languages that survived in the mainstream.
      • golemotron 12y ago
        Ruby and Python seem relatively coherent next to the feature creep of C++, Java, and C#.
        • pjmlp 12y ago
          I cannot speak for Ruby, but Python has had big ride since the 1.0 days, specially if you take the standard library into account.
      • angersock 12y ago
        C, Javascript. There, I said it.
        • nly 12y ago
          C has added few features worth a damn in 15-25 years. It hasn't even bothered to augment the standard library, which is just dire in terms of API design, capability and performance. Some of C++s worst stdlib components are modelled on libc (e.g. streams and locales)
  • delroth 12y ago
    It fragments the ecosystem. A developer that does not want to use a feature gets limited in its choice of libraries. It makes it harder for people to contribute to other C++ projects (experience can not be directly translated since different aspects of the language might be used). Exceptions are a good example of that: you can't use a library that's built around exceptions for error reporting if you don't want to use exceptions in your own code.
    • truncate 12y ago
      Also, unless I have strong feeling against some feature I may spend unnecessary time thinking what syntax style should I be using rather than more important stuff. I avoid it, but it still happens to me sometimes unconsciously and I hate it. Not to mention one more point to argue over coding style.
  • golemotron 12y ago
    The problem is that there is no way to reduce complexity in a programming language that is serious about backward compatibility. C++ now has close to 30 years of non-trivial additions built on the craggy basis of backward compatibility with C and its own feature set. In the early 1990s, it was complex. The Annotated Reference Manual that was used as the de facto standard was full of edge cases and detail that required a great deal of study. No other language since has approached that level of complexity and I'm talking about what it was like before templates. I sincerely believe that C++'s downfall is underway and it comes from a very simple fact - it's increasingly hard (read impossible) for new C++ programmers to go from zero knowledge of the language to being able to read and maintain modern C++ programs that have taken full advantage of the feature set over the past decades.
    • pjmlp 12y ago
      Yes it is complex, but you can say the same about almost any modern language. If the language is not complex, then it is the eco-system.
      • golemotron 12y ago
        Yes, but on balance, I think that ecosystem complexity is both more tractable and addressable than language complexity.
        • pjmlp 12y ago
          I think it is relative. An ecosystem can also be quite complex, specially if it changes often. Any newcomer will face the exact situation not knowing what to use, what is no longer best practice or what should be avoided.
  • pjc50 12y ago
    Do you get to prevent your co-workers using it?
  • _1 12y ago
    Most people don't code in a vacuum.
  • dmytrish 12y ago
    There's a saying, "If you want someone to feel good, hurt him and then stop". C++ is a classical example of this approach, every time C++ committee fights warts it has created, it is perceived like a "cool new feature". What's exactly cool about this syntax? Is it that C++ can now mimic syntax of truly object-oriented languages better? What's the point if nothing has changed under the hood?
  • angersock 12y ago
    No, no, you really can't. As mentioned elsewhere, consider exception handling, or use of Boost or STL--in many cases, libraries will leak such implementation details during stack traces or interfaces or what have you. From a coding standpoint, using the hottest new sexy library can mean breaking compatibility with older compilers. This might be surprising, but a lot of times shops still use old versions of compilers because they're a known evil. For all these cool new features, consider that C++ has yet to standardize on a standard library file system interface (though one is, kinda, in the works). It only just introduced hash maps into the core standard library. It still does not deign to handle time in a useful fashion: Javascript gets this right out of the box, whereas C++ doesn't even have a way of parsing or generating an ISO-8601 datetime string without having to pull in Boost. ~ The language seems to have abandoned all of the programmers that need to get actual work done, which is fine, because they've all moved to more productive languages like Java, Python, Ruby, Javascript, Go, or PHP.
• vidarh 12y ago
  Consider that someob.foo(other args) in C++ is already effectively syntactic sugar for <address of foo as function pointer>(someob, other args) where <address of foo> is either obtained by statically resolving which function "foo" refers to, or dynamically looking it up in "someob"'s vtable with an indirection. What we've always had is two syntaxes that results in pretty much the same code (the same for non-virtual member functions and freestanding functions, and slightly different for virtual member functions) that have mainly different by lookup. This proposal is basically suggesting to reduce the gap by making the "dot syntax" closer to a superset of the function call lookup. I don't see how that is any more confusing than any number of basic C++ semantics, and it has some fairly substantial benefits, in that it e.g. allows people to write libraries to "extend" the apparent interface of a class without forcing users to use two entirely different syntaxes. Just being able to turn instances of baz(bar(foo(ob))) into ob.foo().bar().baz() would be worth it to me.
  • phkahler 12y ago
    >> Just being able to turn instances of baz(bar(foo(ob))) into ob.foo().bar().baz() would be worth it to me. That's funny because I thought he was trying to suggest nobody use the . notation any more, while you give a nice example of going the other way.