Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jun 2000
Offline Last Active Yesterday, 10:12 PM

#5291210 Operating System Questions in Assembly

Posted by ChaosEngine on 11 May 2016 - 03:21 PM


Based on your question, I think you should step back and evaluate your ability to complete this project.

Honestly, you are building a space shuttle and you've just asked about spray painting the NASA logo on the side.

The OP is (according to their profile) thirteen. Personally, for that age group I find it advisable to just give them the information desired and let the empirical values of something deceptively simple-sounding become a huge problem be a first-hand experience. We get a lot of older people who really should have learned that lesson earlier.

It's not even wasted time (especially at that age). You will be gaining skill points all over the place while working on it even with the originally intended goal not achievable.


I disagree. When I was that age, I was constantly trying to build things way beyond my ability, and similarly, I would focus on the "fun stuff", because the actual work frustrated me.


This was before the internet, so I didn't really have any help other than whatever books I could find. So I basically gave up in frustration, and didn't get back to programming until years later.


I really wish someone would have said to me "look, try something more manageable". 

#5291020 Operating System Questions in Assembly

Posted by ChaosEngine on 10 May 2016 - 02:25 PM

Based on your question, I think you should step back and evaluate your ability to complete this project.

Honestly, you are building a space shuttle and you've just asked about spray painting the NASA logo on the side.

I'm not trying to be mean, but I think you've seriously underestimated the difficulty of what you are trying to do.

#5288690 OOP and DOD

Posted by ChaosEngine on 25 April 2016 - 06:42 PM


But one must have a reasonable grasp of where performance is critical -- it would be unwise to program every part of your program at every level as if DOD is necessary or desirable in the same way that writing the entirety of your program in Assembly language would be -- in theory, you might end up with the most efficient program possible, but in practice you'll have put an order of magnitude more effort into a lot of code that never needed that level of attention to do an adequate job, and you'll have obfuscated solutions to problems where other methods lend themselves naturally. For instance, UI components would gain nothing by adopting DOD, yet a DOD solution would likely give up OOP approaches that fit the problem so naturally that UI widgets are one of the canonical example-fodder used when teaching OOP.


QFT. One of the reasons that DOD is still relatively unknown outside of certain areas (game programming, high-performance computing) is because it solves a very specific problem: memory access bound performance.


But for the vast majority (IMHO) of software written today, CPU/memory bound performance is an order of magnitude less important than the much lower bandwidth issues (data access, network access, etc).


Most "typical" business software spends its time waiting for database queries or REST APIs to complete. If DOD improves your algorithm even by 1000%, that's not going to help much if the total time spent waiting for process x to complete is 90% dependent on a high latency process.  


I'm not arguing against DOD; it's very good for it's intended purpose. I'm simply attempting to explain why it's not more widely known.

#5282763 Naming conventions, software documentation and version control

Posted by ChaosEngine on 22 March 2016 - 05:37 PM

Why is it that so many C++ programmers choose a Java style

Simple. They find className.doSomeThing() more readable than class_name.do_some_thing().
That's it, and it's a perfectly valid reason.

and (often) also throw out any and all uses of the standard library

Lots of reasons ranging from the good (they've profiled their code and found that the standard library is causing problems and are expert enough to replace it) to the stupid (NIH, don't understand how it works, etc).


Most of them are probably more on the stupid side though.

#5282553 Naming conventions, software documentation and version control

Posted by ChaosEngine on 22 March 2016 - 02:24 AM

If you're using a versioning system (as is likely the case if you're hosting your project on Github), you don't need to worry about backups - the versioning system provides them for you.

Version control != backups. You need both.

Yes, if your version control is offsite (e.g. GitHub), then they SHOULD be taking care of the backups, but it's important to recognise the difference.

#5282256 (split thread) c-style casts

Posted by ChaosEngine on 20 March 2016 - 07:59 PM

Re: const. const is not really meant as an aide to the compiler, but to the programmer.


Some have argued that variables should be const by default, and mutability should be explicitly declared.


Yep, I'd be one of those.

#5282194 (split thread) c-style casts

Posted by ChaosEngine on 20 March 2016 - 03:52 PM

I have one good reason for favouring C++ style casts. They're way easier to find.


Want to find all the casts in your code base? Search "_cast<". Now tell me how to do that with c style casts.


And quite frankly, anyone who uses "because they're quicker to type" should never be allowed program again. 



In a magically "perfect" codebase, you probably wouldn't need to cast. But the real world is messy and imperfect, so of course it happens.


But C++ casts make it way easier to spot.

#5278160 "Modern C++" auto and lambda

Posted by ChaosEngine on 25 February 2016 - 02:34 PM

If you remove the standard c++ library


why would you do that?




Are anonymous functions really THAT COOL?


Yes. The same thing can be achieved with functors, but lambdas are an order of magnitude less verbose.




And how is auto easier to read?



std::vector<std::string, SomeCustomAllocator> strings;

// which is easier to read
for (std::vector<std::string, SomeCustomAllocator>::iterator itr = strings.begin(); // etc

// or
for (auto itr = strings.begin(); // etc

Sure you can solve this problem with typedefs, but does 

for (StringVecIterator itr = strings.begin(); //

really add any useful information to the code as you read it?


edit: damn... ninja'd! ph34r.png

#5276192 Pointers: "type* var" versus "type *var"

Posted by ChaosEngine on 17 February 2016 - 03:13 PM

I'm an int * foo guy all day long!

You're multiplying int by foo? 


Seriously though, I'm with ApochPiQ. Just use whatever the code is already using.


Even more seriously, I'm with Hodgman and anyone who uses anything other than type* var is a terrible human being and should be ashamed. laugh.png

#5272123 Python for 1st language?

Posted by ChaosEngine on 21 January 2016 - 04:40 AM



I recommend learning C.

I recommend the OP not do this. I also recommend that the OP only uses the tools needed to do the job and do the job well. C does not fit that criteria.
[moderator edit]
C is a good choice by all means. You did not state a single reason not to.

Pointers. No string type. By themselves, those are reason enough for a beginner not to use C.

Fundamentally, you spend more time fighting the language than learning to program.

Oh, and for the record, I started in C.

#5270988 Why does MSVC warn that "not all control path returns a value" with e...

Posted by ChaosEngine on 13 January 2016 - 07:34 PM

In such situations, according to just war theory, the compiler would be justified in morally obliged to intentionally sabotage your code and/or poison your dog.



#5268793 Practicality of a C++ Garbage collector

Posted by ChaosEngine on 02 January 2016 - 12:03 AM

In game development (or other high performance computing) understanding memory ownership is crucial to writing efficient code.

For most other tasks, it simply gets in the way, and worse, forces you to think in the language domain instead of the problem domain.

But that's why we have different languages. ):

#5268386 How would you create a Weapons class?

Posted by ChaosEngine on 29 December 2015 - 03:11 PM

It depends. At a very basic level, do weapons have different logic/game rules or do they simply have different properties that are applied by the same rule?

Instead of inheritance can you apply composition? For example, let's say you can have a sword, and a flaming sword. A naive way to model this would be
Weapon <- Sword <- FlamingSword
Later on, you decide you want a poison sword. No problem just add it to the inheritance tree, right?

Weapon <- Sword <- FlamingSword

Except now, every weapon branch has three classes (Dagger, FlamingDagger, PoisonDagger, etc)

Then what happens if you want a FlamingPoisonSword? It's the dreaded diamond inheritance pattern.

Instead, you could model your Weapon class with a DamageType component (I.e. Edge, Bludgeon, etc) with optional effect slots (Fire, Poison, etc).

And that's before we even get into data driven modelling...

#5266157 GUI elements whose positions depend on one another

Posted by ChaosEngine on 13 December 2015 - 02:29 PM

OP, there are several open source GUI frameworks that have solved this very problem.


Why don't you have a look at the code for QT or WxWidgets?

#5264481 a good source for learning to write advanced sql queries

Posted by ChaosEngine on 01 December 2015 - 03:58 PM

As much as I hate lmgtfy responses, I will have to agree with ChaosEngine.

I don't normally do them unless (as in this case) the OP has put zero effort into researching the question before posting.