Jump to content
  • Advertisement
Sign in to follow this  
Chris81

Yay or Nay on an object system that requires default constructors?

This topic is 4992 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Thanks AR, works like a charm! Here is the new version, which looks much better.


LogPtr log = new Log( "SOUND" );
log->AddDest( new LogFile( "sound.log", LOW ) );
log->AddDest( new LogConsole( LOW ) );
log->AddDest( new LogScreen( HIGH ) );

log->Error( "This is a test 1" ); // MEDIUM by default
log->Error( HIGH, "Lalala: %s (%d)", "Hello, World!", 123.45 );



Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Andrew Russell
I'm not 100% sure on the inheritibility of operator new. I'm fairly sure it is inherited, but you'll probably want to check it or try it. (edit: after a quick hunt I couldn't find anything about its inhertability, so I would be surprised if it wasn't).

Additionally - operator new recieves a size (of type size_t), so you don't need to sizeof anything.

But yes - it sounds like you have the right idea, good luck with it [smile].


It is inherited and is the method I use. The root of my hierarchy is 'struct Interface' and it declares a virtual dtor (so you can never forget) and it overloads new & delete. Just like ctor's if you overload new and give it additional parameters, it hides the default version. So in debug builds I have a special new that takes the lile, file, & typeid, etc... of the instantiation.
A map is maintained as objects are created & destroyed, and once the program terminates it dumps whatever is left in the map.



#ifndef MKH_INTERFACE_HPP
#define MKH_INTERFACE_HPP

/* This is the root header file for the MKH Object Model
* It is like COM or CCM (CORBA 3) with two significant differences.
* Unlike CCM or COM, there is no focus on distributed objects, if you need
* distributed objects, use CCM or COM! This OM (Object Model) is designed
* for easy-of-use and simplicity in the C++ environment, as opposed to the
* complicated & language-neutral design of COM and/or CCM.
*
* This object model should be used for objects internal to the software, and
* then "tear-off" or "composite" CCM interfaces should be provided by these
* objects for remoting when needed. This allows us to benefit from a
* centralized object model while minimizing the intrusive nature of such
* heavy-weight solutions such as CORBA by restricting thier use only to
* objects that need actually remoting services.
* (As opposed to the alternative of using IDL/CCM/CORBA for all object interfaces.)
*/


#include <cstddef>

#ifndef NDEBUG
#include <typeinfo>
#endif

namespace mkh
{
namespace ood
{
struct Interface;

//Inheriting from this provides the requisite virtual dtor
// and consequentially enables RTTI for the derived object
struct Interface
{
//This is the only requirement for a polymorphic C++
// object (and it will be automatic in C++0x)
virtual ~Interface() {}

//new and delete overloads are provided to
// consolidate memory allocation. This prevents
// objects from being created with the context of one
// free-store, and destroyed in the context of another.
// This is particularily troublesome when using dynamic
// linking on Win32 (causes hard-crashes) - it is
// always a bug in your code to do this, you are
// corrupting the free-store. This fixes that problem
// because this new and delete overload will be invoked
// and the code in this library will create and destroy
// all ood objects.
// It also forces the allocation of objects to use the
// debug version for debug builds, allowing us to track
// memory usage and detect objects leaks.
// You should use mkh_new to 'new' objects that
// inherit from ood::Interface
#ifndef NDEBUG
//Use must use this debug version of operator new to create objects
#ifdef _MSC_VER
#define mkh_new(ObjectType) new(__LINE__,__FILE__, typeid(ObjectType), __FUNCTION__) ObjectType
#else
#define mkh_new(ObjectType) new(__LINE__,__FILE__, typeid(ObjectType)) ObjectType
#endif
static void* operator new
(size_t, int line, const char* file, const std::type_info&, const char* function =0);
static void* operator new[]
(size_t, int line, const char* file, const std::type_info&, const char* function =0);

//overloaded delete in case overloaded new throws
static void operator delete
(void*, int line, const char* file, const std::type_info&, const char* function);
static void operator delete[]
(void*, int line, const char* file, const std::type_info&, const char* function);
#else
#define mkh_new(ObjectType) new ObjectType
static void* operator new(size_t);
static void* operator new[](size_t);
#endif
//The delete's that typically are invoked
static void operator delete(void*);
static void operator delete[](void*);
};
}//ns ood
}//ns mkh

#endif //MKH_INTERFACE_HPP


Share this post


Link to post
Share on other sites
Quote:
Original post by Andrew Russell
Mostly because it's not as pretty.

*** Source Snippet Removed ***

There's no major technical reason to use either. Although yours does require the explicit specification of a type, which would make maintinence slightly harder.


You should only have to tell it the return type, it should figure out the types of P1 & P2. But this is essentially how new works.

Foo* foo = Create<Foo>(x, y);

Share this post


Link to post
Share on other sites
Quote:
Original post by Chris81
Yay or nay on if this a good idea? Will it cause a lot of problems in the long run?

In general, default construction is a good thing. The only classes you don't want default construction is for RAII classes (e.g. smart_pointers). However, building a factory that requires it doesn't seem like a good idea. There always seems to be a couple of cases where you want to pass a pointer to some other class when you create a new one.


(Also, this isn't garbage collection, it is an object-lifetime-management-strategy. Garbage collection is one method, this is another.)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!