Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Mar 2005
Offline Last Active Today, 11:14 AM

#5312318 Why do most people recommend Python

Posted by on 24 September 2016 - 09:01 AM

I've recommended Python to new programmers because in my experience one of the biggest barriers to new programmers is getting something interesting working quickly and minimising the amount of technical minutiae they need to understand (at first).

For reasons others have explained, I think Python is great at this.

For this site in particular, being able to recommend a simple but popular library like Pygame is a huge benefit too.

If someone sticks with programming, they will almost certainly learn additional languages later. So one's first language isn't actually important in the long run. I started with BASIC!

But getting them to stick with it is the hard part, and for my Python helps: getting them up and running quickly, writing an interesting program and with lots of help and support available online.

#5289746 Cast your vote now!

Posted by on 02 May 2016 - 09:03 AM

I vote Notey Mc Padface.

#5287730 std::sort corrupts my memory

Posted by on 20 April 2016 - 01:21 AM

Your std::sort predicate is invalid - Googling for "std::sort invalid predicate" will explain why this is a bad idea.

#5287406 Memory Allocation

Posted by on 17 April 2016 - 11:34 PM

Your class should have a destructor, a copy constructor and assignment operator.

I'd recommend not having both a head and tail pointer to start, it should be simpler to implement a queue as a singly linked list (in reverse, push creates a new "head"). It complicates things to maintain both correctly.

Consider using new/delete for the nodes, at least to start. Complex classes like std::string will break unless you account for how malloc() separates allocation from C++ object life cycle management.

#5283487 Regex - Scan a string for special chars

Posted by on 25 March 2016 - 06:04 PM

Normally you try to write a regular expression that fully captures the kind of strings you want to allow. Your approach of having a pattern you want to disallow and search for instances of it can also work, but would be a less common approach.


To simplify, I'm going to imagine a case you only want lowercase letters (e.g. [a-z]). You can say that you expect zero or more, or one or more, by using the metacharacters * or +. You can use the metacharacters ^ and $ to say that your requirement is to match against the entire input, not just a partial match in the middle.


So that might yield ^[a-z]*$, which means a string starting with zero or more lowercase characters and then ending.


You might have something like this:

#include <regex>
#include <string>
#include <iostream>
int main() {
#if 0
    std::regex reg("^[a-z]+$");
    std::regex reg("^[a-z]*$");
    std::string strings[] = { "", "    ", "hello", "1number2", "!goodbye!" };
    for (std::string s : strings) {
        std::cout << '\"' << s << "\": " << (std::regex_match(s, reg) ? "matches" : "doesn\'t match") << '\n';


There are helpful sites which can speed up developing a regular expressions, the one I linked is tailored for Ruby (regex syntax can vary), but there are lots of alternatives out there.

#5270316 Question about lambda function

Posted by on 09 January 2016 - 05:20 PM

What you might be asking about is how "b" and "cb" are working in the lambda. This is called "capturing", the city button and "b" variables are captured when the lambda is created, and are available when the lambda is executed later.


See Variable Scope in Lambda Expressions.

#5268902 loop, continue and reset issue

Posted by on 02 January 2016 - 05:50 PM

That is a particularly complex method, in that there appear to be many non-local variables modified that may be used by other methods. I suspect some of those variables are not used elsewhere, and could be converted into locals, but even then I'm not sure that extracting a method will actually simplify anything here.


Possibly restructuring some of the higher level code, particularly with an eye to reducing the need for so much mutable state here, would enable this approach.

#5268865 Keyboard/Mouse input missing because of low FPS

Posted by on 02 January 2016 - 01:56 PM

You have to be careful with functions like SDL_GetModState(), this gets the state at the time you call it, which can be different than when the event is consumed. Do you do any other non-event related input handling, e.g. calling SDL_GetKeyboardState()?

#5268860 loop, continue and reset issue

Posted by on 02 January 2016 - 01:50 PM

A simple solution would be to extract the inner loop, along with the variable resets, into a helper method which has an early return statement. If possible move the declarations of these variables into this method.


However I suspect there might be other ways to solve this issue, but I'd need to see the full code to be sure.

#5267733 Advice on coding style

Posted by on 23 December 2015 - 07:54 PM

Couple more points:
Many of the comments are unnecessary, in that they just restate what the code does. Maybe the book does that to help guide you through the program, and it is fine if you want to keep doing so in the short term to remind you what different parts mean, but remember that this is not how comments are usually used. Comments are best used to give context to the program, maybe an example in your program is why the "hire date" is important but not the "start date".

... I'm glad my gut instinct did not want to do this, but when reading code that consistently used it, I thought I was in the wrong.
Remember this is code style we're talking about, it is not objectively right or wrong.

... but I think books that assist with the object oriented part would be even more ideal before diving into windows programming?
I can't say I've read those exact books but strengthening the fundamentals first sounds like a good idea.

(I can't accept sentences that say: This code does this, don't ask how, but it works).
A good attitude for the most part, but don't let it turn into a "not invented here" syndrome!

enum variables in the book are all upper case, I did not realize that it was standard. I'll adjust that. As for the objects John, Joe and Jill starting with an uppercase is probably bad mannerisms from the actual English language.
Yes. Indeed most of the time you want your program to be agnostic to such details. Giving human friendly names to the data structures in your program is mostly accomplished using some kind of lookup system like a dictionary data structure (e.g. std::map<>) or a database of some kind. Don't worry about this too much for now, but I'd say that if you can, try make names data (even if only a string literal) and not code.

I hope I posted in the right forum, if not you can move this to wherever it belongs.
This is the right place!

Again, thank you for the time to reply.
No problem! :]

#5267731 Advice on coding style

Posted by on 23 December 2015 - 07:23 PM

Separate class or function declarations with a blank line

Instead of:

class A
    // A stuff...
class B
    // B stuff...
void foo()
    // foo stuff...
void bar()
    // bar stuff


Put a blank line between them:

class A
    // A stuff...
class B
    // B stuff...
void foo()
    // foo stuff...
void bar()
    // bar stuff

This helps to keep them visually distinct.


Separate function parameters with a space.

You had:


Use a space to separate the parameters:

Jill.getStat(number, wage, type, year, month, day);

#5267718 Advice on coding style

Posted by on 23 December 2015 - 06:12 PM

Please not that the following is based on the most common styles I've seen, it is not universal.


The following is discouraged:


  • Having multiple statements on one line



  • Having multiple variable declarations on one line



  • Abbreviated variable names (use the full name for a variable "year" instead of "y")



Most of your variables start with a lowercase letter (which is standard), but "John", "Joe" and "Jill" appear to be exceptions? Consistency is the most important part of having a code style, the actual details aren't too important (though it is good to stick with common ones unless you have a reason not to). Typically, constants are uppercase, e.g. enum entries would be "DRIVER". Types usually use "CamelCase", e.g. Employee, Date, EmployeeType.


Separate class or function declarations with a blank line. Separate function parameters with a space.


Personally, I prefer if a comment is before the statement it related to, and starts at the same indentation level.


Most people use "get" as a member function prefix to mean that the member function will only fetch data from the object and not modify it.


You repeated code in your main function, can you extract the logic for  "John", "Joe" and "Jill" to be less specific, without affecting the program's functionality?


Consider renaming "eDate" to something meaningful, like "dateHired" or "hiredOn".

#5267516 How to sell our Twich.tv clicks inventory?

Posted by on 22 December 2015 - 10:41 AM

This isn't a "Game Design" question, so I've moved it to "Business and Law".

#5267325 Strange std::set comparator outcome.

Posted by on 21 December 2015 - 09:02 AM

std::tie creates a std::tuple, when you compare std::tuples it compares the elements sequentially, so in your example first by total_cost, then by estimated_cost and finally by m_time_dependent_id:

Compares lhs and rhs lexicographically, that is, compares the first elements, if they are equivalent, compares the second elements, if those are equivalent, compares the third elements, and so on.

All comparison operators are short-circuited; they do not access tuple elements beyond what is necessary to determine the result of the comparison.


So if you want to compare the sums of the values, then just sum them! :]


But Andy Gainey's explaination might still be relevant, for example if the two apparently equal floats 31.7885 values aren't precisely equal in binary. It is good to be aware of this.

#5267157 knowing about military strategies and tactics and

Posted by on 20 December 2015 - 10:33 AM

It depends on your game. Most games have some kind of simplified system to represent terrain, units and battle. Depending on which mechanics you include or exclude, different strategies and tactics can emerge as especially dominant. A simple example is flanking, in some games attacking from the "side" or from behind is ignored, in others it can be decisive.


Studying how other military games, especially those similar to yours, handle this might yield some insight into how to handle this - or in many cases what not to do! For game A.I., not having glaring weaknesses can be more important than trying too hard to make the "best" choices. As an example, in at least one version of Civilisation, if you invaded an opponents territory, they would throw *everything* they had at you to defend themselves... even if you "invaded" by placing several high defensive units on a mountain square (which has a high defensive bonus).


Another important consideration is whether you mind allowing the A.I. to "cheat" in various ways to compensate for the lack of human creativity and ingenuity. This can be a rather simple way to help put the human player at a disadvantage which might result in a more enjoyable, challenging game.


i searched a bit on internet but i couldnt find so much.

What are you searching for? I appear to be getting some interesting stuff just by searching for "strategy game AI".