I'm trying to figure out a way to keep track of all the instances of a class I have made, so I can access them at any point using a title string (or int ID)
I decided to use a static vector of pointers to each instance, and then on creating each instance i'd add a pointer to it to the vector.
This works up to a point but at one point the values inside each element of the vector seem to reset/get randomly assigned values and i can't figure out what's happening.
i'm adding the object to the vector here:
SWindow::SWindow(LPCWSTR WindowClass, LPCWSTR Title, UINT Style, int x, int y, int height, int width, HWND hParWnd, HINSTANCE hInstance)
:
x(x),
y(y)
{
hWnd = CreateWindowEx(NULL, WindowClass, Title, Style, x, y, height, width, hParWnd, NULL, hInstance, NULL);
SWindows.push_back(this);
The function at which the values change is:
which is a member of the SWindow class
SWindow.h:
static SWindow* GetSWindow(wstring ws);
SWindow.cpp:
SWindow* SWindow::GetSWindow(wstring ws)
{
for (int i = 0; i < SWindow::SWindows.size(); i++)
{
if (SWindows[i]->title == ws)
{
return SWindows[i];
}
else
{
}
}
return 0;
}
i'm accessing the function from a different class using:
SWindow* pPlayViewer = SWindow::GetSWindow(L"Viewer");
Also if this is a bad way to be doing what i am trying to do, let me know of a better way.
Thanks!
Are you sure that you didn't add stack allocated objects into your static vector? Did you remove pointers when objects are deleted ?
If you want to be more efficient, I can suggest you to use a map, where the key can be your title string/id int and the value the pointer, so that the search would be much faster than parsing the whole array.
There are four main possible causes for the dangling pointers:
you do not remove the instances from the vector upon destruction of an instance
you create instances accross DLL boundaries (and pass the vector arround)
you have a buffer overflow (or similar) in another part of the code and it is overwriting your vector
you are accessing the vector concurrently from multiple threads (and the access to it doesn't look synchronized in your code)
(this is all speculation on my part).
To use such a vector correctly, you will have to do the following:
implement all constructors and destructor for your class (this implies you will also implement the assignment operators, according to the rule of five).
ensure all constructors add this to the vector
ensure destructor removes this from the vector
Also, suggested refactorings:
pass the vector into the object, instead of declaring it as static; this will allow you to decide in client code if you have a single vector, multiple ones, or a window manager object of some sort, that holds a vector internally
group the window creation parameters into a structure, and pass that arround as a parameter
your SWindow class wants to be both a window manager and a window; Extract the window management into a separate object
Related
I have a Display class that uses SDL to write pixels to the screen. I'd like another class (Triangle) to be able to use this already existent class object, so I've been trying to pass the object by address.
It's sort of working, in the sense that it is actually calling the methods. However, I was getting a segmentation fault in the DrawPixel function. After checking gdb and checking what values are in the function, I figured out that the color_buffer array does not exist (note that when DrawPixel is called directly from the display class in main it works fine).
After a little more testing, I determined that window_width, window_height etc are not set in the Triangle's version of the Display object. But they do exist in the original Display object.
So I'm assuming that I am not properly passing in my object, but I'm uncertain how to fix this issue as I thought passing by address would work just fine. How can I pass an already existing/instantiated class to another class?
I've also tried putting color_buffer into public variables in case private was causing it, but that didn't help.
Example:
main.cpp
int main() {
Display display;
Triangle triangle(&display);
// This doesn't work
triangle.DrawTriangle(300, 500, 0xFFFFFF00);
// This does work
display.DrawPixel(300, 500, 0xFFFFFF00);
return 0;
}
triangle.hpp
class Triangle {
private:
Display* display;
public:
DrawTriangle(int x, int y, uint32_t color);
};
triangle.cpp
Triangle::Triangle(Display* display) {
display=display;
}
Triangle::DrawTriangle(int x, int y, uint32_t color) {
display->DrawPixel(x, y, color);
}
display.hpp
class Display {
private:
// SDL Stuff defined here
uint32_t* color_buffer;
int window_width = 1920;
int window_height = 1080;
public:
Display();
DrawPixel(int x, int y, uint32_t color);
};
display.cpp
Display::Display() {
// SDL Stuff declared
color_buffer = new uint32_t[window_width * window_height];
}
Display::DrawPixel(int x, int y, uint32_t color) {
// This is receiving the correct values, but doesn't allow me to access
// any index of color_buffer.
color_buffer[(y * window_width) + x] = color;
}
Triangle::Triangle(Display* display) {
display=display;
}
the display is not the member of your class.Use this->display = display instead
You have to use "this" in Triangle constructor. That should solve the problem.
Triangle(Display* display) {
this->display=display;
}
A couple of things to add to the answers above:
use a different naming convention for member variables - this way it is very easy to avoid typos. _display, m_display, Display_ (Clang style =) )
class members are private by default so if you are following convention where attributes are defined on top, there's no need to add private:
Some prefer references (e.g. Display&), mostly to save typing ->, since if `Display goes out of scope it will have the same hilarious effect as passing a pointer.
static analyzers look down on pointer arithmetic(due to possible out-of-bounds writes).
You can use std::array from header:
static constexpr int WIDTH = 1920;
static constexpr int HEIGHT = 1080;
std::array<uint32_t, WIDTH* HEIGHT> m_color_buffer{};
and then either use m_color_buffer[index] = color (no bounds checking, random memory gets written if you write out of bounds in release and normally an exception in debug), or use m_color_buffer.at(index) - slower but this way you get an exception in release mode, but the compiler may complain about the stack size, as the definition is essentially the same as uint32_t buffer[WIDTH*HEIGHT]. std::vector is a better alternative - it hides buffer allocation, manages memory (no need to delete) at expense of the 2 extra pointers for begin and the end of the vector.
The code example lacked a destructor. Every new should have an accompanying delete hence either add it or just switch to a standard library container to avoid the headache =)
Last but not least - both classes override constructors. Display also manages resources. What happens when you copy Display instances? Move them? It is a bit of a headache and leads to a bit of a boilerplate, but it is best to implement Rule of 5 members and avoid accidental surprises =)
PS. C++ is a beautiful language =)
I'm currently designing classes that should represent a chaotic storage system.
Lets say we have slots in rows and columns with certain properties.
So the slots have different restrictions in min/max height, width, length, weight and some more that come from a parameter file.
Also the Slots have a max total weight that must be checked before a new parcel gets added to that slot. And also the max weight that a row of slots can hold is lower than the sum of the max weights of the single slots. So for example each individual slot might be able to hold 50kg but the row of 10 slots must not exceed 200kg, so it is not allowed to fill every slot by 100%. The same is true for the Columns where the maximum weight is lower than the sum of the individual weights of the single rows. The row_id and column_id are atrificial numbers for adressing the slot in the physical system with barcodes or whatever that get read for positioning.
As all this parameters do not change over the lifetime of the program, my intention was to design the classes in a way that this properties are readable by getter functions but there should not be any setter functions (maybe not even private ones) in the object o the values cannot be changed by accident.
There is one class/function that reads the config-file and generates the data structure for the rows and columns with the slots. This function should be able to read the config and create objects for every column holding a row of slots and pass all the values from the config down to the slot.
Later when the program is running I also need some way to search for the best matching slot to add the next parcel or for searching parcels and unload them in a certain sequence.
So the (simplfied) basic structure of the classes would be like this:
Class Parcel {
int width;
int height;
int length;
int weight;
}
Class Slot {
vector<Parcel> parcel;
int min_width;
int max_width;
int min_height;
int max_height;
int min_length;
int max_length;
int max_total_weight;
int act_total_weight;
int total_length;
int free_length;
}
Class Row {
vector<Slot> slot;
int row_id;
int max_total_weight;
int act_total_weight;
}
Class Column {
vector<Row> row;
int column_id;
int max_total_weight;
int act_total_weight;
}
Class Storage {
vector<Column> column;
}
So here are my thoughts about how to initialize the data structure:
First possibility would be to pass all the properties in the constructor(s) of the classes, but then the constructors has some huge parameter lists specially for the Slot class that has a lot of properties.
Second thing that came to my mind (and currently my fafourite way to go) is to use config-data-structures that hold all the parameters. This parameter-objects get filled by the config-function and passed to the constructor when initializing the class. Then it also may be useful to use the parameter class as such and not having all the parameters defined in the storage class once more.
Third way is to use private setter and public getter and make the config class friends with the data structure classes to be able to access the setter functions (but i would prefer to have no setters at all in the final storage structure classes.
Fourth way that i was thinking off, was to derive child classes from the structure classes that hold the setter functions (and also some other logic needed for creating the data structure) so the child has no own variables but only additional functions. So the child class is used to fill the properties but the base class gets added to the data structure vector.
I also want to use Factory pattern to initialize the data structure because the objects have often similar or only slightly different properties. So with the second aproach after creating one row of slots I would maybe want to change the max weight of the slots in that row. Therefore I would need to change the setting in the factory and the factory then fills the parameter data structure differently and passes it to the Slot class. Or is it better to pass the data structure to the factory directly and the factory assigns it but then i think this is not what the factory pattern is meant to be.
I don't know if this is a good aproach or which of the above is best practice.
Or am I missing something and there is a way more convenient solution or this?
Thank you (and sorry if the question is maybe not the way it should be)
When constructing your classes as you describe it you can have a look at the creational design patterns.
Your second proposed solution is almost a builder design pattern. This will help you to construct the Slot e.g. piecewise.
As an example:
#include <iostream>
class Slot {
public:
int GetMinWidth() const { return min_width_; };
int GetMaxWidth() const { return max_width_; };
// Builder class
class SlotBuilder {
public:
SlotBuilder& SetMinWidth(int min_width) {
min_width_ = min_width;
return *this;
}
SlotBuilder& SetMaxWidth(int max_width) {
max_width_ = max_width;
return *this;
}
Slot Build() {
return Slot(min_width_, max_width_);
}
private:
int min_width_{/* you can add default value here*/};
int max_width_{/* you can add default value here*/};
};
// This is optional, but creates a neat interface
static SlotBuilder Create() {
static SlotBuilder slot_builder;
return slot_builder;
}
private:
// Make constructor private to restrict access and force the use of the builder
Slot(int min_width, int max_width) : min_width_(min_width), max_width_(max_width) {}
const int min_width_;
const int max_width_;
// .
// .
// Continue with your const attributes
};
int main() {
// Create the slot with the builder
Slot slot = Slot::Create()
.SetMinWidth(10)
.SetMaxWidth(20)
.Build();
std::cout << slot.GetMinWidth() << ", " << slot.GetMaxWidth();
return 0;
}
You can see the example working here
For having different types that are almost the same a Prototype pattern could work if you want to "clone" a class or in your case a Factory pattern could do the job.
There is never an ideal solution or that one pattern that solves it all, so I can't give you a definitive answer, but here are some collected thoughts:
Default values
Primitive types like int don't have a default value, so make sure you give them one explicitly:
struct Parcel {
int width{};
int height = 0;
int length = {};
int weight{};
}
All those different versions above are equivalent, but you really should use one of them. Otherwise you will probably run into UB down the line.
Const correctness
One thing that I love about C++ and that I dearly miss in languages like C# is const correctness. If you want an object to be immutable, declare it as const. To prevent changes to your objects, either instantiate the object as a const:
const Parcel x;
x.width = 10; // compiler error
or make the members of your classes const:
struct Parcel {
const int width{};
const int height{};
const int length{};
const int weight{};
};
Parcel x;
x.width = 10; // compiler error
Aggregate initialization
If you keep your types simple enough you can initialize the class members with curly braces directly:
const Parcel x { 1, 2, 3, 4 };
In C++ 20, you can also name the members, so this code is equivalent to the line above:
const Parcel x { .width = 1, .height = 2, .length = 3, .weight = 4 };
Note that this can bite you later though if you have to deal with ABI stability and versioning. In that case you are better off using getter and setter functions, because that allows you to still change the data layout of your members.
I have to think about design patterns a bit more. I'll update this post if something useful comes out of it.
Basically, I have two classes, Peg and Disk. (It's a Towers of Hanoi program) The files I have are Disk.h, Disk.cpp, Peg.h, Peg.cpp, and main.cpp. Not sure if that matters. Here's the disk class from Disk.h
#include <vector>
#include "gwindow.h"
#ifndef DISK_H
#define DISK_H
class Disk
{
private:
int xCoord; //x and y coords are for drawing in a gwindow
int yCoord;
int mHeight;
int mWidth;
COLOR mColor;
int mName; //helps me keep track of which is which
public:
Disk(); //default constructor
Disk(int x, int y, int heightIn, int widthIn, COLOR colorIn);
void setXY(int x, int y); //this is the one I'm having trouble with
int getHeight();
int getWidth();
int getX();
int getY();
COLOR getColor();
std::string diskColor();
void draw(GWindow &gw);
void nameDisk(int name); //yet this one is working?
int getName();
};
#endif
However, I'm having trouble with the setXY function. When I call it from main, it calls the function properly, changes the variable inside the scope of setXY, but the value doesn't persist outside the function. However, nameDisk works fine and is basically the same thing, except it is changing mName instead of xCoord and yCoord. Here is setXY:
void Disk::setXY(int x, int y)
{
xCoord = x;
yCoord= y;
}
and here is how I call it from main:
pegVec[2].getDisks()[0].setXY(690, 200);
I know this looks crazy, but basically pegVec is a vector of 3 peg objects. Each peg object has a function, getDisks(), which returns a vector of all the disks on that peg currently. So the line above is trying to perform setXY on the first peg on peg 2. Sorry if that's unclear, but I've tried making a new disk object and calling it on that and that didn't work either.
Here is getDisks, if it matters:
std::vector<Disk> Peg::getDisks()
{
return disksOn;
}
and disksOn is just a member variable of Peg:
std::vector<Disk> disksOn;
I think it might be a problem with how getDisks() works. I'm a noob, but I'm guessing that returning the vector disksOn makes a "copy" of it, kind of, which is what I am altering with my setXY function but which is not the same as the actual disksOn vector associated with the Peg object? I don't know if that makes sense.
What I've tried so far:
Making xCoord and yCoord public variables and updating them manually instead of making a setter function. This did not work.
I printed out the x and y values at every step. Inside setXY, the values were updated successfully, but when the function ended they went back to how they were.
I tried some mess with the const keyword, but I don't understand it and couldn't even get it to run.
Passing everything by reference/value
Making a new function in main which accepted a Disk vector as input, and using getDisks as input to that function. Didn't work, same problems.
Tested my other setter function, nameDisk, which works fine. It's essentially the same as setXY, which is why I think the problem is with getDisks.
Using pointers at various points (heh) throughout, but I wasn't sure the best way to do that. I was messing with it last night so I don't remember 100% but I think I tried to have getDisks return a pointer instead of the vector, and I don't think that worked, but it's more likely a problem with my syntax and how I used the pointer. I think that might work but I don't know how to shake it.
Help?
You're on the right track - somehow you're looking at a different objects than what you think you are. Using references is a good solution, but you may not have got the right one ;-)
Try:
// Return reference to the disks on the peg.
std::vector<Disk>& Peg::getDisks()
{
return disksOn;
}
The issue is that
std::vector<Disk> getDisks() { return disksOn; }
returns a completely new and separate temporary copy of disksOn rather than a reference to the original. So you're modifying a temporary copy which gets discarded at the end of the statement.
You need to use
std::vector<Disk> &getDisks() { return disksOn; } in order to return a reference to disksOn.
Although if you are going to return a reference to the vector member object you might as well make the object directly accessible as public because anyone can manipulate the vector at this point and get rid of the getDisks() function as it serves no purpose in terms of access protection.
Better design would be to give access to individual disks:
Disk &getDisk(int index) {
return disksOn[index];
}
const Disk &getDisk(int index) const {
return disksOn[index];
}
The idea behind not giving direct access to the vector is that you can later change the underlying container type if needed without changing the code outside of the Peg class.
The second version (const) is necessary for accessing const Disks of const Peg objects.
I'm having trouble implementing an ImageManager into my program. I had success using this method with references:
//definition in Brick.h
ImageManager &imgr;
//constructor taking &imgr as a reference upon creation of object
Brick::Brick(ImageManager &im) : imgr(im){
//imgr is now a reference in my class, so it points to the same object that imgr in another class would point to
//this essentially makes one "static" instance of imgr, so all my graphic objects are dealing with the same instance of my ImageManager
imgr.doStuff()
}
This method of passing around my imgr used to work, until I started trying to remove obejcts from vectors. For instance, in my Level class I try to remove elements from a vector of Brick objects,
void Level::RemoveLine(int line){
//loop through every piece, loop through given piece's rects, if the rect falls on the removed line, then remove the piece
for(int i = 0; i < gamePieces_.size(); i++){
//crt new iterator per each gamepiece
auto write = gamePieces_[i].GetPieceRectangles().begin();
int j = 0;
for(auto read = write; read != gamePieces_[i].GetPieceRectangles().end(); read++){
if(gamePieces_[i].GetPieceRectangles()[j].GetActiveLine() != line){
if(read != write){
write = std::move(read);
}
write++;
}
}
gamePieces_[i].GetPieceRectangles().erase(write, gamePieces_[i].GetPieceRectangles().end());
}
}
but this doesn't work because ImageManager &imgr declared in Brick.h doesn't have a copy constructor, so it can't be copied in vectors when I try to .erase() the element. My goal is to implement one static ImageManager object to be used throughout all my classes. How would I go about doing this?
"My goal is to implement one static ImageManager object to be used throughout all my classes"
You can implement ImageManager as Singleton class. But I have learnt to use singleton only if there's no other option.
You can also use static data members in your class. In this way only one copy of your class's data members would be in circulation.
Generally speaking this kind of code isn't what you want. Take a look at the Singleton design pattern.
https://en.wikipedia.org/wiki/Singleton_pattern
I'm writing a C++ framework so that I can rewrite some software to work on multiple platforms. The question I have pertains to an implementation of some wrapper classes that use Windows handles. Consider the following code...
class Font
{
public:
Font(const LOGFONT& lf)
{
m_hFont = ::CreateFontIndirect(lf);
}
~Font()
{
::DeleteObject(m_hFont);
}
private:
HFONT m_hFont;
}
I then have a Display class where I might call the following...
LOGFONT lf;
// initialise lf
Display d;
d.SetFont(Font(lf));
d.DrawText(0,0,"Some Text");
The problem of course is that d.SetFont will result in the m_hFont being deleted by the Font class destructor. I appreciate that I could create the font on the heap and let the graphics class be responsible for the Font's overall "lifetime". I guess that this is really a design issue. Is it better to...
Implement reference counting for classes that wrap Windows Handles.
Create wrapper classes on the heap.
Some other method?
I notice that MFC has an explicit DeleteObject in their wrappers but this of course does not result in automatic resource de-allocation.
Any help/advice appreciated.
Thanks
EDIT: I think this is more of a copy constructor question. I.e. My Font class creates a Windows FONT handle, but is destroyed because I pass the Font object to the display by value.
You have at least three options:
Mind "the rule of three": if a class has a non trivial destructor then it should probably also implement a copy constructor and an copy assignment operator. In this case, they should insure that every copy has its own version of a m_hFont.
Use reference counting.
Change Display::SetFont to accept a pointer to a Font or a const reference. That way you can still create the Font "on the stack" and, if you only pass a pointer or a reference to it there will be no copies being made.
EDIT
You might be able to avoid the problem entirely if you make Display::SetFont accept a LOGFONT directly. This way, the Display class itself will manage the fonts (e.g. delete the old font structure and create the new). This option works best if you plan to use the Font object only in the context above (with a Display) and if the font changes are few.
Make the Font class also hold the LOGFONT as a member and generate the HFONT only on demand. When copied, the LOGFONT will be copied and the HFONT be given an invalid value. If the new Font::GetFont is called (say by the Display) then the HFONT will be created. In the Font destructor, if the HFONT is not the invalid value delete it. This will avoid some unnecessary calls to CreateFontIndirect if not all the copies will be used to call GetFont.
That's the nature of Windows. When you use resources in such a way like calling CreateFontIndirect, you'd have have to call DeleteObject or a method of some sort to release resources when you're done. What exactly is the problem? Is your program not behaving as expected? It should be fine unless lf goes out of scope before you use it.
Following advice from the answers and some further thought I have adopted the following approach. I think that the Display class should manage the font's lifetime. Library users would supply font settings to the display class. Basic code is as follows...
struct Typeface
{
bool Bold;
int Width;
int Height;
};
class Font
{
public:
Font();
~Font(); // calls DeleteObject(m_hFont)
HFONT Handle() const { return m_hFont; }
// Create will destroy the current font handle and create a new one
void Create(const Typeface & tc);
private:
HFONT m_hFont;
};
class Display
{
public:
// select font modifies the display's current font
void SelectFont(const Typeface& tf);
// Draw a string using the display's selected font
void DrawString(int x, int y, const String& text);
// Draw a string using the supplied font
void DrawString(int x, int y, const String& text, const Font& font);
private:
Font m_hSelectedFont; // Font handle automatically destroyed
};
I think this is the most convenient solution in C++20:
using XHFONT = unique_ptr<remove_reference_t<decltype(*HFONT())>, decltype([]( HFONT hf ) { hf && DeleteObject( hf ); })>;
unique_ptr<> can only manage data for pointers, but fortunately Windows hanlde are always pointers, usually declared with DECLARE_HANDLE, and you can declare wrappers for any Windows hanlde type except HANDLE because a HANDLE is simply a void-pointer where remove_reference_t<decltype(*HFONT())> doesn't work.