Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Rattrap

Member Since 03 Nov 2004
Offline Last Active Today, 11:36 AM

#5203475 Registering Window Class Multiple Times

Posted by Rattrap on 11 January 2015 - 09:01 AM

This is also a great point - which minimizes the 'messiness' of having multiple static variables.  I was just wondering - do you use this type of a system in practice, or is this one solution that you see working due to the topic's question?


In general, I have not found to many cases where I derived a C++ window class from another complete class. I generally just have a base abstract Control class (with a lot of built in functionality, but can't be instantiated) and many complete children classes. I tend to model then off of the .NET classes.

For example:

Control -> Form
Control -> Button
Control -> Label


#5203389 Bug in vc++ 2014 preview compiler? (std::thread)

Posted by Rattrap on 10 January 2015 - 09:40 PM


Is an okay way to do this

 

Yes.

 

You might also want to rig some kind of way to signal the threads to stop waiting for input (stop looping) and to quit entirely.




#5203387 Registering Window Class Multiple Times

Posted by Rattrap on 10 January 2015 - 09:35 PM


That just gets really messy if you allow sub-classes of the Window (for example to have a different style, or perhaps handle events differently).

 

As far as the static variable, you could try calling GetClassInfoEx to see if it already exists and get the atom for local scope use in creating a window.  You could do this with just a const string (to ensure the same name is used).  The catch here (if you want to be thread) is you still would want some kind of static atomic flag/mutex to make sure two separate threads aren't trying to perform the same action at the same time.

 

As far as handling events differently, that doesn't tend to revolve around the atom/class itself, but the window handle passed to the window procedure.  I've generally gone with a master shared window procedure in a base Control class that can make calls to a class instance (stored in the window handle using SetWindowLongPtrduring the handling of WM_CREATE) and virtual functions or a delegate based system.  Both of these are handled at the instance level, so the atom only was really needed for the CreateWindowExcall.  Otherwise you might have to create separate window procedures for both classes, which that would probably be very messy with a lot of shared code.

 

It shouldn't be too messy if you actually derived a c++ from a parent class.  At the derived class's scope, a static variable of the same name should hide the parent's, thus it should always reference to the local one.  If for some reason you actually needed the atom at the window procedure level, you could just call GetClassLongPtrwith the window handle to retrieve just about anything that was passed when RegisterClassExwas called.




#5203280 Registering Window Class Multiple Times

Posted by Rattrap on 10 January 2015 - 09:08 AM

If you're not worried about thread safety... I would typically keep the atom returned by RegisterClassEx in a static variable stored in the individual class. In the constructor, I would just test to see if it was 0 or not to see if the call to RegisterClassEx needed to be called.

You can add a mutex if you need thread safety as well.


#5201833 Bug in MSVS 2012?

Posted by Rattrap on 04 January 2015 - 06:59 PM

Well one thing I notice is you've got the same header guard on both files.  This might cause some of this as well.  It might only be loading one of the files, which ever one is parsed first.  The other, while included, isn't bringing in any data, since the header guard would already exist and it would ignore whatever is in the ifndef block.

 

Try making the header guards more unique.

 

Since the files seem to be in different directories, try something like GUI_SPRITE_H and RENDER_SPRITE_H.




#5195730 NULL vs nullptr

Posted by Rattrap on 01 December 2014 - 10:35 AM

There is a type safety aspect to nullptr.  See the example below

// Declarations
int func(int Input);
int func(int* Input);
 
func(0);
func(NULL);
func(nullptr);

Which version of the function gets called for each line?




#5190926 What can I improve in this code

Posted by Rattrap on 03 November 2014 - 10:11 AM

Another example on why to use nullptr over 0 (found on stackoverflow).

void f(char const *ptr);
void f(int v);
 
f(0);  //which function will be called?
f(nullptr);  // Well defined which is called.



#5190924 What can I improve in this code

Posted by Rattrap on 03 November 2014 - 10:02 AM


From what I read on msdn, I didn't quite get what are the advantages to be honest, can you explain it in a simple fashion(with an example)?

 

In the case of using 0, you are assigning an integer to a pointer.  In the case of nullptr, you are actually assigning a const pointer type to the pointer.  It also aids in readability since it better documents that this is a pointer being assigned a null value.

 

[edit]

It also can aid in catching possible typo errors, like if you accidently dereferenced the pointer.

 

*Pointer = 0; // might be ok depending on Pointer's type and any implicit conversions that might exist
*Pointer = nullptr; // error (unless it is a pointer to a pointer).



#5190903 What can I improve in this code

Posted by Rattrap on 03 November 2014 - 08:03 AM

These are more nitpicks than optimizations.
 
If you are using a C++11 compiler, when initializing your pointers to nothing, you should use nullptr instead of 0.
 

Branch()
:parent(nullptr), x(0), y(0)
{
}

 
Also, member functions that don't modify anything can be declared const. Doesn't really offer any improvement performance-wise, but does convey that the function shouldn't be changing anything internally and can sometimes help the compiler catch bugs. One example...

Branch* findRightmost() const
{
if (children.empty())
return this;
children.back()->findRightmost();
}



#5174787 So... C++14 is done :O

Posted by Rattrap on 19 August 2014 - 12:04 PM

The language shouldn't know what begin and end are.


The language doesn't, which is why std::begin and std::end must be overloaded for a particular type. So it is fairly safe to assume whomever overloaded std::begin and std::end return whatever they consider the beginning and end of the range.


#5174704 So... C++14 is done :O

Posted by Rattrap on 19 August 2014 - 06:17 AM

The constexpr system just complicates what was simple and could already be done by leaning on the preprocessor.


I personally like constepxr. I mess around with a lot of template meta-programming, and it (especially the improved C++14) let me do some compile time value generation much easier and cleaner than using enums or constants in structs. Plus it adds in type-safety, which pretty much is pretty much non-existent if you use macros.


#5165574 Visual Studio 2013 Express Desktop Intellisense stopped working

Posted by Rattrap on 08 July 2014 - 10:57 AM

I don't have Express (using Pro) but when Intellisense stops working, typically you can do Rescan Solution under the Project menu. This usually gets it going again. Haven't had to do the delete the database trick since 2010 iirc.


#5156585 What are constant references used for?

Posted by Rattrap on 28 May 2014 - 05:40 PM

Would it refer to anything? I mean, after the execution of the function, local variables with automatic block duration would be wiped out of memory, hence the reference returned by such hypothetical function would refer to garbage.

Local variables, yes. But member variables of a class that hasn't gone out of scope would persist.

Look at std::vector, the const versions of the [] operator or the at function return a const reference to the requested index.


#5153755 Karatsuba algorithm

Posted by Rattrap on 15 May 2014 - 06:15 AM

Thanks.  This has been one of those pet projects of mine that has been written and rewritten several times (bigint not Karatsuba).  I've been playing with implementing different cryptographic functions and needed it to get RSA to work.

 

Based on Wikipedia, it was saying in the 300-600 bit range should be where it beats the long multiplication method.  My default multiuplication uses the shift and add method instead of long multiplication, which tends to be faster than long multiplication as well.  So my base comparison is a little skewed to begin with.

 

I've been comparing runtimes between my Karatsuba and my shift and add based multiplication and currently Karatsuba is way slower using QueryPerformanceCounter as the metric.  Doing a test of 50 multiplies for each algorithm, even at the 25000 bit range (I was really looking for the point Karatsuba would overtake the other), it was still twice as slow.  The shift and add version only needs to two temporary vectors. My current Karatsuba implementation currently has to allocate 4 temporary vectors for each level of recursion, so I think the memory allocations are killing it.  The two vectors in shift and add grow so there are multiple allocations there too, but no where near as bad.  Plus the needed space can be pre-allocated.  I'm going to try allocating a large pool before starting the recursion and passing iterators through to see if that will help speed it up.




#5153618 Karatsuba algorithm

Posted by Rattrap on 14 May 2014 - 11:56 AM

There was a link at the bottom of the Wikipedia page for a c++ example that worked very similar to mine.  After rigging up some debugging code, I found that the issue involved the splitting and the shifting.  I added 1 before dividing the size by 2 in order to make the lower half bigger.  I assumed this would be the place to split it and trailing zeros in the upper half would "balance" it out.  Based on the other code, it looks like you want the higher order to be the larger of the two if it doesn't split perfectly.  This then caused me to use to large of a shift for Z2, since it should have been shifting by twice the "half".  I assumed that twice the half would always be the longest length, which isn't true when the number is odd.






PARTNERS