Jump to content

  • Log In with Google      Sign In   
  • Create Account


tivolo

Member Since 19 Jun 2004
Offline Last Active Jul 24 2014 04:19 PM
-----

Posts I've Made

In Topic: Storing position of member variable

14 July 2014 - 08:17 AM

 

 

EDIT: Unfortunately, pointer-to-member seems to also have a problem with the child-POD-struct:

class Sprite : 
	public ecs::Component<Sprite>
{
public:
	math::Vector2f vPos;
	float z;
	
	void Test(void)
	{
		float Sprite::* pZ = &Sprite::z; // works
		float Sprite::* pX = &Sprite::vPos::z; // doesn't even compile... I don't even know how that should work
	}
};

I don't know... is there even a solution to this? offsetof would work, though I like pointer-to-member better... I don't want to replace the vector with pure floats eighter... any ideas?

 

 

The problem is that &Sprite::vPos::z is not a pointer-to-member of class Sprite, but rather a pointer-to-member of math::Vector2f, which is entirely unrelated to Sprite.
One solution to your problem would be to implement a generic (but typesafe!) pointer-to-member, something using inheritance and type erasure should do the trick.


In Topic: C++ Template Class -Creating a static method overload in derived class hides...

24 March 2014 - 04:49 AM

 

 

Hi I have a some code in my engine similar to following snippet - 

...

So basically what I am trying to do here is there's a static method in template base class and I am trying to create an overload with string parameter. I want to use both of them.

But the problem is if I create the static method overload in derived class it hides the base class version. I am not sure if I am missing something here or this is the intended behavior ????

Right now as a work around I am using BaseClass<DerivedClass,InitDataType_t>::GetInstance(initData); inside main.

 

Also If I don't create any overload in derived class then DerivedClass::GetInstance(initData); works fine without any warning or error. Which I think how it should be.

 

Creating a static method overload in derived class hides the base class method, which I feel is a bug or maybe I am missing something here? So can anyone please provide an insight to whats really going on here ?

The behavior is correct and indended. You're not overloading here, but overriding. Overriding a base class function in a derived class hides the base class definition unless explicitly qualified with the base class name as you discovered. This applies to non-static member functions as well, not just static ones.

 

You can "unhide" the base class symbols in the derived class with the using statement. Something like this should work:

class DerivedClass : public BaseClass< DerivedClass, InitDataType_t >
{
using BaseClass::GetInstance;
public:
static T1* GetInstance(const cstring& somestring);
}

I understand overriding for non static methods makes complete sense to me. 

But overriding static methods, I didn't knew if that was even possible ? (mind blown)
Can you please provide a little insight into how does it works with regards to  memory mapping, vtable and stuff ? Is it like non static methods ?

 

(This problem reminded me of a quote I read somewhere on the internet - "C++ is too much of a language to learn in a single life time".)
 

 

 

I'm pretty sure Brother Bob wanted to say it the other way around.

You are creating a new overload in the derived class, and that will hide all overloads from all base classes, unless you explicitly "pull" them into the derived class via "using". That is intended, and correct.

 

There is no such thing as overriding static methods.


In Topic: Sorting a std::vector efficiently

10 March 2014 - 08:01 AM


 

To answer the original question: just sort the indices, and use a radix sort. If your indices are 32-bit, you can use a three-pass radix sort with 11-bit buckets that will nicely fit into the CPU's L1 cache.

This looks like indeed a nice idea for applying radix sort. There's so few places where it really fits.

 

I couldn't tell whether it's worth the trouble (still always using std::sort, which for anything practical surprisingly turns out just good enough every time, I've never had enough of a justification for actually using radix sort in my entire life), but from playing with it a decade or two ago, I remember that radix sort can easily be 3-4 times faster than e.g. quicksort/introsort.

So if the sort is indeed bottlenecking you out (that is, you don't meet your frame time, and profiling points to the sort), that would probably be a viable option.

 

Slight nitpick, though: One doesn't of course sort the indices, which would be somewhat pointless. You most certainly didn't mean to say that, but it kind of sounded like it.

One sorts the keys (moving indices). Or well, one sorts indices by key, or whatever one would call it.

Which means that most likely, 3 passes won't be enough, sadly (or you need bigger buckets), since you will almost certainly have at least 48 or 64-bit numbers to deal with (except if you have very few passes and render states, and are very unkind to your depth info).

Not using a stable radix sort to save temp memory may be viable (can instead concat the indices like described above if needed, even if this means an extra pass... the storage size difference alone likely outweights the extra pass because of fitting L1).

 

Thanks for pointing out my mistake, yes I wanted to say that one should sort the keys :). What you get back are the indices which are then used to access your data.

 

Fully generic rendering-related data might not fit into a 32-bit key, that's true. But there are certain occasions where 32 bits are more than enough (or even 16 might suffice), e.g. for sorting particles.

As a quick note on performance, sorting 50k particles back-to-front using an ordinary std::sort on 16-bit keys takes 3.2ms on my machine, whereas an optimized radix-sort needs 0.25ms. If all you need to sort are keys that somehow index other data, it's almost always better to just sort that, and correctly index the data on access because this causes much fewer memory accesses during the sort.


In Topic: Sorting a std::vector efficiently

10 March 2014 - 02:29 AM

To answer the original question: just sort the indices, and use a radix sort. If your indices are 32-bit, you can use a three-pass radix sort with 11-bit buckets that will nicely fit into the CPU's L1 cache.

And you can also make the radix sort benefit from temporal coherence. But even if you don't, it will be much, much faster than a std::sort in comparison.


In Topic: Simple Question BYTE->float C++

28 February 2014 - 03:05 AM

I don't believe the static cast is needed, unless your compiler has a nonstandard warning message.

Dividing the types char / float is going to follow a standards-required implicit conversion to make them the same types, float/float. Since the char value can be exactly represented by a float, no compiler message is required.

 

I'd argue that in the general case it would be better to use a solution with explicit static_casts as presented by ApochPiQ, because you can immediately see the four casts (and can also search for them), also making it easier to spot potentially expensive operations (load-hit-stores on PowerPC architectures).

But that's probably a matter of taste.


PARTNERS