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!


Codarki

Member Since 17 Feb 2004
Offline Last Active Sep 13 2013 07:22 PM

Posts I've Made

In Topic: Code organization for larger win32 projects

13 September 2013 - 02:35 PM

I'm finding it harder to navigate the increasingly larger main source file.

Usually my main.cpp file is just a few lines. Then there's program.cpp or application.cpp. After that it gets more domain specific, high level class what the application does. Then there might be 10 more layers all down to the lowest level classes and functions. It all depends how big the program is. You should introduce higher level abstractions whenever the program grows too big, or if you know the requirements beforehand you can try to do it prematurely (beware of overengineering).

 

I'm sure if you can give an example, many of us can give our thoughts.


In Topic: Code organization for larger win32 projects

13 September 2013 - 02:19 PM

Book might be useful when dealing with Win32, but surely not when dealing with C++. Win32 is a C API. 10 years ago it was all clumped together as C/C++. C++ is totally different language than C.

 

Anyway, that was just a side-comment in my post.


In Topic: virtual destructor

13 September 2013 - 02:15 PM

 

You don't actually need virtual destructor if base class doesn't have any resources (or destructor defined). Omitting virtual destructor from virtual class really confuses developers though.

 

D3DX11 asynchronous loading/processing base classes have virtual functions without virtual destructors, which are meant to be inherited. You need derive them and introduce virtual destructor to make them work correctly.

Wrong conclusion. Those base classes don't need virtual destructors because they aren't freed by calling delete on a pointer to the base class, not because they have no resources in the base class.

 

Yes. But if you're making exception safe engine, you have to call the Destroy() functions automatically.. And for that you have to wrap it with virtual destructor. Sorry I wasn't specific enough in the exaple.

 

EDIT:

Only because documentation says they're COM objects.I remember that some of those wasn't really a COM object. Might remember be wrong. Haven't seen that deprecated crap in years.


In Topic: unique_ptr

13 September 2013 - 01:48 PM

std::unique_ptr does have an operator= overload. You can use either a nullptr_t or a std::unique_ptr rvalue as the right hand side. Similarly, it is legal to have a function that takes a std::unique_ptr by value. You'd need to call that function with a std::unique_ptr or std::auto_ptr rvalue or a nullptr_t.

 

You're right. I wasn't specific enough and was thinking only about lvalues as seen in first example here.

 

EDIT: Ok I'll try to be a bit constructive.

 

Example1:

You're right, destructors for std::vector and std::unique_ptr p are called when leaving from scope. (std::unique_ptr needs a type btw). You are moving first element of the vector to the variable p. Your Foo type is still destructible after being moved-from. You should see 11 messages. This means you're constucting 10 Foo objects and destructing 11 of them.

 

Example2:

BaseResourceObject is not used at all. I don't think Manager should have Run() virtual function. Manager is not a concrete class, I can't see the Insert() implementation. GetResource() method accesses unknown member.

 

I've used similar classes alot. I've named the classes something like asset_cache, what you call Manager. It doesn't need to be virtual. It's ok to store resource as unique_ptr and return just a reference, just make sure the Manager is destructed after all other objects who have access to the reference.


In Topic: virtual destructor

13 September 2013 - 01:30 PM

You don't actually need virtual destructor if base class doesn't have any resources (or destructor defined). Omitting virtual destructor from virtual class really confuses developers though.

 

D3DX11 asynchronous loading/processing base classes have virtual functions without virtual destructors, which are meant to be inherited. You need derive them and introduce virtual destructor to make them work correctly.


PARTNERS