CyberDildonics

I gave you great information on how to make your queues thread safe again.

I don't know where this expectation comes from that you can reply to me and I can't reply to you. If you don't want to continue you don't have to reply.

This is totally irrelevant because if you paid attention, the problem wasn't even threads. It was concurrency, more abstractly. Iterator invalidation based on the "manifested" order of execution.

This is really just mixing terms. You aren't going to notice all your concurrency bugs without threads. If you're holding a raw pointer to an internal resource of a data structure while other threads can modify it, you aren't going to see all your bugs until multiple threads are modifying and reading from the queue.

If the threads have unpredictable lifetimes, then yes, some form of reference counting is indicated.

It isn't about threads having unpredictable lifetimes, they could all be running at the same time and have predictable lifetimes.

In some cases your data structures might even be so messy that you end up with cycles.

Then don't do that.

Thanks for the pointers to what is probably 5K lines of C++ boilerplate.

Lots of people get a lot of good out of them.

But I have written half a dozen concurrent queues myself,

You might want to benchmark and test those bad boys thoroughly if you think you can hold a raw pointer into a data structure that can change from other threads. If you use a template you won't have to rewrite them over and over.

Also don't forget that allocations can lock and that your double allocations of the struct and data in a data structure can amplify that.

If you want an approachable source that leaves out the fluff,

Thanks, but I haven't made the same assumptions about raw pointers in concurrent data structures then blamed the STL, so I haven't had the bugs that you're talking about here.

This isn't a problem with the standard library because a std::dequeue or any other core data structure doesn't make any promises about concurrency.

You can find details of iterator invalidation here.

https://cppreference.com/cpp/container/deque

If you have an underlying data structure that is being used from multiple threads, you can't hold on to raw pointers into the data structure. There is no way for other threads to know that it can't be changed, moved, freed or invalidated.

You need to copy the data out while a mutex is still locked (if doing simple mutex style concurrency) or you need to hold a reference count in the object that is returned so that the underlying structure knows that it can't touch that data from other threads.

I hope it isn't lost on you that the reference counting approach is much easier to do with a destructor, since the reference count can be incremented before it is given to you from the API and decremented automatically when it goes out of scope.

If you want some good concurrent queues for C++, look at this person's work:

https://github.com/cameron314/concurrentqueue

Which part of the STL are you expecting to be thread safe?

One is is good information from lots of experience, one is "the parts that don't use more cpus don't speed up with more cpus".

Unhelpful nonsense about running software vs battle won experience about making software.

Show evidence of your claim.

That would be proving a negative, which is another logical fallacy.

Please p off man. You're being ridiculous.*

If that were true you could explain why.

I would rather call it _implicit_ flow but they also lead to losing control over control flow because of that

But it's just running something you need to run anyway and it's optional. Destructors don't need branching, they can just run a single function like free.

And then I can also do without RAII and without all the baggage I'd have to buy into in order to use it.

Again the "baggage" is the part you can't seem to explain.

Like you have been on your Linux, Windows, or Mac machine? Maybe you are running a linux machine with an uptime of weeks, months, or even years?

Are you trying to say people never write memory leaks or forget to clean up resources in C? Something being done with huge amounts of efforts doesn't mean a better way to do things is bad.

You claiming to run a marathon with a 25kg backpack doesn't mean you don't lie, and it also doesn't prove running without it isn't the better approach.

This doesn't mean anything. Now you're trying to say (without evidence) that someone is lying? Destructors don't add any size to a program.

Is this your only argument after dozens of messages? Running a function with no branching destroys control flow and running a tiny function that runs what you need to call anyway is bloat?

I've been giving a lot of explanations what I think is problematic,

No, you just said it's problematic over and over, that's not an explanation.

Why don't you do it so you can make your own argument.

Why does it seem like the majority of core infrastructure,

Why are projects started decades not using modern C++ that came decades after they were started?

This doesn't have anything to do with destructors.

The arguments that I've given (but you keep insisting I didn't give them)

You didn't give arguments, you made claims based on other people doing something different decades before modern C++ existed. Someone managing to dig a hole with their hands doesn't make a shovel a bad tool. Animals dig holes all the time, people are better at it.

But if you try to actually implement technically interesting things, it won't help you at all, it's just getting in the way.

This again is your claim which you haven't been able to explain in any way.

I don't think you did, I think you just said it has downsides over and over.

Once again you're explaining beginner C++ do me.

Don't ask for basic knowledge then get upset when you get it.

My response to this was and is, if you have primarily stack scoped lifetimes, you are writing beginner programs.

This is what the vast majority of values have. Some escape one scope and get cleaned up in another one. This also includes values inside data structures.

It's not something I want in general, I think it has more downsides than upsides for the code I'm writing. I've actually tried to use RAII many times and I've concluded it doesn't work for me.

Again, this isn't an explanation, it's just you saying "I don't think it's good, I don't like it", but you aren't explaining why. This isn't evidence, it's just you restating "this is bad". Why is it bad? "I told you it's bad!!".

thus enabling exceptions and implicit or uncontrolled control flow

Exceptions aren't uncontrolled flow and you can also not use them. Something else being enabled doesn't mean the unrelated feature is bad. This also implies that every other language that isn't C is terrible because they have some sort of automatic cleanup. Now java and python are unstructured by your own definition?

If I were you, my response would be: The burden of proof is on you, show the evidence.

You don't have an explanation of why the burden of proof is on me. Everyone uses these techniques in system software now. You are the odd person out, that's why the burden of proof is on you.

I also gave you a very good explanation and you said "you're explaining basic C++ to me". I am, you asked for it and you didn't poke any hole in why it's wrong.

the issues caused by manual cleanup are also somewhat exaggerated by C++ people

It means memory leaks and crashes which everyone has been fighting for 50 years.

This should be plenty evidence to a reasonable mind, but that isn't you.

Someone running a marathon without shoes doesn't mean shoes are bad. Just because an old program is written in C, that has no bearing on if other tools are good or not. This is not a logical conclusion. Unix was written in C too, does that mean destructors are bad? No one said it's impossible to write a program in C now that C++ exists.

Why can't you give a single basic explanation instead of making the same claim over and over?

One is basically 1 + 1 = 2 and the other is a warning of a non obvious situation that comes from lots of experience and effort.

It's completely obvious and the "eventually" is where anything interesting happens. This comes from the early days of computers which is why something trivial became a supposed insight.

For Brooks the communication between people starts to dominate the time spent the more people you add, so it will eventually become the bottleneck.

Not just the communication between people while working in general but the communication to get someone involved in the project weighing down the people who would be making progress.

Feel free to come up with your own conclusions.

I did come up with own conclusion, the only similarity is the word bottleneck.

People use them because by default values have scope based lifetimes and destructors unify the handling of stack based values which require no explicit cleanup with data structures that heap allocate, which require no explicit cleanup once the destructor is implemented.

This is the opposite of C where even though the resource cleanup needs to happen on scope end, it is not automatic, and so becomes a source of bugs. This is exaggerated when there are multiple returns, gotos, macros and other sources of branching especially for error handling.

This automation also removes boilerplate so there is less management that needs to be done when using data structures.

What was your evidence or explanation?

For starters not many people need story boarding.

When someone is actually doing a project that is big enough to need story boarding, they are going to have some infrastructure and making a wrapper around prompting image generation is not going to be far fetched.

The narrow window of productions that are doing story boarding but think they need a tool to wrap image generation and have no one to script some tools themselves is pretty small.

You can predict 250 years in the future now and when 'brain uploads' will happen and when everlasting life will happen and when the harvesting of distant stars will happen?

That's impressive because you've made predictions a year into the future and they never came true.

There is the power board (AC to DC conversion for electronics and leds), video input board (where you plug in HDMI etc) and a t-con board, which takes a single video signal in from the input board and drives the LCD screen.

Then there are a few ancillary components like speakers, maybe a roku module etc. There are easy to find and everything is modular. You can take the speakers out and use them somewhere else if you want. You can just disconnect the wifi antennae on the smart tv board and be done with it. You can also find the IR led connection that the remote sends signals to.

The best way to deal with a TV you don't trust is what no one wants to hear.

Open up the back and disconnect the wifi antenna. It is easy to open them up and everything is pretty simple and obvious once you do.

The mythical man month is about communication between people and the amount of work to be productive in a project. It's about people colliding with programming.

It has nothing to do with a vague statement that "eventually" you have diminishing returns on processors (of course there is some limit even though different tasks could be many orders of magnitude apart).

Then why are you trying to make something?

You claimed there were problems many times for sure, I don't think you came up with any evidence of those problems.

We already have that from a lot of standpoints. Math, routing and the ability to look up all of human knowledge.

We don't think our phones are slaves because they don't have emotions or a nervous system.

No one don't think plants are slaves for the same reason.

This is not a deep or philosophical problem.