aregee

Members
  • Content count

    225
  • Joined

  • Last visited

Community Reputation

1072 Excellent

About aregee

  • Rank
    Member
  1. I thought I would tip you off to these excellent videos that explains what you are asking about.  You will see why the data probably is already in the processor by the time the CPU executes the instructions needing those registers.   https://www.youtube.com/watch?v=qZTt8JtQOmw   https://www.youtube.com/watch?v=TJq5FE7jGzU
  2. When you realize how dumb a bug is...

      Why the heck would somebody declare a variable that is a lowercase 'L'?  I'd be mad at the single letter variable name declaration.      I'm more curious to know why one would type the lowercase L instead of the 1 in the first place, given that at least on a QWERTY keyboard they're practically on opposite sides of the keyboard.     I was thinking the programming world's version of a troll.  :D
  3. Too clever...?

      Oh dear.  :D  Yes, that is overly clever.  Not sure if it is any more efficient though.  The first one seems to even have a bit more overhead than 5 if tests, the second one gives me a feeling to be at best just as good.  I don't know the underlying behaviour of either is_sorted or the Python style chained comparisons, though.
  4. Too clever...?

      Yes, you are right.  I was thinking to myself that if I made them unsigned, I wouldn't even need the test for 'less than 0', since that would never happen in that case anyway.   EDIT: Sometimes I just mindlessly write code, but today I just had an epiphany.       Yes, I have had my dose of try..catch with Java back in the day.  It is something I try to avoid, unless something really bad happens in the code, but I do see its use.  Not sure why, but even 25 years back in time when I first learned Pascal, I tended to stick with the functions that didn't throw exceptions if for instance a file could not be found.  Really never been a fan of exceptions.  I think the main reason is that I think it clutters the code too much.   In java you even have to wrap string to integer conversions in a try...catch clause...  I always was amazed by that even the "simplest" of operations has to be wrapped in exception handling in Java.  You can probably guess that it is not my favourite programming language.  If I were to rank, it would be c#, and Swift looks promising too, but both are (or have been) traditionally been tied to a single platform.  So here I am with my second or third best: c/c++.   EDIT 2: Oh, yes, I get why you mentioned exceptions now.  You are probably right that it is better to throw an exception rather than returning an arbitrary 'negative 1', or pass a value by reference to see if the operations succeeded or not.  I still have a bad feeling about using too much exceptions though.   I know I am not alone in feeling this way.  The whole Objective-C setup that Apple provides, is built on the assumption that excessive exception handling is evil.  Having pass by reference error values is the rule rather than the exception there.   Then you have the reversed way where you return an ok/error code and pass the returned index as a reference.   What is best practice?  Is there even such a thing in this regard?  Swift can return tuples.  That is a nifty thing.  Too bad I am reluctant to be tied to a system that is so locked to one platform and one platform only.
  5. Too clever...?

    Just writing a simple string tokeniser from scratch, when I came to a "clever" realisation when it comes to bounds checking.   Say you have a string of a certain length, and you want to find a token within a section of the string, you would provide an index for the first character position you want to search from and another index for the last character in the string you will be looking.   Then you need to verify the sanity of these values.   The immediate way to do that would be to just check each first and last bounds to the length of the string and check that the last bound index is not before the first.   Then I came up with the following optimisation: static inline int findToken(const int firstIndexInclusive, const int lastIndexExclusive, const std::string string, const std::string oneOfChars) { unsigned long stringLength = string.length(); if ((firstIndexInclusive < 0) || (lastIndexExclusive > stringLength) || (lastIndexExclusive < firstIndexInclusive)) { return -1; } //searching for occurence of any of the 'oneOfChars' here return 0; } Just three tests accounts for all the boundaries that you would normally check against, which in normal cases I would probably have 5 checks for.   After the first bit of cleverness subsided, it came to me that the readability goes down, the optimisation is rather minor unless if I process a lot of text, although the time I spent making this was not much.  Besides, I think that if you do obvious optimisations while you write code, that is a good thing, but the readability factor is an issue to me.   What do you think?  Is this premature optimisation?
  6. Thanks for your suggestions.  I went with forward declaration.  I did actually try to forward declare the template class, but it didn't occur to me that I needed to forward declare the Point class too.  After I did both of those, everything compiles fine, and now I have lots of nice points showing up on my screen.   Now I will move on to make a scripted math library to move those dots around plus researching how I can make a fast 2D picking algorithm for a massive point cloud.  Probably will be much fun to see it all in action.   EDIT: Strewya: Thanks for best practices.  I always do forward declare functions, but that I in certain cases need to forward declare classes is a fairly new thing to me.  
  7. I had a feeling that the order or place I included header files had something to do with this issue.  I tried to move the following lines from the implementation file to the header file: #include "Node.h" #include "Point.h" It solved the problem  even though everything should really be in scope anyway.  That makes for a different question that I tried to research the other day:   I noticed that Xcode likes to put include files in the header file.  I thought that they should be put in the implementation file, so I did look it up.  It seems that most people agree that they should indeed be in the implementation file, but...   That leaves me two questions: 1. Why does Xcode put the #includes in the header file when they seemingly should be in the implementation file? 2. Can anyone kind, please link me to a good explanation what is 'best practice'?
  8. I am trying to make a circular doubly linked list, and thought it was a good idea to implement it as a template, since I will be using this kind of lists in my project.   The problem is, that while I think to my understanding that I have done everything right, my compiler beg to differ.   The error messages I get are:   - "Unknown type name 'node'" - "Expected member name or ';' after declaration specifiers"   I get these two messages for each of the offending lines, and everything seems right to me.  I am sure there is something I am lacking in understanding or something.   My template class: #include <stdio.h> template <typename T> class Node { private: T *mData; Node<T> *mPreviousNode; Node<T> *mNextNode; Node<T> *mChildNode; protected: public: Node(); ~Node(); }; template <typename T> Node<T>::Node() { mData = nullptr; mPreviousNode = nullptr; mNextNode = nullptr; mChildNode = nullptr; } template <typename T> Node<T>::~Node() { } The header class with the offending lines: #include <stdio.h> class Path { private: Node<Point> *mPointListHead; // <<---- THIS LINE, Node<Point> *mPointListTail; // <<---- AND THIS LINE protected: public: Path(); ~Path(); void addPoint(float x, float y, float z); }; The Implementation for the class: #include "Node.h" #include "Point.h" #include "Path.h" Path::Path() { mPointListHead = nullptr; mPointListTail = nullptr; } Path::~Path() { } void Path::addPoint(float x, float y, float z) { printf("Adding point\n"); } The header file for the Point class just for reference: #include <stdio.h> class Point { private: float mX, mY, mZ; float mR, mG, mB, mA; protected: public: Point(); Point(float x, float y, float z); Point(float x, float y, float z, float r, float g, float b, float a); ~Point(); }; The implementation of Point: #include "Point.h" Point::Point() : Point(0.0f, 0.0f, 1.0f) { } Point::Point(float x, float y, float z) : Point(x, y, z, 1.0f, 1.0f, 1.0f, 1.0f) { } Point::Point(float x, float y, float z, float r, float g, float b, float a) { mX = x; mY = y; mZ = z; mR = r; mG = g; mB = b; mA = a; } Point::~Point() { } Thanks for any help with this, and yes, I know that classes are private by default.   EDIT: The weird thing is that the "intellisense" (*) kind of thing sometimes seem to colour the keywords like it understand the names, but when I try to compile again, it forgets them again.  When the names are in the colours that shows that the IDE knows the class names, I can also start typing and get the correct autocomplete suggestions.  Also this goes away if I try to compile.  I am using the latest Xcode by the way, but I am pretty sure it is me goofing up, not the IDE/compiler.   (*) I don't know what name Apple has for the "intellisense".
  9. Architecture copyright

    This:   http://www.gamespot.com/articles/student-transferred-for-making-counter-strike-map-based-on-school/1100-6235913/
  10. "simple" equation confusion (a - b = c)

    This video should give you a thorough explanation on the matter:   https://www.youtube.com/watch?v=O4__F4iX6rc
  11. I am by no means any expert on the topic, but I think you have a lot to learn, if HTML is all you know.  Just client side, I would add that you would need to learn JavaScript too, in addition to the other technologies you have already mentioned.   Unless it is a client based game where nothing is stored between sessions, you will also need a web server with a database system and a server side scripting system. In the past, I have used Apache, PHP and MySQL, but that is starting to be quite a while ago, so have a look around.   Other buzzwords you may have a look into is JSON, JQuery.   Security is a must, so make sure you understand the dangers and pitfalls of a poorly designed system for handling logins and sessions (how you store your passwords, for instance), and data that is sent to the server from the client (it can not be trusted without validation), and SQL security as well (SQL injection, for instance).   All these suggestions are based on what you mentioned in your original post, and there are other choices you can make too, like scrapping everything mentioned above and go for something like FLASH, for instance, client side. You will still need what I mentioned on the server side if you want persistence.
  12. Demo scene 90's, anastasia song

    Never heard of the group or demo, but I am pretty sure it is this one:   "Toys" by "Gods" (PC demo, "Trip" party, March 1999, 1st place):   http://www.pouet.net/prod.php?which=710   I couldn't find any YouTube video of the demo.
  13.   I won't repeat what Álvaro said, but please...   Write sensible names.   Name 'dyn' and the likes more like 'isDynamic' (If that is even what you mean).  Then you can test like this, assuming it is actually a boolean: if (isDynamic) { ... } Instead of: if (isDynamic == true) { ... } Try to make your code as readable like a book that you can.   Always use brackets, even if your if, for, while, do..while, etc is having only one line.   'currentLineCount', or 'CurrentLineCount' is MUCH easier to read than 'CurLnCnt'.   What is 'IsPastEOS'?  'EOF' is so common, I guess most people would understand, but 'EOS'?  End of stream?  I would spell it out in either case.   I know that you have an assembler background, and labels like this were common back then.  I also think you actually was limited to 8 chars on certain assemblers too, and that didn't help.  It really feels like reading assembler code written in C.   And I will also point back to Álvaros comments again.
  14. I think exceptions have no place other than in the case of a fatal, unrecoverable failure in a program.  When I was learning Java way back, I was encouraged to use exceptions as the default way of reporting and handling errors.  I always felt that was a bit clunky, and it made for code that was filled with blocks that I felt never belonged in the code at all.  I always favoured explicit error checking over exceptions.  Who thought it was a great idea to throw a NumberFormatException when you feed bogus data to convert a string to an integer in Java??  That pretty much sums it up...
  15.     That's an arbitrary blanket rule. Early returns are a good thing. Breaks and continues have their places. Goto has its place too when you need some kind of control flow that improves readability (like the error handling example) and no other language construct naturally lends itself to that (admittedly, that is rare even in languages like C, and basically nonexistent for higher level languages). And when I see this kind of rule being repeated blindly all I can think of is the programmer who, told not to use goto, wrapped up his error handling code in a dreadful do{}while(0); loop to obtain the same control flow without writing 'goto' and obfuscating his code in the process. And that is far worse than any amount of gotos (well, almost any amount).   I'm not saying goto is good. Here the use of goto for error handling is justifiable because goto naturally lends itself to a rather elegant, very low boilerplate resource cleanup implementation in C. Clearly jumping all over your code, to labels hundreds of lines away, is nothing short of insane. But simply outright banning goto because there is a paper called 'goto considered harmful' without even considering the possibility that maybe, just maybe, goto could be used in a controlled manner (it is a tool, and just like any other tool it can be abused; break and continue are also tools which can be abused) simply shows a lack of intellectual depth in my opinion.     The cascade model is just plain ugly.  The goto way is actually really elegant.  In those cases I would probably go for a function in the past to avoid goto, but your arguments have convinced me.  There are definitively reasons for goto in certain cases, and the function way is not good either.   Regarding the blanket rule, I am not at all preaching the "flow chart" model, since I am obviously not following those rules myself, just wanted to hear some arguments, and I got a lot of good ones.  I am a follower of clean and elegant code, and that is for me more important than any other strictly (and blindly) enforced idioms.  Hearing comments like this also eases my insecurities/discomforts when I am breaking out of learned/taught conventions to make things more readable/elegant too, but the goto one has really got stuck in me for some reason.