Jump to content

  • Log In with Google      Sign In   
  • Create Account

mrbastard

Member Since 09 Oct 2000
Offline Last Active Jul 13 2014 03:35 PM

#4986828 Is that way of using constructor really better ?

Posted by mrbastard on 04 October 2012 - 12:18 PM

If there is a compiler that does not issue a warning when you put initializers out of order, you should switch to one that does.


FYI Visual c++ 2012 does not issue a warning about this with /wall (and 'language extensions' disabled fwiw). I know gcc does, and I agree that it's a useful warning.


#4986723 Is that way of using constructor really better ?

Posted by mrbastard on 04 October 2012 - 05:23 AM

My big issue is that the order items are initlialized in the initializer list is not the same order as they are listed. Which for dependent items can really lead to some hard to track down bugs.


Ah, but should initialisation be in the initialiser list order, or the order you declared them in the class declaration?

FWIW many coding standards suggest keeping your initialiser lists in the same order as your member declarations for exactly this reason.


#4984010 Should one refactor while writing?

Posted by mrbastard on 26 September 2012 - 10:31 AM

removing duplicate code to functions, pushing up to base classes, generalizing code, extracting classes and methods for clarity, etc. To me, that is simply tidying up.


You can use refactorings to tidy up, sure. But you can also tidy up in ways that are not refactorings, and do refactorings that are nothing to do with tidying up. So I think having a separate specific term is quite useful :)

For example: requirements change and you decide to parameterise a function or class further - that's not tidying up, it's preparing the ground for a new feature without changing external behaviour.

I was prompted to respond to L Spiro's comment that "The only reason to ever refactor is if you simply made a mistake". That's absolutely not true - requirements change. Of course it is perfectly reasonably to argue that the only reason to need to tidy up is if you made a mess. But not all refactoring is tidying up!

Not just being pedantic, I hope!


#4982860 Should one refactor while writing?

Posted by mrbastard on 23 September 2012 - 03:39 AM

Refactoring and feature additions should be in separate commits. This allows the definition of refactoring as a "behaviour preserving transformation" to be useful in a practical way beyond the immediate point of use - it's helpful information to have while regressing to find the source of a bug, for instance. If the refactoring is mixed with other changes it becomes much less useful.

Ideally, I'd like refactoring tools in IDEs to work with version control to check in and revert as I refactor/undo - and potentially even branch when I start refactoring then merge when I'm done and the tests pass.


#4979390 Inheritance vs. Templates

Posted by mrbastard on 12 September 2012 - 12:01 PM

I'd go with the template unless you need polymorphism at runtime. That's the key factor.

The only other consideration I can think of is whether your team are familiar enough with templates to pick it up and use it - though I swear by the above advice, I default to inheritance if it saves arguing with my team!

Edit:

It's worth mentioning that the reason I'd go with the template (apart from personal style) is that compile-time polymorphism avoids the extra indirection of a vtable - clicky. Style-wise, as "inheritance is the second-tightest coupling in c++" I tend to avoid it unless it's the perfect tool for the job. IMHO this also makes templates (huge generalisation coming up here) easier to reuse, maintain, and test than inheritance hierarchies.


#4976381 Can't make edit box

Posted by mrbastard on 04 September 2012 - 05:31 AM

What was the problem? How did you fix it?

Your experience may help somebody else in the future!


#4976133 MMO viability

Posted by mrbastard on 03 September 2012 - 12:10 PM

Where are the players that are not ingame. You've still not given us ANYTHING to work with

There's nothing wrong with asking for ballpark estimates, especially early in a project and even more especially in a subject area you aren't deeply familiar with. But yes - the more information the better. I suspect though that the OP is trying to decide what direction to take the game design in based on what's feasible for him to run - which is perfectly sensible.

OP: turn-based could work fine with virtualized hosting - I'm thinking of the server being a php script and a database. For turn-based, you can avoid most of the complexities Samoth has kindly explained for you above.


#4975109 MMO viability

Posted by mrbastard on 31 August 2012 - 05:18 AM

[edit] I think it won't have more than 32 players at a time.


32 players isn't particularly massive. Do you mean 32 players can interact in realtime, but the game is 'massively multiplayer' in that is has non-realtime stats / game elements that allow more than 32 players to interact in some way?


#4973278 Book on mathematics of programming

Posted by mrbastard on 25 August 2012 - 10:59 AM

Randomly browsing cpp-next.com, found an EoP study group. It's a few years old, but there's some great discussion.


#4972398 Book on mathematics of programming

Posted by mrbastard on 22 August 2012 - 04:00 PM

"Elements of Programming" by Alexander Stepanov and Paul McJones. It's a great book, though heavy going. I've yet to find time to give it the attention it deserves, but my first reading still changed the way I think about programming. I was writing some template functions for fractal stuff at the time, and Stepanov's stuff on functions and their orbits really stood out to me.


#4968758 win32 dialog question

Posted by mrbastard on 12 August 2012 - 11:41 AM

HTH. To add to yadango's suggestion - dialogs don't have to be modal.

Hmm. After a little googling, I find that CreateDialog (which you mentioned) apparently doesn't make a modal dialog with it's own message loop. Instead it make a 'modeless' dialog, which continues to use your message loop - and so doesn't block. So whatever the problem is, it's not that. Maybe set some breakpoints and investigate what's going on with your message loop after the dialog is created?

Also worth knowing - you can have dialogs as children of other windows. See the 'child' style in the resource editor, or WS_CHILD.


#4968745 win32 dialog question

Posted by mrbastard on 12 August 2012 - 10:37 AM

Are you sure the main window appears at all until after you dismiss the dialog?

My understanding is that a modal dialog fired up during another window's oncreate will prevent that window from being created until the modal dialog is dismissed and stops blocking the thread WM_CREATE was handled on.

TLDR: you don't want a modal dialog, don't want to use it from code handling another window's WM_CREATE, or both.

Edit: ninja'd. Anyway, I think th thing you're missing is that a modal dialog blocks the thread it's used from - that is, no code (in that thread) runs until the dialog is closed.


#4962005 Multiplatform game SDK choice

Posted by mrbastard on 22 July 2012 - 01:10 PM

Multi-platform threading seems a slightly strange thing to base a choice like this on.

C++11 has threading support built in - so any platform that has a compiler that supports C++11 already has a multi-platform threading API built in. If C++11 support is incomplete on your platforms of choice, you can/should use the boost thread library instead.


#4960642 Function taking as an argument std::equal_to, std::grater etc

Posted by mrbastard on 18 July 2012 - 02:43 PM

BTW, note that unary_function & binary_function are deprecated in C++11:
http://www.open-std....2010/n3145.html
http://en.cppreferen.../unary_function


Nice to know, thanks!


#4960424 Function taking as an argument std::equal_to, std::grater etc

Posted by mrbastard on 18 July 2012 - 05:25 AM

template <typename T>
bool doStuff(int a, int b, T comparitor)
{
	 return comparitor(a,b);
}

I'm guessing the problem you're having is that the component std functions / functors are not of the same type. Template parameters make this problem go away.

Some of the std component functions may be of related types : e.g. deriving from std::unary_function etc - so it may be possible to use normal polymorphism to work around this - I wouldn't recommend it though. TBH I'm not even sure inheriting from bases like std::unary_function is enforced by the standard.

Lastly, you could take an std::function<bool (int,int)> or similar, if you want to avoid writing templates.




PARTNERS