Introduction

This page captures all ideas and feedback for future directions for C++Script and dynamic typing in C++. Please add any comments and suggestions below, or use the issues page.

The short term goal of this project is to iron out all of issues, and prepare this project for version 1.0.

In the long term, I would like to see dynamic typing as just another aspect of C++, to be used where appropriate. I'd like to make C++ easier to use, by wrapping C and C++ libraries which are difficult to use with dynamic types.

Version 0.9.4

• Sort out list notation a bit better. Remove the C-array style lists from the manual. Decide on a list notation, be it a comma operator, variadic functions, both or stick with () operator.

Before version 1.0

• Profile and optimize the code. Currently there are too many copy constructors, so a change in interface (i.e. return value optimization) is necessary on var_impl. (Assigned to: Calum)
• Support compiler flags and additional libraries on the cppscript program. This should probably work as follows: any flags passed to cppscript before any source files should be passed straight to the compiler.
• Regexes. It's okay to use boost::regex, or a platform regex lib. The tricky part is managing the build environment on different platforms, and making regexes optional. It could be a separate library. Think about whether a Boost dependency is inevitable (answer: yes).
• Python interface. Wrap PyObject by a var (using method 4 above). Provide a full bidirectional interface where vars can call into Python, and Python can invoke methods on var. The tricky part is integrating with Python's garbage collector, thinking about thread safety, and managing multiple interpreters. The Python interface is probably a separately downloadable library. Compare and contrast with boost::python. (Assigned to: Calum)
• Get a logo and put a nice font on the website.
• Add more benchmarks to the bench project, for example from the computer language shootout. Currently C++Script is not particularly competitive (and it should be!) Perhaps split up the bench project into separate source files. Once a good spread of benchmarks have been written, and the performance is where we want it to be, submit C++Script to the shootout page. The thing with benchmarks is that you can always use native C++ for performance-critical code, so a poor benchmark score isn't a disaster.
• Tidy up the manual, by splitting it up and adding a style sheet.

• Implement a compiler front-end ("cppscript.exe") for Windows, e.g. using MinGW or Cl.exe
• Implement a module system.
• Larger examples.

Beyond version 1.0

• Visual Studio plugin to create new C++Script projects. vars can be explored at run-time within the Visual Studio IDE. An integrated installer to make this easy to use.
• Implement a "pair()" function maybe.
• Grammar and Interpreter. (Assigned to Christopher Diggins)
• Tuples. These are just a performance improvement, since array() provides this already. Probably want 11 functions: var tuple(), var tuple(const var&), var tuple(const var&, const var&) etc.
• Multiple dispatch. Create a functor which implements += to add new recipients, and dispatches function calls to all recipients.
• \todo items in the code. These do not necessarily need to be fixed, but need thinking about.
• MySQL interface.
• Object-relational mapper.
• GUI. I was thinking of wrapping Gtk, since Gtk uses the GObject library, which is effectively a dynamic object library for C. The difference is that GObject is damned awkward to use, but GObject can be wrapped in a var to make GObject and Gtk really simple to use.
• Think about unique opportunities offered by dynamic typing. For example an object-relational mapper is quite hard to implement in C++ because of its inflexible type system. Look around at other languages and libraries and see what they can do easily, which C++ cannot do. I see it as more important to provide new functionality that exploits dynamic typing, than just rewrite existing functionality for the sake of it.
• synchronised() objects.
• Networking. Client-server.
• Remoting. C++Script has pickling, so piping objects over a socket could allow for some interesting distributed computing applications.
• XML, DOM.
• Unicode support.
• Web 2.0. There's a nice project called Wt. Support HTTP servers via CGI or FastCGI, an Apache module or just implement an HTTP server (probably a bad idea). Or, just contact the author of Wt and suggest that they use C++Script.
• Application frameworks. I really want to get to the idea of abstracting away the GUI, for example like the model-view-controller pattern.
• COM wrapper. Initially just an IDispatch interface, to provide bi-directional support between COM and C++Script.
• .net interface. Currently this is supported by using Managed C++. Is tighter integration possible or desirable?
• Refining the garbage collector. The current implementation is a basic mark-sweep running per apartment. This is the most efficient, but might it be necessary to implement an incremental garbage collector. There is a snag with per-thread garbage collection, which is that loops cross-thread are not garbage collected. This can be resolved by (a) telling the programmer to be careful, (b) provide a strict message-passing interface with no cross-thread data access at all, or (c) using a global garbage collector. I have an idea about how to use incremental techniques to perform cross-thread garbage collection without changing the threading model.
• Pluggable garbage collector. C++Script uses its own garbage collector, but having multiple garbage collectors in a single program is frankly evil and wrong. So we'd want to be able to configure different garbage collectors such as Boehm's, the .net garbage collector, and possibly Python's. There's enough abstraction in the garbage_collector interface to allow this fairly simply.
• Named functors for better stack traces. Solve the problem of stack tracing better in general. E.g. is it possible to read debug information and walk the stack on various platforms like gcc and msvc? Can we use penter() and pexit() for anything?