Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2009
Offline Last Active Oct 13 2016 10:43 AM

Posts I've Made

In Topic: Would you try a language if all you had to do was install a Visual Studio ext...

27 September 2016 - 05:33 PM

I actually probably wouldnt because would be paranoid about screwing up my VS environment is some way. Although this may be a ridiculous fear. I have had problems with source control extensions for VS in the past though so not without any merit. 


I will try any language that I don't have to build from source and for which I can find a simple but less trivial than "Hello, World" example program easily.

In Topic: Coding-Style Poll

27 September 2016 - 10:13 AM

How do you feel about policies that strictly control how you brace your code?


I am old and have worked for a lot of software companies. When I was younger I gave a shit about this kind of thing but over the years have stopped caring. I'd prefer to work for a place that doesnt have strict style guidelines regarding trivial style details but if a place does it is not a deal breaker for me.


For example, would you prefer a policy that strictly requires all braces to be on their own line, or a policy that defines only where to put braces when declaring a class or defining a function, but lets you use your own style inside functions (which may well be to put them on their own lines)?


I'd prefer a policy of "Take a look at the way we arrange our code, postion our braces, name our member variables etc. and try to conform to that, but by all means style as you see fit if a practical need arises in which it makes sense to break out of the convention.


how irksome is it to have to conform to using a brace style other than your own?


A little irksome but in the grand scheme of things software company-wise not my chief concern, not my secondary concern, etc. Loads of things matter more e.g. autonomy to choose projects, etc.


Does it just bother you but you can get on with it, or does it leave a nasty taste in your mouth and make you disgusted at your own code?

Doesn't leave me disgusted at my own code.
For example, maybe it would annoy you a little to have to prefix a class with “C” if you are not used to doing that, but how annoyed would you be if you could not use “m_” for members of a class?


Actual deal breakers for me tend to have more to do with functionality and behavior than with syntax and syntactic style. I'm talking about arbitrary prohibitions on various language features and programming techniques -- arbitrary, not well-grounded ones i.e. yes: disallow use of exceptions if the code is going to run on an embedded device and compiling with exceptions makes the exe binary too large (or whatver); no: disallow excpetions because Google says exceptions are bad, etc.

In Topic: hiding a library's dependencies from users of the library

27 September 2016 - 09:24 AM


I could just use the Pimpl idiom. However, I see problems with use of vanilla Pimpl as it is standardly defined because I want users of my library to be able to inherit from myFramework::Sprite et al to make their-game specific classes but C++ does not allow inheritance from objects only inheritance from classes.

Sounds like you (or I!) have misunderstood how to implement the Pimpl idiom. I don't see any reason why they can't inherit from your public class given that it would be responsible for creating the private class (eg. in the constructor) and it's the private class that deals with SFML. All the issues regarding inheritance and ensuring behaviour is correct are separate from how the behaviour is eventually implemented.



Yeah, I've looked into it and have come to the conclusion that my usage of the term "pimpl" is wrong or nonstandard. I thought it generally meant when you expose publically only an abstract interface and a public static member function that creates an instance of an object that implements the interface using a private class often defined completely in a cpp file. The factory function creates one of those thingies and returns that but as a pointer to the interface. This is a way a lot of algorithms are implemented in OpenCV and extensions people write to OpenCV for example (which I use a lot at work). I got it in my head that this is what people mean by "pimpl" but according to wikipedia pimpl is close to what I describe in 2. or 3. in the original post.

In Topic: hiding a library's dependencies from users of the library

26 September 2016 - 05:09 PM

I'm not big on hiding this sort of thing from your customers. The code aspects aren't so great, but where you are really letting yourself in for a world of pain, is in needing to provide perfectly working development/release toolchains for every platform under the sun (i.e. you need to provide out-of-box toolchains for Android and iOS, since your customers can't get at the dependencies to do it themselves).


Hadnt really thought about this in that am only going to support Win32 and iOS out of the box because that is what I need personally and it doesnt seem complicated in these two cases (famous last words, maybe). But as you say Linux and Android might be a can of worms ... I don't know a lot about either platform, in terms of game programming anyway in the case of linux.
However to me, implications on the complexity of implementation aside, this is what I personally want out of some I kinds of frameworks: I want someone else to get this kind of stuff right for me. I was planning on having a Python script that will generate a solution/project files etc for you when you start a new project with this game framework. That script will be parametrized in part on platform(s) you want to support. It would just copy in the framework binaries and set up the solution/projects to statically link to them. 

If however you want access to my usage of SFML and OpenAL and libJpeg and zlib etc. you can always pull all the code from github and build that way, changing whatever you like. That would just not be the default usage pattern. My general thought is your average user doesnt care that I am using SFML texture wrappers in there any more than he or she cares that I am using dropbox's Json11 to parse spritesheet metadata Json -- so why have a design that makes those headers and those binaries public to average users? if it is difficult to do this then so be it and maybe I will have to change my decision here for pragmatic reasons but I still think it is a laudable goal.

In Topic: Why C# all of a sudden?

21 September 2016 - 12:05 AM

Java was popular -- its popularity is for example why Javascript is called "Javascript" even though the two have absolutely nothing to do with each other. Get in a time machine and go back to the late 1990s and see for yourself. People couldn't shut up about Java. Mainly what  happened with Java is that client side Java failed. Client side Java failed because 

  1. applets failed. Poor design plus HTML/CSS + browsers werent where they needed to be. Java applets should've had access to the DOM which would have allowed Java to be what Javascript ended up being.
  2. AWT sucked.
  3. Swing sucked.

Thus Java for desktop applications and Java in browsers both failed despite Java's enormous popularity. This opened a door for C# which was a better language and WinForms and later WPF were both much better than the early Java gui frameworks. Given the defacto death of MFC with Microsoft not introducing a new native framework they were the only option for writing Windows applications besides 3rd party cross-platform C++ frameworks like Qt, but were also considerably simpler and easier to learn than Qt and in the case of WinForms, were both simpler than Qt and leveraged one's knowledge of Win32 C programming i.e. if you cant do something in WinForms you can always invoke native calls if it comes down to it. This all led to tools for games, which are GUi applications, getting written in C#. And tools probably led to Unity and other engines being written in C# -- which was possible given C#'s speed.


C# really is a better language than Java by the way. It isn't just little things. It's implementation of generics is better in a major way and LinQ is great. LinQ is a great achievement across software engineering, period.