Yeah, this sounds like it's basically the same thing. Jason, the example
you gave won't work for the following reason. When gem5 auto generates the
header which defines the create() function, it doesn't include the header
which defines the return type of create. I'm not 100% sure why, but likely
because it would create an include loop in some cases. It instead tries to
declare the class using the namespaces and class name that have been
specified. So your example MySimObject would be declared as
class MySimObject<float>;
which is wrong because MySimObject is a template, not a regular class. It
should be
template <type T>
class MySimObject;
and then returned as a MySimObject<float> *
This gets more complicated when the type your using as a template parameter
also needs to be declared. For instance if you wanted to return
MySimObject<OtherType> where OtherType was a class.
class OtherType;
template <type T>
class MySimObject;
MySimObject<OtherType> *MySimObjectOtherTypeParams::create();
This gets even more complicated if, for instance, there are typedefs
involved. You can't blindly declare something as a class if it's actually a
typedef, because g++ (rightly) doesn't think those are the same and will
complain.
The situation I'm dealing with/dealt with is that there's a systemc class
which is templated on an integer width value. I want to wrap that in a
SimObject so that it can be used in a python config script. This all works
just fine for "normal" systemc sc_object classes, but because it's a
template (the systemc part is incidental in this case) it runs into this
problem. I got around this by subclassing it to be a "normal" class, and
then just assuming that there won't be any cases where it matters that it's
not actually the template class directly.
class Normal : public Template<64>
{
public:
using Template<64>::Template;
};
This works well enough since I'm not planning to have to deal with this
templated class in the long term, at least as far as I can tell right now,
and as I imagine you can see from these examples this is quite a rabbit
hole which can get really complicated if you try to handle all the
different situations that come up.
Gabe
On Fri, Feb 22, 2019 at 12:24 AM Daniel Carvalho <[email protected]>
wrote:
> Hi all,
> I am not sure the MySimObject will be allowed by the Python code. If I
> recall correctly, when I tried there was something about the Params being
> programmatically forward declared somewhere, and it didn't exist without
> the template arguments.
>
> Some time ago I have embedded templates to Python
> https://gem5-review.googlesource.com/c/public/gem5/+/11629. The usage is
> explained in the commit message, but this is a basic approach which does
> not cover all aspects of templates. It worked for what I wanted to do, but
> since it was not desired mainstream, I let it go.
>
> Regards,Daniel
>
> Em sexta-feira, 22 de fevereiro de 2019 03:05:39 GMT+1, Jason
> Lowe-Power <[email protected]> escreveu:
>
> Hey Gabe,
>
> Could you describe in a little more detail why you want to templatize a
> SimObject. Since python doesn't have support for templates, I don't really
> like the idea of supporting this.
>
> One option is to have the Python side of the SimObject be the
> "specialization" and then you'd just have to implement the
> SimObjectParams::create() function to return the specialized template for
> each of the types you want to support from Python. Does that make sense?
> Maybe this is what you meant by "subclassing"
>
> For instance:
>
> *my_simobject.hh:*
> template <type T>
> MySimObject public SimObject
> {
> ...
> };
>
> *my_simobject.cc:*
> MySimObjectIntParams::create() {
> return MySimObject<int>(this);
> }
>
> MySimObjectFloatParams::create() {
> return MySimObject<float>(this);
> }
>
> *MySimObject.py:*
> class MySimObjectGeneric(SimObject): # I'm not sure if this is exactly
> right...
> ...
> <all of the params>
>
> class MySimObjectInt(MySimObjectGeneric):
> <header file, etc.>
>
>
> class MySimObjectFloat(MySimObjectGeneric):
> <header file, etc.>
>
>
> I would say that if the above doesn't work now, we should update things so
> it does work. However, I don't think we should do any of this
> *automatically* for templated SimObjects.
>
> Cheers,
> Jason
>
> On Fri, Feb 15, 2019 at 5:55 PM Gabe Black <[email protected]> wrote:
>
> > Hi folks. I'm trying to create a SimObject out of a templated class (the
> > python Param type uses a specialization of it), and the pybind11
> generated
> > code doesn't compile because the predeclaration of the class type isn't
> > syntactically correct since it's a template. I can work around this
> problem
> > by, for instance, subclassing it and then using that subclass (at least I
> > think I can, I haven't tried it yet), but it would be nice if the system
> > could handle it.
> >
> > It's not obvious how to fix it since it's not obvious from the fully
> > specified type how it should be prototyped, so it's not a quick fix. Has
> > anyone attempted to get this to work, and/or have a solution?
> >
> > Thanks!
> > Gabe
> > _______________________________________________
> > gem5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
