Hi Andreas. That's the interface that you would use for it, but
unfortunately it has the problems I described in my previous email. The
namespaces are handled now by stripping them off and putting them around
the class declaration, ie cxx_class Foo::Bar would be declared as:
namespace Foo
{
class Bar;
} // namespace Foo
Doing that same sort of decomposition and adding in all the other potential
declarations and syntactical window dressing that makes it work for
templates gets to be a lot more complicated though, so that strategy might
not work here.
Gabe
On Mon, Feb 25, 2019 at 6:46 AM Andreas Sandberg <[email protected]>
wrote:
> I haven't tried this, but I think you might be able to solve this using
> the cxx_class attribute. If I understand correctly, you are basically
> just trying to describe the Python side of a templatized SimObject. We
> have similar issues when exporting a SimObject that lives in a custom
> namespace (e.g., the ArmPMU). The cxx_class attribute was created to
> handle that corner case. Can't you use that for templates as well?
>
> Cheers,
> Andreas
>
> On 23/02/2019 00:42, Gabe Black wrote:
> > 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
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
