Monami

I am in the process of making an abstraction layer in c++ between my objects and the Max api, so far so good...

first i know that wakefield made some template to make external in c++. I didn't like the approach and I didn't found it object oriented enough... Sorry wakefield, it is just a question of taste.

This said, what I am doing is trying to hide the api behind a pimpl object which is a singleton. Now, this is my main question:

In the function class_new, you have to give a reference to 2 functions mnew and mfree...

when those are acutally called? Because I am kind of not really creating my object there... the mnew just collect the t_symbol and t_atom and the mfree just do some cleanup of inlet, outlet and deallocate the space allocated by object_new.

Which lead to my other question, when actually the end of my main is reach? when Max5 destroy my object?

I also found an inconsystency in the api. I though it would be nice to report... Or at least inquire about...

The fonction sysmem_newptr return a t_prt (typedef char *t_ptr;)

and the function proxy_new and outlet_new return void*, shouldn,t both return the same type?

first i know that wakefield made some template to make external in c++. I didn't like the approach and I didn't found it object oriented enough... Sorry wakefield, it is just a question of taste. 

In the function class_new, you have to give a reference to 2 functions mnew and mfree... 

The fonction sysmem_newptr return a t_prt (typedef char *t_ptr;)
and the function proxy_new and outlet_new return void*, shouldn,t both return the same type?

object-creation-question

The main function does not allocate any objects, it just registers the object type with max's object system. This gets called usually the first time you try to create a max object (e.g. in the patcher) with its name. I'm pretty sure that main() exits before your new function is called; you can verify this with a few calls to post().

The new and free functions are called when you create or destroy a max object (e.g. in the patcher). The memory for the object struct itself is explicitly allocated through object_alloc(), but implicitly freed. Any additional memory to be allocated or freed is your responsibility in the new / free functions.

Watch out for using static variables; they will be shared by every instance of your object. I'm not sure that a singleton pattern is going to work because of that. Try making two instances of your object in a patch and see how they behave...

PS. The API comes from a very C oriented background, and much of it has remained pretty much stable for many many years. I think the inconsistencies between pointer types are partly a legacy, but also partly an integral part of a C-based object system in which casting pointers is commonplace.

The main function does not allocate any objects, it just registers the object type with max's object system. This gets called usually the first time you try to create a max object (e.g. in the patcher) with its name. I'm pretty sure that main() exits before your new function is called; you can verify this with a few calls to post(). 

The new and free functions are called when you create or destroy a max object (e.g. in the patcher). The memory for the object struct itself is explicitly allocated through object_alloc(), but implicitly freed. Any additional memory to be allocated or freed is your responsibility in the new / free functions. 

PS. The API comes from a very C oriented background, and much of it has remained pretty much stable for many many years. I think the inconsistencies between pointer types are partly a legacy, but also partly an integral part of a C-based object system in which casting pointers is commonplace.


I am starting to think that the way I did things will not work... I was about to test with post exactly when the new and free function are called, but so far my object crashed with bad_acces when I try to do object_alloc(). I guess it has to do with my t_class pointer.

Has for Singleton this is how I am doing it...

static T Instance; ///< Unique instance of the singleton.

template T Singleton::Instance; // Singleton Instance definition.

This way my base class that contain t_class herite from Singleton so through injection the class is a static class that can't be copied. (Or maybe this is where my mistake is) After that the class MaxImpl (that is a derivative of MaxBaseImpl) will implement the create and free function...

Well I guess that I am passing the wrong pointer to object_alloc()...

For thecasting pointer, I realized that... just I don't like to reinterpret_cast in my code!

thanks for the tips... I'll try to find what I am doing wrong

Has for Singleton this is how I am doing it... 

   template  
      class Singleton : private Uncopyable


      {
      public:
         ///
         /// Return the singleton object.
         ///
         static T& GetSingleton()
         {
            return Instance;
         }

         static T Instance; ///< Unique instance of the singleton.
      };

   template  T Singleton::Instance; // Singleton Instance definition.

This way my base class that contain t_class herite from Singleton so through injection the class is a static class that can't be copied. (Or maybe this is where my mistake is) After that the class MaxImpl (that is a derivative of MaxBaseImpl) will implement the create and free function...
Well I guess that I am passing the wrong pointer to object_alloc()...

For thecasting pointer, I realized that... just I don't like to reinterpret_cast in my code! 

thanks for the tips... I'll try to find what I am doing wrong 

It's hard to see what exactly you are doing... the code you posted doesn't show anything from the Max API.

But, I think a singleton pattern isn't going to work for Max objects, because you can't stop a user from making more than one instance of your max object in a patcher. Or maybe I didn't understand what you are trying to do?

It's hard to see what exactly you are doing... the code you posted doesn't show anything from the Max API. 

But, I think a singleton pattern isn't going to work for Max objects, because you can't stop a user from making more than one instance of your max object in a patcher. Or maybe I didn't understand what you are trying to do?


Sorry, I know that the code that I posted doesn't show any of the max API.. It was just the class that I use for the Singleton...

You are saing that the singleton might not work, but isn't the object class_t should only be instantiated once? It shouldn't be copied or cloned... I think the pattern of singleton suit that no?

Because I learn OO programming and c++ the way the api is shown how code is kind of bugging me and I know I can make some classes and wrapper to make it more OO... and more managable, easier to understand. I find the example, even the simplemax really all entangled. I understand the example but I don't know everything under the hood of the api (we don't have acces to the source code).

1. Create an abstraction layer between the api and my object. 

2. Put some security around the api: const, volatile.... and tryto make it more type safe, staic_cast, dynamic_cast ( no C style cast and in absulutly last resort reinterpret_cast)

3. Try to keep intact encapsulation ( but I fear just because the way Max create object I can't have that at the root, ther is no deterministic creation/destruction. 

4. Easy to use, and re-use as much as possible...

My Idea, was to hide the api the object_t and class_t behind a pimpl, use template for either a jitter object or a max object ( I don't really do Msp...) the public interface would show only service that my object would use to construct=destruct himself, register function ( maybe delegates?)...

My first problem was with the allocation... It seams that the t_object, t_class and my object need to be part from one herarchie.

Since you made those template in c++. In fact I want to push what you did further... Do you have any suggestion tip insight? I would appraciate to discuss about this with you... I think it could be interesting.

You are saing that the singleton might not work, but isn't the object class_t should only be instantiated once? It shouldn't be copied or cloned... I think the pattern of singleton suit that no?
Because I learn OO programming and c++ the way the api is shown how code is kind of bugging me and I know I can make some classes and wrapper to make it more OO... and more managable, easier to understand. I find the example, even the simplemax really all entangled. I understand the example but I don't know everything under the hood of the api (we don't have acces to the source code).

1. Create an abstraction layer between the api and my object. 
2. Put some security around the api: const, volatile.... and tryto make it more type safe, staic_cast, dynamic_cast ( no C style cast and in absulutly last resort reinterpret_cast)
3. Try to keep intact encapsulation ( but I fear just because the way Max create object I can't have that at the root, ther is no deterministic creation/destruction. 
4. Easy to use, and re-use as much as possible...

Oh I see. Yes, I guess the t_class could be owned by a singleton... but it's only a single void *, it might as well just be a static class member, no?

The only way to encapsulate max objects is by overloading the new and delete operators, since Max needs to take care of the memory. This is not so unusual for a dynamic host environment.

Max's API is actually OO, just using C rather than using C++. Objects, classes, methods and so on are managed using run-time rather than compile-time definitions. This is what the t_class and main() function are all about. That's also why it's a bit opaque sometimes, and at other times includes lots of pointer casting or memory fudging, at least to the eyes of a C++ programmer.

Sounds like what you want to do isn't so far away from what I did with the Max template classes. As much as templates can make code cleaner, there is a limit to how much the run-time object system of max can be encapsulated in the compile-time object system of C++ / templates. Registering functions gets quite messy, because method pointers, and especially template class instance member functions, are tricky to coerce into C-like function pointers...

The only way to encapsulate max objects is by overloading the new and delete operators, since Max needs to take care of the memory. This is not so unusual for a dynamic host environment. 

Sounds like what you want to do isn't so far away from what I did with the Max template classes. As much as templates can make code cleaner, there is a limit to how much the run-time object system of max can be encapsulated in the compile-time object system of C++ / templates. Registering functions gets quite messy, because method pointers, and especially template class instance member functions, are tricky to coerce into C-like function pointers... 

hey wow thanks it is interesting what you are saying the it is actually OO...

I didn't quite understand one thing you said can you precise

Objects, classes, methods and so on are managed using run-time rather than compile-time definitions. This is what the t_class and main() function are all about.

What doyou mean by manged run-time, instead of compile... I guess when you speak of max objects, classes like t_object, t_atom, t_symbol? and what «action» you imply by managed. Sorry if i am specific like that. I've been wondering about the way max operate in it iside ( i know it is probalby liscened and copyrighted, but i'd like to know what i can know and the principles)

For the singleton you are right, but I have this utility class and it prevent me to make copy of the object as a plus. It help in writing less code! it is ala CRTP Iguess.

About the function class_new, the param size is describe like this. The size of the object's data structure. What actually should be part of this size. It might seam trivial but since I am trying to decuple the max thing from my stuff, it is not so trivial... My guess is all the attributes of my object, but what about inlets, outlets? the t_class object?

As for oveloading thennew and delete, I actually to inject it by one parents...

class Foo: Max_new
{
  //really important stuff

};

I just don't know if a assisted placement new can be generic..

hey wow thanks it is interesting what you are saying the it is actually OO... 

Quote:Objects, classes, methods and so on are managed using run-time rather than compile-time definitions. This is what the t_class and main() function are all about.

More specficly:
What doyou mean by manged run-time, instead of compile... I guess when you speak of max objects, classes like t_object, t_atom, t_symbol? and what «action» you imply by managed. Sorry if i am specific like that. I've been wondering about the way max operate in it iside ( i know it is probalby liscened and copyrighted, but i'd like to know what i can know and the principles)

For the singleton you are right, but I have this utility class and it prevent me to make copy of the object as a plus. It help in writing less code!  it is ala CRTP Iguess.

As for oveloading thennew and delete, I actually to inject it by one parents... 

Sorry again... Somthing in you code of maxcpp5 intrigue me how this is possible in your destroy function

x is a t_object which is an member of your MaxCpp5 class which is a parent of your class.

I am supposing that the api pass you t_object m_ob to the fonction destroy. So casting it in the child doesn't make sens to me... How does a member of MaxCpp5 relates to a child of MaxCpp5?

Because a pointer to a struct is the same value as a pointer to its first member. That's why it is important in Max objects to always have the t_object as the first member of the struct. This also works for simple C++ classes, but may break for virtual/multiple inheritance (can't remember.)

Max's class system is runtime, in the sense that a class is an object (t_class) which can be manipulated at runtime (e.g. adding new methods).

The size passed to object_new() should be exactly that, the sizeof the struct (or C++ class).

I made some progress but I get something weird:

It enter 3 times in my main????? and my fonction where there is my class_new methode.

The object doesn't appear as bogus, but the create and free (the one that I passed the pointer to the methode class_new)method where never called since I don't have any post in the max window...

Quote:Entering Main function
Entering RegisterMaxClass function
Quitting Main function
Entering Main function
Entering RegisterMaxClass function
Quitting Main function
Entering Main function
Entering RegisterMaxClass function
Quitting Main function

Because a pointer to a struct is the same value as a pointer to its first member.

When yousay t_object should be the first is this allright?

class MyClass
{
public:
   MyClass()
   {}

   ~MyClass()
   {}

   void OtherFunction( type g)
   {}

private:

   t_object myObject;
};

About runtime... the binding message function are done runtime with the static instance of the t_class. so the method class_addmethod just register a value and a function pointer to be called when the value it met by an inlet?

About the sizeof, in you case (maxcpp5) since, you design it like a whole «family» the sizeof will return teh size of the whole family... In my case I am decupling so the t_class is not part of the hierarchie of my object and I am thinking of moving out also the inlet and outlet out of my hierarchie.

I guess the t_object really need to be there since it is the first memory address of my object (right)?

Quote:Because a pointer to a struct is the same value as a pointer to its first member.

About runtime... the binding message  function are done runtime with the static instance of the t_class. so the method class_addmethod just register a value and a function pointer to be called when the value it met by an inlet?

About the sizeof, in you case (maxcpp5) since, you design it like a whole «family» the sizeof will return teh size of the whole family... In my case I am decupling so the t_class is not part of the hierarchie of my object and I am thinking of moving out also the inlet and outlet out of my hierarchie. 

I guess the t_object really need to be there since it is the first memory address of my object (right)?


http://puredata.info/Members/thomas/flext/

). It's a library that allows you to write cross-platform externals in C++, which can be built for either Max of PureData. I should warn you, though, that it isn't really clean, orthodox C++. It uses a LOT of macros, which are used to provide much of the connection between the object orient code that you write, and the underlying Max system. It is still rather nice, just a bit unusual if you're coming from a purely object-oriented background.

As far as applying object-oriented programming to Max, it is important to understand how Max functions and where it came from. It was created before C++ really entered the mainstream. It was written entirely in C, and therefore used a lot of the techniques that are common to most C code. Despite this it is, in a sense, object-oriented, just in a different way than you are used to.

C++ compilers implement a very solid connection between object-oriented concepts, and the underlying assembly language which makes up your program (or external). It handles things like VTables (

), which allow you to have methods associated with objects, which can be overridden in sub-classes. It also provides a precise specification of the interface to an object (i.e. its methods and fields).

Max implements much of this same type of functionality, but does so at run-time rather than compile-time. In max, objects (generally externals) define an interface (a set of messages, which are basically like methods in a class), and the Max system and other objects interact with this interface. While C++ generates method tables while compiling your code, and then uses those tables to handle map calls from other objects to them, Max uses message maps, generated at run-time and stored in memory, to accomplish effectively the same thing. The t_object header that needs to be at the base of every external (or t_pxobject, etc) stores references to these maps. The setup() function that you call in the main() function of your external builds these tables, and the class_new() function uses them to construct the t_object header.

So, applying the concepts of object orientation to Max is absolutely a good fit. If you think about it, Max patches are an object-oriented programming language.

However, applying the strict and orthodox attitude of an experienced C++ programmer to writing Max externals can be problematic. First, it tends to lead to a lot of unneccessary bloat. C++, by definition is a layer of extra stuff that gets put into a program. It often allows programs to be designed in a more logical manner, but it does add a fair bit of code in order to accomplish that. Since Max has been a non-C++ creation from the start (though Max5 may have used some C++, I don't really know...), it is often best to have a C-oriented mindset when writing for it. Interactions with Max are usually best handled on Max's terms, meaning it's version of object-orientation.

My solution to this (since I have a heavily object-oriented background), has generally been of one two approaches:

1. If the external is simple enough, suck it up and write it in C (or mostly C).

2. If it's really beyond what I'm comfortable doing in C, I write a C++ class, with methods for all the messages that it needs, and then I write standard C code that wraps around it.

Encapsulation and polymorphism are excellent things, when designing large systems and libraries (intended for other people to use). However, Max externals are rarely complicated enough to make it worthwhile.

You should check out Flext (http://puredata.info/Members/thomas/flext/). It's a library that allows you to write cross-platform externals in C++, which can be built for either Max of PureData. I should warn you, though, that it isn't really clean, orthodox C++. It uses a LOT of macros, which are used to provide much of the connection between the object orient code that you write, and the underlying Max system. It is still rather nice, just a bit unusual if you're coming from a purely object-oriented background.

C++ compilers implement a very solid connection between object-oriented concepts, and the underlying assembly language which makes up your program (or external). It handles things like VTables (http://en.wikipedia.org/wiki/Vtable), which allow you to have methods associated with objects, which can be overridden in sub-classes. It also provides a precise specification of the interface to an object (i.e. its methods and fields).

So, applying the concepts of object orientation to Max is absolutely a good fit. If you think about it, Max patches are an object-oriented programming language.
However, applying the strict and orthodox attitude of an experienced C++ programmer to writing Max externals can be problematic. First, it tends to lead to a lot of unneccessary bloat. C++, by definition is a layer of extra stuff that gets put into a program. It often allows programs to be designed in a more logical manner, but it does add a fair bit of code in order to accomplish that. Since Max has been a non-C++ creation from the start (though Max5 may have used some C++, I don't really know...), it is often best to have a C-oriented mindset when writing for it. Interactions with Max are usually best handled on Max's terms, meaning it's version of object-orientation.

My solution to this (since I have a heavily object-oriented background), has generally been of one two approaches:
1. If the external is simple enough, suck it up and write it in C (or mostly C).
2. If it's really beyond what I'm comfortable doing in C, I write a C++ class, with methods for all the messages that it needs, and then I write standard C code that wraps around it.

Encapsulation and polymorphism are excellent things, when designing large systems and libraries (intended for other people to use). However, Max externals are rarely complicated enough to make it worthwhile.


Wow what an answer I really appreciate...

You part of wht I say, is not about complaining (even tough you didn't imply it). Just to clarify.. I basicly finished graduate studies in video game programming and I wanted to get, for my self more max external done. And I wanted to apply what I learn...

I knew a bit about coding external for max and I felt, and you all comfirm what I sensed that it is object oriented, from the graphical environment ( the patch) to its api... What I find a bit odd ( and i wish I could since it is still OO) is that I don't feel (maybe it is possible, but not sure) it is possible to write a external, in c++ the orthodox way, because you have to break encapsulation for max to interact with it. The t_object struct... Well this is how it is so fine! there is other tools useful in c++ like heritage and on and on. So I'll deal with it.

Now I want to share some though with you... And it is just something I am think about and trying to figure out.

It was created before C++ really entered the mainstream.

How can max5 be the Max for the next 20 years without a c++ api? Soon C++0x is coming, some IDE are already suporting some feature... Before my graduate studies, I was studying engineering... and I was thaugh c++ not C. Real-time entertainment application aka video game are in c++ now... Really I thiink about this and I really feel that it will have to update it self to the fasion of the 21 century to survive at one point... no? what do you think?

All this work I am going through, I do it for fun and to have a kind of generic template (not c++ template), so that when I start a new project/a new external I just have to wonder about the actual external and not about the max stuff... Also to write less code, I guess I am a lazy programmer... hurray for template! That's why a abstraction layer was interesting to me...

Once again really thanks for that answer , I found it really relevent

I knew a bit about coding external for max and I felt, and you all comfirm what I sensed that it is object oriented, from the graphical environment ( the patch) to its api... What I find a bit odd ( and i wish I could since it is still OO) is that I don't feel (maybe it is possible, but not sure) it is possible to write a external, in c++ the orthodox way, because you have to break encapsulation for max to interact with it. The t_object struct... Well this is how it is so fine!  there is other tools useful in c++ like heritage and on and on. So I'll deal with it.

Quote:
 It was created before C++ really entered the mainstream.

All this work I am going through, I do it for fun and to have a kind of generic template (not c++ template), so that when I start a new project/a new external I just have to wonder about the actual external and not about the max stuff... Also to write less code, I guess I am a lazy programmer... hurray for template!  That's why a abstraction layer was interesting to me...

Given that Max has a pretty effective object system which is better suited to dynamic environments by being run-time rather than compile-time defined, the advantage of C++ is meager. Interfacing max objects with existing C++ code isn't difficult, and even easier using C++ bindings that already exist (Flext, my templates, etc). And to refactor Max itself into C++ would not only be an enormous amount of work of dubious benefit, it would cascade down to every third party developer.

Making it easier to write code for Max, e.g. some abstraction layer, is definitely worthwhile, I'm just not convinced that C++ is the future... 

Given that Max has a pretty effective object system which is better suited to dynamic environments by being run-time rather than compile-time defined, the advantage of C++ is meager. Interfacing max objects with existing C++ code isn't difficult, and even easier using C++ bindings that already exist (Flext, my templates, etc). And to refactor Max itself into C++ would not only be an enormous amount of work of dubious benefit, it would cascade down to every third party developer. 

Making it easier to write code for Max, e.g. some abstraction layer, is definitely worthwhile, I'm just not convinced that C++ is the future... 


Of course, as long as it is not broke there is no real reason to modify it, plus this kind of change, by experience, I know is really risky and alot of fun work . You mentin a good point here..

Given that Max has a pretty effective object system

It is really effective and eficient! and you people at C74 are really making a good job for sure.

It would be a little disgretion of the subject, but I am curious, why do you say c++ is not the future. I don't previledge one language over the other. We all heard that before, but they all have their advantages and weakness... in your opinion what wold be the future?

About Flext, I went and look into th source code.. Ho my god, there is alot of work in that.... and a LOT[/supersize] of macro. Interesting...

If I may, I have been on this problem for some days.. I simplify and simplified again my desing to find the problem but I can't find it. I attached my source code... What happens is the RegisterMaxClass is called. This static function contain the class_new method but the «create» function is never called... so I get in the max patcher a box with my external name but no inlet or outlet. I have put some post message in different function to follow the creation process. this is what I get. When I open it in the max patcher.

Of course, as long as it is not broke there is no real reason to modify it, plus this kind of change, by experience, I know is really risky and alot of fun work . You mentin a good point here..Quote:Given that Max has a pretty effective object system

I'm assuming the problem is in RegisterMaxClass(). If Max is calling this more than once, then it probably means that the class registration failed in some way. It seems like your Allocate() function is never called. This could be because class registration fails, or it could be because the Allocate function failed to register.

I suspect it is here, but honestly I'm not sure:

(VoidFctPtr_t)& Cleanup, sizeof(T)+sizeof(MaxClass),

This puzzled me. The size you should be passing is the size of the struct (or class) which holds instance data for a max object in a patcher. That is, the amount of memory Max must allocate for a given max object. That seems to be what T is, given that T derives from MaxObject which has the t_object as first member. So, just sizeof(T), I think.

I don't think this is why it is failing though. Maybe something in the casting isn't working.

MaxMspJitter::class_register(MaxMspJitter::CLASS_BOX, maxclass_); 

And I couldn't see anything immediately in your code that would otherwise be a problem. Not that that means much...

Why not try doing it the C way, and then incrementally shift to C++ as needed? Then you'll know exactly where it fails. Maybe obj_ shouldn't be a private member of MaxObject?

Oh, also, maybe you need add this to main.cpp:

ETC_Libs::MaxClass::MaxClass_t* ETC_Libs::MaxClass::maxclass_ = 0;

It could be that the static was not properly allocated, since it is only declared in a header. Just a thought.

maxclass_ = MaxMspJitter::class_new(
const_cast(name.c_str()),                   
(VoidFctPtr_t)& Allocate,                    
(VoidFctPtr_t)& Cleanup,                   sizeof(T)+sizeof(MaxClass),

I don't think this is why it is failing though. Maybe something in the casting isn't working. 

0L,
MaxMspJitter::A_GIMME,
0);    
MaxMspJitter::class_register(MaxMspJitter::CLASS_BOX, maxclass_); 
return maxclass_;

Why not try doing it the C way, and then incrementally shift to C++ as needed? Then you'll know exactly where it fails. Maybe obj_ shouldn't be a private member of MaxObject? 

It could be that the static was not properly allocated, since it is only declared in a header. Just a thought.


I took a look through the code, and I noticed two potential issues.

The first problem has to do with the nature of the Allocate and Cleanup functions. Since it appears that neither of them are being called, it's possible that there is an issue with their signature and/or linkage. I can't recall all the gritty details of how static class methods are linked and compiled in C++, but it's possible that they aren't set up in the manner that Max is expecting them. A possible solution to this would be to have those two be declared/implented outside the context of a class, with extern "C" linkage. It would violate the encapsulation of that class, but it may solve the problem.

The second problem (as mentioned by grahamwakefield) has to do with the size of the max object's data, which you are passing into class_new. C++ objects have additional space in them, which accounts for things like VTABLES. I don't know the details of how the sizeof operator handles this, but it may be causing a problem. If the VTABLE is being placed at the beginning of the data, then this will almost certainly cause a problem. Traditional max objects are structs, with a t_object (or t_pxobject, etc) that 

 be at the front. When this is the case, a pointer to the struct is a pointer to the beginning of the struct's data block. Since the t_object is at the begining, a pointer to that struct is also a pointer to the t_object. Max uses this header to store information about the object's class, messages, and so on. If additional data is being stored before you t_object, this will cause nasty problems.

My solution to this (and first problem) has generally been to put the bulk of the code/data in a nicely designed and encapsulated C++ class, but have the actual "max object" of the external be a standard C-style max object (struct), which contains a pointer to an object of that class. Then you have standard C-style functions, which handle messages by passing the control over to methods of that object. That way, the part that max deals with directly is exactly what it expects, but the main body of it is a class. As I recall, this is the approach that the Flext library takes. You define a class, and use the somewhat nasty Flext macros to define a wrapper struct (though it has been a while since I've dealt with Flext).

The second problem (as mentioned by grahamwakefield) has to do with the size of the max object's data, which you are passing into class_new. C++ objects have additional space in them, which accounts for things like VTABLES. I don't know the details of how the sizeof operator handles this, but it may be causing a problem. If the VTABLE is being placed at the beginning of the data, then this will almost certainly cause a problem. Traditional max objects are structs, with a t_object (or t_pxobject, etc) that must be at the front. When this is the case, a pointer to the struct is a pointer to the beginning of the struct's data block. Since the t_object is at the begining, a pointer to that struct is also a pointer to the t_object. Max uses this header to store information about the object's class, messages, and so on. If additional data is being stored before you t_object, this will cause nasty problems.

My solution to this (and first problem) has generally been to put the bulk of the code/data in a nicely designed and encapsulated C++ class, but have the actual "max object" of the external be a standard C-style max object (struct), which contains a pointer to an object of that class. Then you have standard C-style functions, which handle messages by passing the control over to methods of that object. That way, the part that max deals with directly is exactly what it expects, but the main body of it is a class. As I recall, this is the approach that the Flext library takes. You define a class, and use the somewhat nasty Flext macros to define a wrapper struct (though it has been a while since I've dealt with Flext).


I think the linkage of the Allocate & Cleanup is ok, it works in my (admittedly simpler) templates. Don't suppose that the const on the t_atom pointer makes much difference. But it's worth a try.

The issue about the t_object at the start of the struct I think is the most likely source of problems. Trouble is, it's very hard to know what a C++ compiler is going to do with memory layout, without descending to C techniques anyway.

E.g. I also use template class for the max object, and it works, but it may be because the class does not inherit any virtuals, so it does not need a vtable. It actually inherits from the type it is templated from (curiously recurring template pattern).

His MaxClass doesn't have any inheritance or virtuals either, but his T (PimplMax) does inherit from MaxClass (which has no members of its own, nor virtuals). I don't think that should force the creation of a vtable, but who knows.

Honestly, I think the conclusion is that Max isn't going to be so easily encapsulated into a C++ inheritance hierarchy; and I don't think it is really appropriate or necessary either. 

His MaxClass doesn't have any inheritance or virtuals either, but his T (PimplMax) does inherit from MaxClass (which has no members of its own, nor virtuals). I don't think that should force the creation of a vtable, but who knows. 

Honestly, I think the conclusion is that Max isn't going to be so easily encapsulated into a C++ inheritance hierarchy; and I don't think it is really appropriate or necessary either. 


first thanks for all those insight... So I checked what you said and it didn't solve my problem.

First what Graham suggested, I changed the sizeof to sizeof(T). I look at what the class_register() return and unfortunatly it return 0. So there is no error in the registration.

As for what thezer0ist suggested, Graham has done something really similar with his function static in his class. From what I know a static function is like a global function... In my object i don't have any virtual function so the compiler shouldn't create a vtable, he wouldn't use it. Of course as far as I know About the t_object.. i tried several thing. public:, private, the first attribute, the first in the class declaration and still no luck. I even tried to put it before the typedef and take out the namespace...

I think that even if if the class prototype are first, I think that the compiler should still put the first class member in front, but on that I don't have any proof...

So I went and try to see what the class_new return. I found something that i think is strange but it may not be... each time the memory address is 0xfeedface ( a magic number how magic I don't know) When I inspect after the class_register in the debugger the content of the t_class object there is nothing in it. But After my function RegisterMaxClass in the main I have put this line of code:

and surprise surprise in the console I can see the name of my external. this kind of hint like on variable in the RegisterMaxClass is not in the right «scope» example: passing an instance member when it should be a class memebr or something like that. ( not sur if I am clear here)

Since what I have now is really really close the what Graham did with his template, it should work... I hope I'll understnd why it doesn't work, or I fear I'll be haunted by it in my dreams..

thanks again I am attaching again the code...

As for what thezer0ist suggested, Graham has done something really similar with his function static in his class. From what I know a static function is like a global function... In my object i don't have any virtual function so the compiler shouldn't create a vtable, he wouldn't use it. Of course as far as I know  About the t_object.. i tried several thing. public:, private, the first attribute, the first in the class declaration and still no luck. I even tried to put it before the typedef and take out the namespace...
 I think that even if if the class prototype are first, I think that the compiler should still put the first class member in front, but on that I don't have any proof...

So I went and try to see what the class_new return. I found something that i think is strange but it may not be... each time the memory address is 0xfeedface ( a magic number how magic I don't know) When I inspect after the class_register in the debugger the content of the t_class object there is nothing in it. But After my function RegisterMaxClass in the main I have put this line of code: 

Since what I have now is really really close the what Graham did with his template, it should work... I hope I'll understnd why it doesn't work, or I fear I'll be haunted by it in my dreams.. 

ho and did I thank you all?  thanks alot


Since I had no luck, I decided to start over....

And I realize that the error might come from copying the simplemax example. Once copied, what do I have to change beside de name of xcodeproj?

Copy the simplemax folder to my development folder. I deleted the vcproj and .def file. I put the simplemax.c in a sub folder called src and renamed it. I then renamed the codeproj and simplemax.maxhelp file. I opened the xcode project to change the ref to the simplemax.c file. I then build the project and moved the mxo to the max folder ( it had the right named of my project) I then opened the maxhelp file. It can'it find the simplemax object, ofcourse so I changed it to the named of my mxo. When I click out of the box it can't load the object and give me this in the max window

Since I had no luck, I decided to start over....
And I realize that the error might come from copying the simplemax example. Once copied, what do I have to change beside de name of xcodeproj?

I am the simplemax object
I am the simplemax object
I am the simplemax object

I didn't touch one line of code...
what is going on here?? Any suggestion?

Ok I think I found the source of all the problems at least most!!!

If you want to hear about a really easy mistake... read on! We were all talking about memory layout!! You don't know how far we were!

Ok, why max wasn't calling my new and fre methode and why just renaming the project wasn't working is because the char* that I was passing to the class_new, wasn't the same as the name as the mxo!!!! This is something that I didn't know and I am not sure if it is documented somewhere. Also I think it is not case dependent? Can some one confirm this?

thanks again! for everything I learn a lot from you and my mistakes!

Object creation question