Jump to content

  • Log In with Google      Sign In   
  • Create Account

iMalc

Member Since 05 Mar 2004
Offline Last Active Dec 13 2015 01:49 AM

#5264705 C++11 template question

Posted by iMalc on 03 December 2015 - 12:50 AM

Of course, those of us who write firmware will not go through all this trouble just to get the size, we just straight use the ARRAY_SIZE definition to save precious clock cycles ;)

Sounds like you don't realise that constexpr methods are evaluated at compile time and as such have no run-time penalty whatsoever. And if that's not enough, the int template argument is also determined at compile time.
Identical assembly is generated to the code with macros, but without the headache macros bring.

 

When people writing firmware do this sort of thing it's actually typically because they're stuck using an ancient compiler written at a time when templates were either unheard of, or were still in their infancy.




#5259077 Confusion with smart pointers

Posted by iMalc on 26 October 2015 - 12:28 AM

 


I've almost never called std::move on a unique_ptr myself; that should be mostly called by container classes e.g. vector in a normal program, and I you wouldn't often be writing a container.
In a normal program if you have to transfer ownership between unique_ptrs, you'll often find yourself doing so by detaching from one unique_ptr, and attaching to another, most likely across a function call boundary.

 

That's exactly when std::move should be used.

 

Well sure, if the function signature takes a unique_ptr directly as one of the arguments. Kinda forgot that obvious case as I've almost never been in that situation. I deal mostly with code where the interface in the middle is a C interface, e.g COM, and that sort of thing.




#5258999 Confusion with smart pointers

Posted by iMalc on 25 October 2015 - 02:27 PM

As you are no doubt aware, in C++ it is preferable to avoid new and delete in your program. Modern C++ provides some nicer ways to achieve this with unique_ptr:

 

Instead of this:

std::unique_ptr<Random> SP(new Random());

Use this:

 

auto SP = std::make_unique<Random>();

I've almost never called std::move on a unique_ptr myself; that should be mostly called by container classes e.g. vector in a normal program, and I you wouldn't often be writing a container.

In a normal program if you have to transfer ownership between unique_ptrs, you'll often find yourself doing so by detaching from one unique_ptr, and attaching to another, most likely across a function call boundary.




#5255410 vector push_back creates error when multi threading

Posted by iMalc on 03 October 2015 - 02:33 PM

And ideally, you pass the mutex as a parameter.

 

Statics/globals are the enemy of multi-threading, and having that singular mutex pretty much ensures that you are not, in fact parallelising much of anything.

Or the better option would be for this doit function to be a member function instead, and the mutex is a member variable.

That way the caller can't pass in the wrong mutex.




#5222884 C++ cant find a match for 16 bit float and how to convert 32 bit float to 16...

Posted by iMalc on 13 April 2015 - 02:08 AM

I use a branchless table-driven implementation by Jeroen van der Zijp (http://www.fox-toolkit.org/ftp/fasthalffloatconversion.pdf) which some time ago I wrapped into a class to make it as convenient as a regular float.

 

The conversions in both directions are two-liners, and the combined size of all of the lookup tables is less than 10K.

http://homepages.vodafone.co.nz/~tawa47a/Malc/Useful_Classes.htm

It's probably nearly functionally identical to Aressera's

 

Edit: Bah, Jeroen van der Zijp's original link is now not working for me.

 

Edit2: Christian Rau has since produced an even more complete version here, which is clearly also based on Jeroen's work, but is more complete than mine, with template meta-programming to avoid unnecessary conversions and such:

http://half.sourceforge.net/

Probably best just to use that one.




#5221508 Unused param

Posted by iMalc on 05 April 2015 - 01:57 PM

Unless I'm in the situation where the parameter is used in only debug or only release build, I tend to just comment out the parameter name.

 

I've also seen people just mention the variable name in the function body on a line by itself, without any cast.




#5216801 is it possible to prevent a proggram(specialy a game) to get decompiled

Posted by iMalc on 16 March 2015 - 02:42 AM

My take is that generally in the best case you're only going to be able to completely stop someone who is only as good a hacker as yourself.

 

But ... yes with the right outside help you can do better.

 

Still, there's always going to be someone out there with better hacking skills that whoever you learn from.

From them, your best defence is to make the reward not worth the effort. Sadly, that is not easy.




#5200335 Getting Rid of "char*"

Posted by iMalc on 27 December 2014 - 05:24 PM

Let's pretend it is an issue. How do you think you would solve it?

Actually, let's not pretend it's an issue, that's exactly what causes premature optimisation.

Here is the procedure to "solve it".

 

First prove it is an issue, via profiling. You've either done that and not posted results, or you haven't done that. Either way there is more work required at this step.

 

After that, your first attempt at a resolution should be to see how you can use strings less. E.g. if profiling showed that you had a bottleneck when comparing your string object IDs, then perhaps you could switch to using enumerations instead of strings. Or, if you're getting too many string copies, perhaps there are some critical places where the string is passed by value instead of const-reference.

 

The next thing to do is to look for a replacement that already exists. That may be in the form of a more-specialised part of the same library, or a whole other library. There is plenty that you can research.

 

Next, in considering whether to write your own replacement, you need to understand that in proceeding down the path of making your own, you are assuming that you can do a better job than the expert standard library writers. You are then assuming that you are in the top few percent of all C++ coders. Most people like to think that they are in the top few percent of C++ coders, but obviously most aren't. The experts are those who have first learnt to use existing tools very effectively (e.g. strings). One must learn why all the parts of the string class work as they do, in order to not fall into traps that others have already solved.

 

The final thing to understand is that even when there is a bottleneck, and even when you've done your best to optimise all related code as much as you can, there is always going to be a bottleneck somewhere. It's even possible that no matter what changes you make to a program, string handling could be such an unavoidable bottleneck (although that is generally unlikely, depending on what the program does).




#5190633 Is optimization for performance bad or is optimizating too early bad?

Posted by iMalc on 01 November 2014 - 03:10 PM

I should note that there is sometimes a bit of a misconception about premature optimisation.

Avoiding premature optimisation doesn't mean that you ALWAYS just start with the simplest thing that could possibly work. For example, say you are starting out writing what is planned to be a very good chess AI.

You do your research and discover that other people have already studied this area and determined that the only way to get things fast enough is to use bit-boards. Starting out using bit-boards, which is more complex that a straightforward solution, is thus not a premature optimisation. It's an informed need for optimisation, and the only known way to get the required performance.

 

You either profile then optimise, or you research then optimise, or both.




#5171825 Interrupt handling very slow

Posted by iMalc on 06 August 2014 - 03:51 AM

Generally when the problem appears to be that the Windows message queue mechanism is too slow, that is usually not the case at all.

It can only deliver you the next message when you request it, and you normally only request it when you are finished dealing with the current message. So basically your own slow message processing slows down the receipt of further messages.

 

One mistake I've come across when processing Windows messages is when you only allow at most one Windows message to be processed each time around your main loop, seemingly giving maximum time to the rest of your drawing code. In reality what happens is that this slows the program down horribly. You should endeavour to process ideally all messages before doing any other stuff in your main loop. Although this may be counter-intuitive, it actually makes a world of difference. Give Windows more attention and promptly process its messages, and your program's performance will be greatly rewarded.

 

Those are not interrupts and no you do not need a mutex there. In fact the term "interrupts" doesn't have much applicability at all in a Windows program. The terms that you need to be familiar with are synchronous / asynchronous, blocking / non-blocking, or single-threaded / multi-threaded.

You can confirm this for yourself by placing a breakpoint within the HandleInterrupt function, and when the breakpoint is hit, examine the Call Stack window. When you can look back through the call stack of the same thread and find the original GetMessage or PeekMessage call, then what your application is doing is entirely synchronous, or blocking.




#5154160 Most efficient way to write identical data to 2 memory locations simultaneously

Posted by iMalc on 16 May 2014 - 06:40 PM

This sounds similar to the problem of drawing the screen bitmap in one thread and transferring that to the graphics card in another.

When you don't want either thread to have to wait for the other, then the general solution is to use triple-buffering.

Have a read of this and see if it might be what you are looking for:

https://en.wikipedia.org/wiki/Multiple_buffering

https://en.wikipedia.org/wiki/Triple_buffering#Triple_buffering




#5153726 Karatsuba algorithm

Posted by iMalc on 15 May 2014 - 01:41 AM

I implemented that algorithm , but found that the numbers had to be pretty big before it was a win. About 700 bytes IIRC. It would be good to hear how well it works for you.

In case you want to compare notes, my three variations of bigint libraries are here: http://homepages.ihug.co.nz/~aurora76/Malc/Useful_Classes.htm




#5148485 Using C++

Posted by iMalc on 20 April 2014 - 11:50 PM

So I have recently watched several videos on C++. I understand the basics, but how can I apply this into developing a game? 

 

Thanks

Let me help put that into perspective for you...

 

You've just watched several videos on how to use a hammer, and now want to build your own home.




#5148481 C++ std::move() vs std::memcpy()

Posted by iMalc on 20 April 2014 - 10:52 PM

The obvious example that comes to mind, is when the object contains a pointer to one of its other members. I have just been using production code that has exactly that.

 

The other thing you should not overlook is that memcpy-ing may do most of the job for some types, but it doesn't in itself suppress destruction of the object where the data came from, which you would need to also do to avoid double-deletion. std::move on the other hand, gets implemented to null out pointers from the source location as necessary, causing subsequent destruction to be safe.




#5143168 Random Arbitrary Precision Numbers

Posted by iMalc on 29 March 2014 - 07:13 PM

Okay, here is a rough draft of my new article, comments welcome:

http://homepages.ihug.co.nz/~aurora76/Malc/Random_Numbers.htm






PARTNERS