raddevus wrote: well they didn't entirely abuse me. You obviously weren't trying hard enough! :laugh: "These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

This forum is for bugs and suggestions with the CodeProject website. For discussing CodeProject.AI, there is a dedicated forum: CodeProject.AI Discussions[^] "These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Let me expand a bit on my previous answer[^]. As I said, you can convert a pointer (or reference) to pointer (or reference) to the base class. This called "upcasting" because you are moving "up" in the inheritance tree. The conversion is "non-destructive", in other words you can later on "downcast" (move from base to derived) as long as you know what type of object was in the first place. An example: struct Unit { Unit (int tag) : dog_tag(tag){}; virtual std::string kind () = 0; int dog_tag; }; struct Soldier : public Unit { Soldier (int tag) : Unit(tag) {}; virtual std::string kind() {return "soldier";}; float running_speed; } struct Sailor : public Unit { Sailor (int tag) : Unit(tag) {}; virtual std::string kind() {return "sailor";} int life_jackets; }; std::vector actors {new Soldier(555), new Sailor(666);}; int main () { Unit* u0 = actors[0]; std::cout << "Actor 0 is a " << u0.kind() " with tag " << u0.dog_tag << std::endl; If you would look with a debugger at u0 you would see a memory layout something like this: u0 0x1234 -------> pointer to vtable of Soldier dog_tag ----------------------------- running_speed ------------------------------ You can see now why the code works: no matter what kind of object you deal with, the first part of the memory layout is the same. Compiler simply ignores whatever is after the dog_tag field. A few more lines of code (please ignore that I didn't initialize other fields): Soldier *s = (Soldier *)u0; std::cout << "Running speed " << s->running_speed << std::endl; s has exactly the same value as u0 but compiler considers it a pointer to a Soldier object so it uses the value from the running_speed field. I could have written: Sailor *ss = (Sailor*)u0; std::cout << "Sailor has " << ss->life_jackets << " life jackets"; And compiler wouldn't have cared at all. It would have accessed the memory at lif

Thank you for your comment.

I have those same skills at the same levels! But the thing about CAD/Blender/Max/Maya etc... you can't really get that so wrong. The visuals constrain physics impossibility (no Escher stuff). The rest is 'hard' science. How many millimeters is this edge? etc. Of course, then you're also adding another skill to learn more. But I figure you won't mind that so much.

There I go, hallucinating wrong answers again. :sigh: TTFN - Kent

Chad3F wrote: If you felt like using those worthless (and probably very unreliable) SD cards to mess with people, They're only unreliable if you buy 1TB ones from China for $12. All my MicroSD cards are still functional and reliable. You get what you pay for. And why revive a nearly month-old thread for something nefarious like this?

For sure, a laser printer works much more decently. Despite of this, I should be interested in finding somebody able to repair an Epson LQ100. A little noisy, but worked more than 20 years with no problem. And it does not make a topic of having been unused three months long.

Ah memory leaks (and small buffer overruns). I would point out that your example is fairly obvious. If you have a long running task, and this code is in some sort of processing loop, you'll see it quickly. What will really bite you in the a$$ are the small leaks. A byte here, a byte there. I live in the embedded world where customers forget our equipment was installed under their production line 10 years ago. The engineer responsible either died, retired or moved on to another company. I'm not being morbid, I have stories I could tell you :) The group I work in is a decent group of smart people. Sadly, they never let us into the field to see how the product is actually used. The few times I've seen examples, they always shock me with "I didn't see that coming" sort of response. What amazes me is that if your customer never turns off your machine, why not set up an area where a test unit runs forever? I guess it falls under diminishing returns. Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.

That was the old solution, but it had serious problems with USB (essential for the test equipment). Also, the VMs turned out to be huge, and we had created lots of them. The hope was that containers would create an environment restricted to the tools and their runtime requirements - presumably a lot less than than the full VM OS environment. I believe they found a cure for the USB problems, and disk space was getting cheaper, so maybe they did resort to VMs after I left the company. Picking up a ten year old VM could cause more friction than just running an old container - well, that's what we thought, and it turned out to be wrong. Maybe Linux can run any and every ten year old container. Maybe your favorite VM manager can run any and every ten year old VM image. So maybe reverting to the old VM solution was a wise solution. Yet, I would certainly want to see that 10 year old solution running with all the physical interfaces (USB was only one; we still were using RS232 COM-ports, and software mapping 4 COM-ports to a single D25 LPT-style port). I am not at all sure that the old VM solution really could solve all the issues we encountered when running containers. Whether VMs were a good solution or not: The container solution was not a good one. And then I left the company, leaving them to choose their future path without my competence. Visiting them again and ask them to show how they rebuild a ten year old system might be an interesting exercise! Religious freedom is the freedom to say that two plus two make five.

Uncategorised posts can refer to various topics that may include game updates or tips. In the context of the Bus Simulator Ultimate mod APK, these posts could provide players with insights on gameplay strategies, mod features like "no damage," or community discussions, helping to enhance their overall gaming experience and knowledge.