Search Results

Search found 5 results on 1 pages for 'kaa'.

Page 1/1 | 1 

  • C++ Storing variables and inheritance

    - by Kaa
    Hello Everyone, Here is my situation: I have an event driven system, where all my handlers are derived from IHandler class, and implement an onEvent(const Event &event) method. Now, Event is a base class for all events and contains only the enumerated event type. All actual events are derived from it, including the EventKey event, which has 2 fields: (uchar) keyCode and (bool)isDown. Here's the interesting part: I generate an EventKey event using the following syntax: Event evt = EventKey(15, true); and I ship it to the handlers: EventDispatch::sendEvent(evt); // void EventDispatch::sendEvent(const Event &event); (EventDispatch contains a linked list of IHandlers and calls their onEvent(const Event &event) method with the parameter containing the sent event. Now the actual question: Say I want my handlers to poll the events in a queue of type Event, how do I do that? x Dynamic pointers with reference counting sound like too big of a solution. x Making copies is more difficult than it sounds, since I'm only receiving a reference to a base type, therefore each time I would need to check the type of event, upcast to EventKey and then make a copy to store in a queue. Sounds like the only solution - but is unpleasant since I would need to know every single type of event and would have to check that for every event received - sounds like a bad plan. x I could allocate the events dynamically and then send around pointers to those events, enqueue them in the array if wanted - but other than having reference counting - how would I be able to keep track of that memory? Do you know any way to implement a very light reference counter that wouldn't interfere with the user? What do you think would be a good solution to this design? I thank everyone in advance for your time. Sincerely, Kaa

    Read the article

  • What's the best way to handle numerous recurring log entries in game loop?

    - by Kaa
    I have a custom logging system, use of which is scattered all over the engine and game. The system is linked to a "LogStore" that has an std::vector<string> logs[NUM_LOG_TYPES] - each vector corresponds with it's log type (info, error, debug, etc.). There's one extra std::vector that has "coordinates" to all log entries in the order they were received. Now, all the logging output is also displayed inside my development console in the game. The game console is handled by HTML-type GUI and therefore requires a new <p> element being added for each log output. My problem is that the log entries that are generated in the main loop each frame freeze the engine, because they continue to add elements to the in-game console, and if the console or guy generates a warning - that creates an infinite logging loop. I want to solve it by handling the recurring log entries in an elegant way that lets you know that something is critically wrong, but won't freeze the engine - like displaying the count of errors in the last 60 frames instead of displaying errors themselves. But how do you guys handle this? Does anyone know any nifty tricks to do this? I understand the question may sound vague, but if someone came across this type of issue I'm sure they would know exactly what's happening. Example problematic log entries: OpenGL warnings (I actually do check for errors every frame in many places) Really any prints anywhere in the main loop (may be debugging, may be warnings)

    Read the article

  • How to retrieve row count of one-to-many relation while also including original entity?

    - by kaa
    Say I have two entities Foo and Bar where Foo has-many Bar's, class Foo { int ImportantNumber { get; set; } IEnumerable<Bar> Bars { get; set; } } class FooDTO { Foo Foo { get; set; } int BarCount { get; set; } } How can I efficiently sum up the number of Bars per Foo in a DTO using a single query, preferrably only with the Criteria interface. I have tried any number of ways to get the original entity out of a query with ´SetProjection´ but no luck. The current theory is to do something like SELECT Foo.*, BarCounts.counts FROM Foo LEFT JOIN ( SELECT fooId, COUNT(*) as counts FROM Bar GROUP BY fooId ) AS BarCounts ON Foo.id=BarCounts.fooId but with Criterias, and I just can't seem to figure out how.

    Read the article

  • Verifying method with array passed by reference using Moq

    - by kaa
    Given the following interface public interface ISomething { void DoMany(string[] strs); void DoManyRef(ref string[] strs); } I would like to verify that the DoManyRef method is called, and passed any string array as the strs parameter. The following test fails: public void CanVerifyMethodsWithArrayRefParameter() { var a = new Mock<ISomething>().Object; var strs = new string[0]; a.DoManyRef(ref strs); var other = It.IsAny<string[]>(); Mock.Get(a).Verify(t => t.DoManyRef(ref other)); } While the following not requiring the array passed by reference passes: public void CanVerifyMethodsWithArrayParameter() { var a = new Mock<ISomething>().Object; a.DoMany(new[] { "a", "b" }); Mock.Get(a).Verify(t => t.DoMany(It.IsAny<string[]>())); } I am not able to change the interface to eliminate the by reference requirement.

    Read the article

  • How to retrieve row count of one-to-many relation while also include original entity?

    - by kaa
    Say I have two entities Foo and Bar where Foo has-many Bar's, class Foo { int ImportantNumber { get; set; } IEnumerable<Bar> Bars { get; set; } } class FooDTO { Foo Foo { get; set; } int BarCount { get; set; } } How can I efficiently sum up the number of Bars per Foo in a DTO using a single query, preferrably only with the Criteria interface. I have tried any number of ways to get the original entity out of a query with ´SetProjection´ but no luck. The current theory is to do something like SELECT Foo.*, BarCounts.counts FROM Foo LEFT JOIN ( SELECT fooId, COUNT(*) as counts FROM Bar GROUP BY fooId ) AS BarCounts ON Foo.id=BarCounts.fooId but with Criterias, and I just can't seem to figure out how.

    Read the article

1