letzjuc · HackerTrans

> how a container is searched should be abstracted away in the container's implementation

lol, no, god no. I think you got the STL completely wrong.

letzjuc

12 anni fadiscuss

Indeed. It should be:

>TL;DR: concurrency is unspecified in _C99_.

Since it is specified in C11's memory model.

letzjuc

12 anni fadiscuss

Anyone knows why anyone would impose these limits to crowdfunding?

letzjuc

12 anni fadiscuss

In a non-deterministic garbage collector memory _might not_ be released when the last reference goes out of scope (and this is often the case).

letzjuc

12 anni fadiscuss

forcing strict evaluation feels like a mess, template haskell feels like a mess, debugging space leaks feels like a mess, not to mention that the haskell learning curve is very high

Haskell is pretty good at a lot of things, so don't misunderstand me, Haskell it's really good! But, at the same time, it still has lots of room for improvement. I guess perfection doesn't exist.

letzjuc

12 anni fadiscuss

Do that and tell us how many people use your language. We'll be waiting.

letzjuc

12 anni fadiscuss

Why use new/delete when you have make_shared and make_unique?

Like 99.99999999% of the time you can use those. Like the only situation where I think they might be not enough is for some weird uses of placement new.

letzjuc

12 anni fadiscuss

> And reference counting also renders the point of determinism moot - now you never know if releasing a reference while trigger freeing a resource.

You know that releasing the last reference will. That is why the important concept is single ownership of resources and not reference counting by itself.

letzjuc

12 anni fadiscuss

>You asked for a situation where the lifetime of a resource can't be directly tied to the lifetime of a single storage location.

I don't think I asked for that but correct me if I did (maybe I'm just not understanding your point).

Anyways, could you elaborate why shared_ptr, unique_ptr, and weak_ptr don't work in that case?

letzjuc

12 anni fadiscuss

The solution above works even if your graph has cycles. Of course if you know that it doesn't you can just build the graph with unique_ptrs.

letzjuc

12 anni fadiscuss

It's simple. The key is that something has to have _ownership_ of the products. [1]

User decides to view a couple of orders. Orders reference products. Those products are managed by something (e.g. an unordered_map of shared_ptr). The order can check, is my product there? If so, i'll copy the shared_ptr to it. Otherwise, I create a shared_ptr for a product and store a copy in the manager. When the order's destructor is triggered, you check the count of the shared_ptr. If it is 2 (i.e. the order and the manager), the order removes the shared_ptr.

[1] Single ownership is the key concept, not reference counting which is just an implementation detail.

letzjuc

12 anni fadiscuss

Could you elaborate?

letzjuc

12 anni fadiscuss

I fail to see why you need cycles' support for that.

letzjuc

12 anni fadiscuss

Have a vector of shared_ptr that own the objects in the graph and build a graph with weak_ptr ?

Removing an object is just as easy as removing an element from the vector. (If you test the weak_ptrs on use, that's actually the only thing you would need to do).

letzjuc

12 anni fadiscuss

Then the lists should only have a weak_ptr to the object.

Something is handling both list [1], that something could own the object, or maybe something external to that. Giving ownership of the object to both list is a design error [2].

[1] e.g. if the two list are an implementation detail of a data structure, the data-structure itself could own the objects in the lists.

[2] Do non-deterministic garbage collectors that handle cycles allow you to have a resource with multiple owners? Yes. Should you do it? No, god, please don't.

letzjuc

12 anni fadiscuss

Because it is deterministic? (i'm just guessing that what you call "proper" garbage collector is non-deterministic).

Furthermore, the only "advantage" I see in garbage collectors is that they can deal with cycles.

I say "advantage" because i'm of the strong opinion that having a cycle in your code is a software design error.

letzjuc

12 anni fadiscuss

In Germany I get paid around 3.500 Euro brutto per Month for pursuing my PhD at my university. Same conditions as the parent post: expected duration 5 years, 20% work time dedicated to university,...

That's around ~44.000 Euros per year (including perks).

I interviewed in 4 companies before deciding to go for the PhD (all engineering jobs). The salaries varied from 45.000 to 55.000 Euros brutto per year, with one offer at 60.000 Euros.

Friends working in industry make around 50.000 Euros which matches with my experience. Making a bit less for working in _your_ PhD is a really good deal here. If you find the right PhD for you it can be very gratifying (plus you are working for yourself). OTOH my friends in industry work way less hours than I do, so if I had a family I would probably had never gone the PhD way.

letzjuc

12 anni fadiscuss

well there is clang-format and clang-tidy and they are really easy to set up in CMake (I use "make format").

letzjuc

12 anni fadiscuss

This is no gotcha; he deliberately shoots himself in the foot by using a "weird" integer type. The right solution is to use value_type from container/iterator_traits (that is what it is there for):

    accumulate(begin(v), end(v), value_type{0});

Suggesting 0LL is just calling for trouble when someone realizes the vector didn't had to be long long and forgets to change the initialized value.

IMO one of the huge screw ups of the design of the STL is making sizes unsigned. It means that you get a compiler error when writing:

    for(auto i = 0; i < vec.size(); ...) {...}

since i and size() have different types. The worst part is that unsigned doesn't buy you that much (only twice as many elements).

The lesson to be learned here is: don't use weird integer types unless you really need to, and then, you should know what you are doing. E.g. if I need a long index then I use

    using Idx = long long;
    accumulate(begin, end, Idx{0});

when I'm hacking, and

    struct unique_tag {};
    using Idx = arithmetic_type<long long, unique_tag>;

when I'm serious to disable all implicit conversions and make these types of errors impossible.

letzjuc

12 anni fadiscuss

> but I don't think "Run your code through a formatter when you're done hacking it together" is a viable, maintainable, or scalable policy.

Just hook clang-format or clang-tidy with your build system. A lot of projects do it.

You will be surprised how inconsistent people actually are, even in project where almost everyone is sticking to these practices at 100%. And the larger the project, the worse it gets (most people are inconsistent in different ways).

The only way to get this right is to either produce hard errors when they are violated (e.g. your code won't compile, or won't be committed) or do it automatically. clang-tidy is just the way to go.

comments