Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Should Be C++

open-std.org

Post reply on HN
Print view View original

161–170 of 191 posts

Re: C++ Should Be C++

#161

Post by Sankozi »

eej71 wrote: post #102
29athrowaway wrote: post #29

If C++ wants to continue evolving, it needs breaking changes. It needs to impose a migration duty to the user, but that is not going to happen. So it will die a death by entropy where noone can know the language.

I think the great challenge with breaking changes is demonstrating how other systems have done breaking changes with great success. They are quite rare. And no, the python2->python3 migration is not one of them. Neither is ip4->ip6.

The important part about breaking backward compatibility is allowing forward compatibility. Java is good in that regard, for each breaking change, you could still create a library that worked for Java N and Java N+1.

It is possible to have a network supporting IPv4 and IPv6. I don't think the speed of migration is an issue. It is not a tremendous success but it is not a failure either.

In Python forward compatibility was often impossible. The migration benefit was low and the cost was high. Python is a great example how not to break things. I am little surprised that whole language is still popular after such failure of leadership.

Re: C++ Should Be C++

#162

Post by rightbyte »

CoolGuySteve wrote: post #98
MaxBarraclough wrote: post #93

Earlier quoted context omitted.

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

No, C is not the same as it is less expressive. C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros. See elsewhere in this thread for discussion of boost, it's not applicable.

In practice the Sufficiently Smart Compiler will have a hard time optimizing all these layers.

C macros are way simpler as they are only text. I still use them alot in C++.

Re: C++ Should Be C++

#163

Post by menaerus »

zozbot234 wrote: post #34
CoolGuySteve wrote: post #24

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application. Things like: shared_ptr eagerly using…

Why does this have to be part of the standard library? Isn't that the whole point of Boost, that one is not limited to what's in std?

Even if somebody put such a thing, or two, in the standard library there would be again someone showing that they managed to come up with a better solution. For their workload. And under constraints that are only valid under their use-case and constraints that only they would know. Not standard library developers. And that's the thing - the premise that "one size fits all" even exists is wrong. I used to think that way as well but generic solutions to high-performance algorithms do not really exist.

Re: C++ Should Be C++

#164

Post by menaerus »

worik wrote: post #42
shortrounddev2 wrote: post #35

Earlier quoted context omitted.

It was my understanding that one can easily add their own allocator to any STL container, though as you point out you have to write that allocator yourself

> one can easily add their own allocator to any STL container, You and I must have a different definition of "easily "

How about this?

  template
  struct Foo {
    using value_type = T;
    Foo() = default;
 
    template
    constexpr Foo(const Foo &) noexcept {}
 
    T* allocate(std::size_t n) {
        if (n > std::numeric_limits::max() / sizeof(T))
          throw std::bad_array_new_length();
        auto p = static_cast(std::malloc(n * sizeof(T)));
        if (!p) throw std::bad_alloc();
        return p;
    }
 
    void deallocate(T* p, std::size_t n) noexcept {
        std::free(p);
    }
  };
And then you go and use it as

  std::vector> v;
So the complexity is not really in writing the "C++ allocator" but in writing a sufficiently complex memory management logic that will actually make your application/algorithm run faster. And that only you can know given that you're familiar with the memory allocation patterns in your code. C++ allocator is only an interface that allows you to capture that logic and makes it feasible to apply through the code.

Re: C++ Should Be C++

#165

Post by viraptor »

worik wrote: post #42
shortrounddev2 wrote: post #35

Earlier quoted context omitted.

It was my understanding that one can easily add their own allocator to any STL container, though as you point out you have to write that allocator yourself

> one can easily add their own allocator to any STL container, You and I must have a different definition of "easily "

If you're in a position where you know you need a different allocator, and you have your own allocator, plugging it in should be relatively easy in comparison.

Re: C++ Should Be C++

#166

Post by UncleMeat »

Kranar wrote: post #78
gavinray wrote: post #72

Earlier quoted context omitted.

> Continue being the fastest systems language possible. If you want to be pedantic -- in theory C++ can never be the fastest systems language possible because of the language's rules about aliasing. You'd need to smatter "_restrict" everywhere to skirt this.

This is not pedantic at all. Aliasing issues are really subtle and hinder so many optimizations. It's not clear that there is a way to even fix this without substantially breaking backwards compatibility.

Yeah the number of cases where otherwise really trivial optimizations are prevented because of soundness concerns regarding aliasing is simply enormous.

Re: C++ Should Be C++

#167

Post by UncleMeat »

josephg wrote: post #99
mxmlnkn wrote: post #51

Earlier quoted context omitted.

And the additional trade-off that some bugs are only noticed at runtime when that particular line is executed while it could have been noticed by the compiler of a strongly typed language. Pytype helps but at this point you have a static analyzer that potentially runs as slow as a compiler without the additional performance benefit.

There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

It isn't just that, but there are a number of ways that templates can cause superlinear type checking behavior.

Re: C++ Should Be C++

#168

Post by fluoridation »

bsder wrote: post #136
josephg wrote: post #99

Earlier quoted context omitted.

There’s no good reason for type checking to be super slow. I’m no fan of Go, but the language compiles insanely fast while being fully statically typed. As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. This isn’t a problem with static typing. It’s a problem with C++, and to a lesser extent C.

> As I understand it, C++’s slow compilation comes from the fact that it usually parses all of your header files n times instead of once. Sort of. The primary issues are: 1) The C/C++ grammar is garbage. Note that every single modern language has grammatical constructs so that you can figure out what is "type" and what is "name" without parsing the universe. "typedef" makes that damn near impossible in C without pars…

1. No, the grammar is not the issue per se. As you say, C has the same problem, and C code invariably compiles dozens of times faster than C++, and both Zig and Rust have modern grammars, but Zig compiles about as quickly as C and Rust is only somewhat faster than C++ (depending on features used).

2. This is incorrect. What's happening is that each template instantiation for a new set of template arguments requires reprocessing the template to check types and generate code, and also that is done per translation unit instead of per project. Each distinct template instantiation increases the compilation time a bit, much more than it takes to parse the use itself. That's why it's easy to have a small C++ source that takes several seconds to compile.

Re: C++ Should Be C++

#169

Post by Joker_vD »

menaerus wrote: post #160
einpoklum wrote: post #120

Earlier quoted context omitted.

Allocators have an inherently broken design, tying them to types. See this CppCon talk by the (engaging and funny) Andrei Alexandrescu: https://www.youtube.com/watch?v=LIb3L4vKZ7U std::allocator is to allocation what std::vector is to vexation (or: designing allocators that don't not-work)

If the allocator is unaware of your type, how do you initialize the underlying object? That is - how do you invoke the default or non-default constructor of type T over the memory region you just allocated?

That's not the allocator's job, is it? It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

Re: C++ Should Be C++

#170

Post by fartsucker69 »

MaxBarraclough wrote: post #93
CoolGuySteve wrote: post #24

> It is easy to see that C++ is fit as a general-purpose programming language–adoption by millions is a testament to that. I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. Everywhere in the std lib you can see compromises that require rewriting substantial portions for any real time application. Things like: shared_ptr eagerly using…

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but: > I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible. You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs. C++ is at least still pretty committed to the you only pay for what you use principle. A…

the only pay what you use thing is bullshit. because everything you want to use actually costs something. the point being that a better implementation would give you the same things without a cost...
Post reply on HN