Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Mar 2001
Offline Last Active Today, 12:07 AM

Posts I've Made

In Topic: Week of Awesome IV announcment!

29 June 2016 - 07:20 PM


In Topic: Week of Awesome IV announcment!

29 June 2016 - 07:19 PM


In Topic: Single producer - multiple consumer fast queue?

21 June 2016 - 10:06 AM

First step: Write a lock based one, or better yet, use an existing queue such as ConcurrentQueue, which is already moderately lock free (source).
Second step: If profiling actually shows it to be a problem, then invest the time to replace it.


As for writing a lock free circular queue goes, for starters: Time consuming operations should be completed long before you ever attempt to insert the object into the queue. Your insertion into the queue should be one or more CAS operations based on the result of the CAS.

In Topic: How to avoid Singletons/global variables

14 June 2016 - 10:11 AM

4. Dependency Injection.
If you are familiar with SOLID development principles, you should know about handling dependencies.  In well-designed systems there should be interfaces for behavior.  Code should be written to accept objects that implement the interface rather than accept concrete types.  Then developers can build new concrete types and they will automatically integrate and work cleanly with the code.
If you have written your code according to SOLID principles, it is easy to inject the concrete class.  It sounds hard, but really it just means providing constructor parameter and/or a member function that accepts a new interface.  
For example, if you went with a combination of a texture loader / cache / proxy / pool rather than a monolithic "Manager" class, and each of the loader / cache / proxy / pool types had an interface, you could add a function that sets their owning pool, accepts an object that accepts the interface, and then the object uses the interface.  Alternatively, you can require the interface pointer be passed to any calls that need it, which is the most explicit way to do things but requires a bit of discipline.
When code needs several interfaces passed to it, it can also make sense to have a structure with a bunch of interface pointers. Fill out the structure with the active objects and pass the structure around for less typing.

As an additional note here, DIP can allow you to write unit tests against code that would otherwise be untestable. Since your concrete instances are merely taking interfaces, you can provide mock implementations of the interfaces and then back that with your test framework.

In Topic: Is it C# Territory?

04 May 2016 - 05:02 PM

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."