Jump to content
  • Advertisement

Prinsessa

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

121 Neutral

About Prinsessa

  • Rank
    Newbie

Personal Information

  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Prinsessa

    Lambda overload problem

    Well, there's no rush. I can ad-hoc it in the meantime. Good to know it's on the list at least. Thanks!
  2. Prinsessa

    Lambda overload problem

    Ran into a little problem now. I have a function that can be used to register a callback for an object by providing it with a function, and it's meant to be used using lambdas of course. However, the function has two signatures, each accepting slightly different lambda signatures. The lambda signatures are as follows (these are not their actual names, tho, which I'll be getting to in a bit):   void fMutable(Component @) void fConstant(const Component @)   This is because certain callbacks are restricted to constant components and others may modify them. My function to register callbacks has two overloads, one taking the mutable lambda signature and one taking the other. The lambda signatures have of course been registered as funcdefs as is necessary.   However, since lambdas won't actually allow me to specify the types of the arguments, this creates an ambiguity which I cannot manually resolve by explicitly specifying them:   Multiple matching signatures to 'Collider::event(const string, $func@const)' Collider@ Collider::event(const string&inout, karhuAS_Callback_Component_event@) Collider@ Collider::event(const string&inout, karhuAS_Callback_Component_eventConst@)   Here you can see the real names of the funcdefs. These have been generated by my engine when registering the function event() and for my own convenience I'm not supposed to know the exact names of funcdefs, so I can't manually specify the signature by, say, casting the lambda to either of these (if that's even possible).   Would it be possible to make it so that we can explicitly specify lambda parameter types if necessary for disambiguation, or is there some other way I can resolve this based on what I've said about my particular situation (i.e. not casting, and I'd rather not have to give the two functions different names either, because it would clash with the C++ interface and the general naming convention of my engine)?
  3. Prinsessa

    Template idea

    It's a member function in this case, unfortunately. Though I did actually play with the convoluted thought of doing something similar anyhow before dismissing the idea. :p
  4. Prinsessa

    Template idea

    Yeah, I remembered from looking around the docs the other day that there was something else besides asIObjectType but I couldn't remember what it was called. Ah! I did indeed look at the todo list like yesterday to see if it was on there and got pretty sad to see it absent. Cool that you've added it! I don't know how common the problem is, but my (component-based) C++ game engine uses templates a bunch to make things handy but since AS lacks templated functions I can't transfer the interface quite as elegantly to AS and have to resort to slightly bulkier solutions where I have to both tell the function (with a string) what type I want and then cast it anyway because I have to return the base class to AS. Stuff like that.   Good to hear that you think the idea possible to implement at least.
  5. Prinsessa

    Template idea

    I know full, real templates are hard to do for a lot of reasons (I've read the threads), but I had some sort of idea last night so I thought I'd present it and ask anyway.   Wouldn't it be plausible to emulate templates in such a way that you could register a templated function and then the C++ callback would receive the template types either as asIObjectType * or something that tells us what kind of primitive it is, and then we could do something with that?   Primitives aside for now, focusing on handles, it could look something like this in the AS:   ClassType @obj = getObjOf<ClassType>("by-this-name");   This function has been registered with the following AS signature: T @getObjOf<T>(const string &inout) In order to call this C++ function:   asIScriptObject *callbackGetObjOf(asIObjectType *templateArg, const std::string &functionArg) {     return findObjByNameAndType(templateArg, functionArg); }   Or perhaps if you're okay with doing some manual work if you have some C++ types registered (let's say ClassType is a registered C++ type): void *callbackGetObjOf(asIObjectType *templateArg, const std::string &functionArg) {     // return ...; } Or instead of void *, perhaps a CScriptHandle with a ref or whatever... This function would be able to return a class derived from ClassType or whatever since the return value would automatically be casted to whatever T specified in the AS code. This is obviously not necessarily safe since a bad cast could cause a crash, and so the responsibility of using this would lie with the programmer, but at least it would be possible to use templates to some extent unless my idea cannot possibly work in reality. Maybe by activating some compiler flag or AS engine rule in order to enable this unsafe feature.
  6. Prinsessa

    [SOLVED] Casting between const handles broken?

    Well, now I'm embarrassed. I tried exactly that, with a const handle returned, but I forgot to mark the method itself as const. And I'm an avid producer of const-correct code!   Sheesh. Thanks a lot! Works like a charm now.   But yeah, probably good to mention in the docs since that's different from when you used to do RegisterObjectBehaviour().
  7. Hello! I updated to the latest version of AS for my project (thank you soooo much for the lambdas — they made my day!). It's been some time. But almost everything still worked. One thing I needed to change was how base types and child types are casted between each other, because the syntax for registering that was changed a little. But the new example could be found at the same place in the doc as the old one, and the difference wasn't big, so it was done in a jiffy.   BUT.   Now I can't cast const handles. cast<Emitter @>(getSomeVarOfTypeComponent()) works fine, but cast<const Emitter @>(getSomeConstVarOfTypeComponent()) does not, giving me the following error:   No conversion from 'const Component@&' to 'const Emitter@' available.   The & sign is because the component is being returned from a function, and that's exactly how I'm retrieving the non-const one as well, and either way both worked before I updated AS.   I was thinking maybe now I need to register const conversion individually, but AS actually has an assert telling me I can't register more than one cast for the same type, const or not, and in the comment above the assert, there's a todo saying that maybe more should be allowed in the future to allow different behaviour for const conversion than for non-const conversion.   But surely that must mean that const conversion is automatically covered by the non-const cast I registered, and not that the latest version of AS suddenly cannot cast between const handles at all, like some sort of todo? That would be a step backwards from something that actually worked before and would break existing AS code.   So why is this happening? Could it actually be a bug? Both types, parent Component and child Emitter, are C++ classes that have been registered in AS as asOBJ_REF | asOBJ_NOCOUNT. I've registered Emitter @opCast() in the parent class and Component @opImplCast() in the child class, using a direct copy of the refCast() function from the docs (sans the ->addref() of course). I have changed absolutely nothing from before I updated, neither in AS code or C++ code, besides the registration of casting, and the AS code that performs this cast did, again, work before the update with the old registration of casting, and does still, again, work if the handles are not const.
  • 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!