Jump to content

  • Log In with Google      Sign In   
  • Create Account

Juliean

Member Since 29 Jun 2010
Offline Last Active Today, 01:42 PM

Posts I've Made

In Topic: Local hash

Yesterday, 09:19 AM

At every size, unordered_map beat map, but at size 10 it was close.

One practical consideration can be the size of the unordered_map, though. Its exactly 4 times the size (32 byte vs 8 byte of map), so if you have a huge amount of those maps as like a part of another class, this can produce way worse results for unordered_map - as it happend to me recently, even though I was even using a simple int-key for the unordered_map, it was significantly slower than map (mainly due to increasing item size and thus roughly increasing L3 cache misses from roughly 7% to 17%). Maybe having that many maps is not a good idea in the first place, but just something to keep in mind.


In Topic: My C++ gotcha of the day

21 May 2016 - 12:29 AM

Huh? i dont see how the macro is related to this in this case, I generally do tend to avoid them but in this case it is just a shorthand for "extern ACCLIMATE_API template class XXX", and I do know what it stands for so whether seeing the macro or the written-out version doesnt seem to make a big difference to me.

In Topic: My C++ gotcha of the day

20 May 2016 - 07:38 AM

Huh. Any idea what SFINAE stands for? It should be a clue as to why it's unreasonable to expect an error in that situation.

 

 

Sure do, and it was an "Aha! That makes sense"-moment after I found out. Saying I expected an error was probably wrong, but I sure didn't think of this as even a possibility for this error.


In Topic: My C++ gotcha of the day

20 May 2016 - 03:28 AM

Huh, when its unclear where the issue is coming from, thats the worst :/

Had something along those lines for some time now. So in my runtime-type system I had a SFINEA-expression to check if a registered object has a reference-counter, or not:

template<typename ObjectType>
static auto AddRef(ObjectType* pObject, int) -> decltype(pObject->AddRef(), void())
{
    if(pObject)
        pObject->AddRef();
}

template<typename ObjectType>
static void AddRef(ObjectType* pObject, long)
{
}

For certain types under certain conditions, this simply was not working. Even though the object had a reference-counter, AddRef was called with the empty implementation, in certain parts of the code. When debugging explicitely, this behaviour somehow depended on which files where included, whether I forward-declared the type in question or not, and so on. There was no clear pattern to it, and I thought it was a compiler bug for the longest time.

 

So than the other day, I noticed that at a certain point I was doing this:

template<typename Type>
class Asset; // this is forward declared in another header

class MyObject
{
	// this is a fully declared class
};

 // exports dll-symbols for the type system for MyObject and Asset<MyObject>
EXPORT_ASSET_OBJECT(MyObject);

At this point, I was generating the export-symbols for the refCounter<Asset<MyObject>>, one of the types that were making difficulties. Turns out that because "Asset" is only forward declared here, it doesn't have an "AddRef"-method as far as the compiler can see it, so the empty SFINEA-expression is generated -.-

This explained why it depended on whether I included specific files, and/or was using the DLL symbol in the test project or not, and so on.

Thats really weird, I expected for SFINEA to eigther give some compilation error that the class was not defined at this point, but not just silently tread it as if it was an empty class the whole time.

 

 

 

 


In Topic: VS 2015

20 May 2016 - 03:15 AM

When switching to 2015, did you make sure to clean & recompile? I also had similar issues, as 2015 seemed to wrongfully reuse some of the obj-files/binaries from the old compilation.


PARTNERS