Re: which IDE ?

[Florian Weimer <fw@...>]

* Rob Kendrick:

>> That's true for C and C++ as well.  To some extent, all those code
>> completions are based on heuristics.  I'm not even sure if exact code
>> completion based on all statically available information would be
>> useful for C++.
>
> It's tricky to think of a way of hiding an identifier's true type and
> purpose in such a way that what can be done with it (ie, methods, or
> what it is valid to pass it to) cannot be inferred before compile time
> with either language (after all, the compilers produce errors for
> misuses here).

Dependent types in C++ templates cannot be completed statically
because the template is a meta-program run by the compiler, to create
the actual program.  The actual values of type arguments are not known
when you write the template, and without concepts, C++ does not
provide many constraints.

With the next C++ version, it seems likely that more templated code
will be written by users (and not just library authors).  It's going
to be an interesting challenge for IDE creators.

> At least not in any common idiomatic syntax or use.
> Which is my point here; many idiomatic approaches in Lua can't be
> understood like this.

Boost has got quite a bit of heavy metaprogramming stuff.

> But how does one do this even remotely effectively when it's impossible
> to know what the contents of the globals table will be at runtime?

Why can we understand code examples posted to the mailing list and
give helpful advice?

You don't have to address the problem in full generality.  Partial
solutions would be useful.

>> One way to get better data is to have a live VM running the
>> application around, and use data from that to support code navigation
>> and completions.  Now I don't like large, long-living VMs (which may
>> even run multiple applications) that much, but using this approach,
>> you can create very rich development environments.  Using Emacs for
>> Emacs Lisp development is fun, and even if you don't like the language
>> itself, it shows what is possible even with dynamic languages.
>
> This is one solution, yes, but the applications it can be applied to
> are especially niche.

As I said, I don't like this model, but I don't think it really
restricts the application domain (you may need simulators in some
cases, but that's basically a requirement for automated testing
anyway).