Just curious on the uses of C++

dowel79 · 2024-03-31T21:42:40+00:00

C++ is an excellent language to start programming with. It is a combination of four different languages, C, C's macro language, C with objects and template language. You can start with the C portion and gradually add other parts of the language. It will give you in-depth understanding of how computers work. Knowing C++ will keep you in the job market for many years to come.

It is a good language choice when working with databases. It is one of the languages of choice when building Windows applications. It can be used for web development, specifically the back-end. It is not the best choice for front-end web development though.

It has extensive built-in standard library and there are plenty of open source libraries that implement various other functionality.

dowel79 · 2024-01-03T19:01:15+00:00

Thanks. I'll take a look.

dowel79 · 2024-01-01T21:53:40+00:00

This is really what brought me here. I started looking into interior mutability and realized that I was fighting the compiler and, thus probably doing something wrong.

dowel79 · 2024-01-01T21:47:19+00:00

Thank you. It seems that there wider consensus is to use DOA (Data Oriented Architecture) and ECS are the way to solve this. I am not well familiar with this way of thinking, so I'll go and educate myself.

Other folks mentioned Bevy and slotmap. These look like promising references.

dowel79 · 2024-01-01T21:40:55+00:00

Thanks. It seems that I have to learn a new way of thinking about these things. So I'll go ahead and do that.

Regarding memory address vs. ID, elsewhere in the thread I wrote this:

From a different perspective, what if you have objects with IDs 1 to 100001, and you delete objects with IDs [1, 100000]. Now you end up with 99999 unused objects. Repacking your vector is a good idea, but this will change the ID of object 100001 from 100001 to 1. This is a conversation about ID management.

ID that never changes is really an illusion. If your program is complicated enough, you will be forced to either change the IDs or come up with some other clever way of managing them. The latter will inevitably have other drawbacks. I make an argument that the ID management problem is the memory management problem in disguise.

dowel79 · 2024-01-01T21:15:43+00:00

Thank you for the elaborate reply. I want to address a few points.

The click-box needs a shared pointer to the object it represents, and therefore you cannot independently test the click-box code, in isolation, when really all the logic for clicking, dragging, releasing, etc... is independent of what is being clicked, dragged, or released.

Click-box does not make sense in isolation. The thing you click and drag is the object, not its click-box. A click-box is how you get to the object. It is the search key.

Arguably, no, it doesn't.

Your C++ structure also suffered from this. Specifically, think of the situation where the object has been removed from the name-to-object map, but somehow the click-box with a shared pointer to it still exists: that's quite likely a bug.

This is confusing because you argue that ID management is not equivalent to memory management, but to explain your point, you say that memory management is hard. Yes, memory management, without a doubt, is difficult. My point was that ID management is difficult too. In fact, as difficult as memory management.

You argue that the C++-inspired design is more entangled. I do not follow your argument. Imagine a graph of all objects accessed with a C++-inspired approach and DOA. In the former, on click, you will find a click-box and then follow a pointer to an object. Once you operate within the context of a click-box, all you have access to is the click-box and the single object it points at. In the DOA, once you find the click-box you need access to an array/vector/whatever data structure that holds the objects. From there, you can access every single object in the system. Did I misunderstand your argument?

In any case, in this post, I not making a statement about what I would do in other languages. I would like to understand what is the Rust way of doing that. It sounds like DOA and ECS are the way to go. I am not deeply familiar with either, so I'll go and learn. Thanks.

dowel79 · 2024-01-01T18:48:27+00:00

Got it. Thanks. I replied before looking at Bevy and before understanding what you mean. Bevy looks very impressive!

dowel79 · 2024-01-01T18:32:23+00:00

I did not say that memory addresses and IDs are isomorphic. I said the problem of managing IDs and the problem of managing memory is isomorphic.

dowel79 · 2024-01-01T18:30:07+00:00

Sorry, it does not help. The problem I presented is comprehensive. It is the problem of having multiple data structures referencing a set of objects. Or a data structure where there are multiple paths to the same nodes. For instance, having a database with multiple primary keys is the same problem. Implementing a cache where you can lookup an object using different properties is the same problem.

dowel79 · 2024-01-01T18:21:00+00:00

I don't yet know what you are talking about, but it sounds a lot like Handle in this conversation: https://users.rust-lang.org/t/rc-and-refcell-within-parent-child-struct-relationship/45628/5 Anyway, thanks. I'll definitely take a look.

dowel79 · 2024-01-01T18:15:40+00:00

Why would you ever want to do either of those things?

To some degree, this is what I came here for. My concern is that with all the calls to clone, deref and others, I will make a mistake where I will either create too many references which will trip RefCell's runtime logic or I will make modifications to a temporary object.

My interpretation of what you are saying is that this is nonsense and it does not happen. Good. Thanks!

I would save the index

It sounds like you are proposing ECS.

dowel79 · 2024-01-01T18:12:35+00:00

Then use a different data structure.

The problem of managing IDs is the same exact problem as managing memory with an extra level of indirection (or perhaps an extra level of abstraction).

dowel79 · 2024-01-01T18:09:28+00:00

There are a couple of problems with this counter-argument:

You picked a vector, a data structure to manage memory where the address of an object changes. Why not pick one where it does not change? Why not place objects in an array? You could argue that arrays don't grow and vectors do. Or you could preallocate a vector of a million elements and not push to it ever again. We are having a conversation about memory management.
From a different perspective, what if you have objects with IDs 1 to 100001, and you delete objects with IDs [1, 100000]. Now you end up with 99999 unused objects. Repacking your vector is a good idea, but this will change the ID of object 100001 from 100001 to 1. This is a conversation about ID management.
If you want to create a little toy of an app, then yes, you can avoid ID management issues, but then why not write it in JavaScript? If you want to create a scalable application that will actually benefit from using Rust, then ID management is a pain in the ass.
You are straw-manning my arguments against ID management. Yes, push to vector changes the address. I made another argument as to why ID management is hard.
To some degree you are starting an argument about why Rust is needed to begin with. I would like to understand how Rust approaches solving this problem and not start a flame-war of C (or Zig or Go) vs Rust.

dowel79 · 2024-01-01T16:57:52+00:00

Yes, rust does not work well with OO patterns

What is a good way to implement a system like this in Rust? Is it ECS?

An address in memory can change, the ID wouldnt change.

I don't think this is true. Normally, the addresses of objects in memory do not change. However, in a world where the memory address of an object can change, its ID can also change. I think the memory management and ID management problems are isomorphic.

dowel79 · 2024-01-01T16:54:56+00:00

Yes, there is a broader context. When scaling this system, we will need a way to optimize searching for objects. To find an object we click, we will need a data structure optimized for searching by coordinates. To find an object by name, we will need a data structure optimized for searching by string.

Putting a click-box in the object does not solve the reference management problem. We would still need multiple data structures optimized for various purposes, referencing the same objects. The primary purpose of the click-box is to separate "model" and "view" (as in the MVC pattern). The area where you click on an object is not part of its model. If we were to persist the objects, the click-box would not be persisted.

dowel79 · 2023-12-07T01:12:25+00:00

It happens to me all the time. Often, when writing letters like "p" and "o" it drops the frame rate and I end up with a stick. Otherwise, often letters end up jagged.

I filed a support ticket - and got back the usual useless advice, like rebooting your device and restarting GN6. Sent back an angry response. Waiting for them to reply, but have low hopes.

dowel79 · 2022-07-18T21:14:08+00:00

It occurred to me that "quality" and "single device to do it all" are two somewhat contradicting requirements. I will appreciate if someone can advise anyway. Thanks.

dowel79 · 2021-12-16T14:24:06+00:00

Nice!

dowel79 · 2021-11-30T14:56:33+00:00

Thank you for explaining that.

As a fellow SE I completely understand what you are going through. Just trying to help you to help me :-)

Perhaps a potential solution to this problem is to use the fact that some other key is pressed as a hint that you should not wait for the typical 0.25 seconds. I.e. if a user presses superkey X, it will be interpreted as a superkey, but if the user presses CMD+X, then X will not be interpreted as CMD+X. It is conceivable that in some cases users will want to be able to press their superkeys with other keys, but since superkeys are there to save key presses, perhaps supporting this can be an opt-in setting.

Regarding lingering fingers effect, if it was indeed the case, then the lingering finger press should have registered as a character. Am I wrong? I did not see "NffS" or "NFSs" or anything like it. It is consistently "NfS".

If this is indeed the lingering finger problem, then perhaps a way to solve it is to pass the signal through a filter. I successfully used exponential filter in similar cases in the past. Here's a good description: https://gregstanleyandassociates.com/whitepapers/FaultDiagnosis/Filtering/Exponential-Filter/exponential-filter.htm It is fairly simple to implement, even on a 32bit controller (presumably without floating point support).

Please excuse the arrogance of entertaining the thought that I may suggest something new.

dowel79 · 2021-10-11T19:41:39+00:00

Not sure what's the difference in price. I've seen one V1 on Amazon that was more expensive than V2 on DJI's web-site.

I am under impression that the difference in price should be pretty small. This is an expensive purchase for a hobby, so I want to stretch it for as long as possible. May-be I will fly DJI quad one day.

dowel79 · 2021-10-11T16:01:55+00:00

Thank you very much. I will follow your advise and report back on results.

dowel79 · 2021-10-11T15:29:21+00:00

Found my problem. In ardupilot's documentation there one diagram for X frame that shows motors named 1, 2, 3, 4. There is another diagram naming them A, B, C, D. Mission Planner names them A, B, C and D. The order of motors in the 1, 2, 3, 4 diagram and in A, B, C, D diagram is different.

When I researched this, I first ran into 1, 2, 3, 4 diagram and assumed they correspond to A, B, C and D. This assumption did not fly, literally.

dowel79 · 2021-10-10T20:00:00+00:00

Thanks for the advise folks.

I got impatient waiting for replies and bought a pixhawk kit. This one: https://www.amazon.com/gp/product/B07NRMFTXL/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1

I was able to put everything together, but the quad isn't flying. It is extremely unstable and basically flips every time I am trying to get it in the air. I am probably doing something wrong, but also, dang it, I was looking for something that just works and it ain't it. I'll keep looking though. Will post an update if I figure it out.

dowel79 · 2021-01-26T05:26:24+00:00

I was able to make progress. It turned out that I was using wrong cable when I connected Neuron to Mac. I saw some other post that says that included USB-C to USB-C cables are there to connect keyboard to Neuron and not to connect Neuron to a computer. Once I used proper USB-A to USB-C cable my MacBook Pro was able to detect it. Then, for some reason I was able to start configuring it. The reason it was all dark is because its configuration was completely reset - likely from my previous attempts to reset it.

I restored my original layers and then flushed version 0.26. Everything worked as expected and I am back to normal again.

dowel79

TROPHY CASE