• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

4685 Excellent


About WitchLord

  • Rank
    Moderator - AngelCode

Personal Information

  1. Unfortunately not. What you're asking for would require customization to the library. Out of the two options you provided, the first one looks better. I will not have the time to be working on adding this support myself at this moment due to other priorities, but if you should decide to make the customization on your own I'd gladly take a look at the changes to see if it is something I can incorporate into the library.
  2. Subtypes not always resolved in generic call

    I've changed the code in revision 2476 to always generate unique functions for template methods to show the correct object type for template instances. (I haven't implemented the memory optimization yet though, so if anyone sees an increase in memory consumption this is the reason)
  3. Template specializations for value types

    Value types currently do not support asOBJ_GC. However it is something I have plans to implement, to allow garbage collected objects to forward callbacks to members of value types if those are some kind of containers, e.g. like the CScriptHandle add-on.
  4. Read message from std::exception into script exception

    Indeed. It appears that this would work just fine without relying on C++11. This feature is definitely something that I'll add to the library as soon as possible.
  5. Remote visual debugger: asdbg

    It's shaping up nicely. Well done.
  6. Read message from std::exception into script exception

    Thanks for sharing the code. I'll certainly take advantage of this. However, before I merge it into the library I'll take some time to study the portability of this code. I'll probably have to use the AS_CAN_USE_CPP11 flag to turn something like this off when AngelScript is used with older compilers that are not C++11 compliant. Besides, as this changes the interface of the library, I'll only be able to include it in release 2.33.0 (though that doesn't necessarily mean that the next release won't be 2.33.0 )
  7. Subtypes not always resolved in generic call

    I'll probably combine this with another memory optimization that I had already planned to implement, where the function signature is shared between asCScriptFunctions. This should compensate the overhead needed to create a unique asCScriptFunction for each template instance just to inform the correct object type.
  8. Read message from std::exception into script exception

    I won't be implementing a catch for specific exception types in the core library. Today you're asking for std::exception, tomorrow someone else will ask for another, and so. I will however consider allowing applications to do this through a callback. perhaps using what Solokiller suggested, which looks quite nice, or else allow the application to provide a custom exception handling code that would be injected into the angelscript code at compile time with an #include statement.
  9. Subtypes not always resolved in generic call

    I'll look into this. This looks to be something that I hadn't thought of when I decided not to generate unique instances of all template class members when no template subtype is involved. I thought I was being smart to avoid the extra memory consumption, but it looks like I was just being dumb.

    When defining AS_MAX_PORTABILITY it is precisely the support for native calling conventions that is turned off. When using AS_MAX_PORTABILITY you have to use the generic calling convention (use the autowrapper add-on to avoid having to write all the wrappers manually). On platforms for which there is currently no support for native calling conventions (like Emscripten and arm64) the AS_MAX_PORTABILITY should be defined automatically (through as_config.h) so you do not need to do it manually.
  11. Bitwise Operator

    Only float and double are explicitly restricted here, because these types have an implicit conversion to integer but I do not want to allow them here. Object types that implement implicit conversion to integer are still allowed.
  12. In the previous implementation the script engine would keep it's own copy of the string data, and would only request an instance to the string factory at runtime. In this implementation the script engine will not keep its own copy, and will request the instance to the string factory at compile time. With this there are 2 immediate benefits with the new version: 1. less memory consumption. Even if the application was just referring to the engine's memory buffer, there is still the advantage that the engine no longer has to keep a data structure for keeping track of the strings. 2. runtime performance is improved, since the string instance doesn't have to be created/looked up at runtime, the compiled script code already holds the final pointer to the string and can use it directly. There is also a third benefit with the new implementation. There is no longer a limit to how many different string constants that can be used in the scripts. In the previous implementation there was a limit of 32K string constants. I'll update the documentation to clarify that the 'data' is no longer static and the string factory must make a copy of the content.
  13. Multiple engines can use the same string factory cache without problems. The string factory keeps track of how many references to each string constant are currently in use and will only destroy the string constant once the last reference is released. Note, the code is currently not thread-safe though. So if you're using multithreading with different script engines in different threads, then you'll need to add the appropriate mechanics to make the string factory cache threadsafe. Regards, Andreas
  14. Bitwise Operator

    I've implemented this now. I decided not to add any engine property though. Perhaps if someone has a need for it I'll add it, but for now the compiler will always give an error when attempting bitwise operations with float or double.
  • Advertisement