Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Nov 2004
Offline Last Active Yesterday, 09:47 AM

#5255732 Problem with reading a binary file into a vector

Posted by Rattrap on 05 October 2015 - 06:09 PM

Additionally, you can move the vector declaration after you have determined the size of the file and pass the size through the constructor.

#5255731 Problem with reading a binary file into a vector

Posted by Rattrap on 05 October 2015 - 06:05 PM

Try using resize instead of reserve. Resize will allocate enough usable space, reserve is used to prevent reallocations when using push_back and emplace_back.

Try calling size after you called reserve to see how much space you had available.

#5255675 Cross platform execution branching?

Posted by Rattrap on 05 October 2015 - 10:40 AM

But I don't think #defines are globally recognized right?


No, but instead of defining those in a file, you could feed it "globally" through the compiler.  Most compilers will allow you defined values as part of the compile settings.

#5253710 can anyone explain const char*, char, strings, char array

Posted by Rattrap on 23 September 2015 - 12:54 PM

As for concrete std::string class, it will surely always write '\0' byte - if std::string class is standardized as this (http://www.cplusplus.com/reference/string/string/size/) and std::size() will return amount of bytes of explicit string ,with or without even knowing encoding of the string.


This is semantics.  You said characters earlier, now you are saying bytes.  The number of bytes is well defined.  When they were talking characters; they mean the represented characters, not the number of bytes.  In ASCII, the number of bytes = number of characters (1 character fits into 1 byte).  When you introduce a multi-byte system like Unicode (UTF-8, UTF-16, etc), multiple bytes may makeup a single represented character.  And it is not a straight 2 bytes = 1 character, you might have to iterate over the entire string to determine the number of characters.  One character might be a single byte, the next might require 3 bytes, then 4, then 2, then 1 again.

#5253487 can anyone explain const char*, char, strings, char array

Posted by Rattrap on 22 September 2015 - 11:48 AM

Servant - does the standard guarantee that std::strings data is a contiguous, null-terminated array like that? I was (perhaps mistakenly) under the impression it was not, hence the use of vector which does make such a guarantee I believe.


I believe since C++11, it is. (Following from draft standard - n3376)


21.4.1 basic_string general requirements

5 The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string

object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0

<= n < s.size().


I don't believe it was pre C++11.

#5247539 Lots of syntax errors when using abstract classes

Posted by Rattrap on 18 August 2015 - 07:15 PM

You've got circular dependencies. Your header files are referencing each other. You can probably break some of this by forward declaring BuddyEngine in Manager.hpp instead of including the BuddyEngine header.

I'm on my phone right now, so not easy to go into more detail.

#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




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);

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.



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.

: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;