Inherent code performance advantages of D over C?

Xavier Bigand flamaros.xavier at gmail.com
Tue Dec 10 11:36:54 PST 2013


Le 10/12/2013 03:54, Manu a écrit :
> On 10 December 2013 11:42, deadalnix <deadalnix at gmail.com
> <mailto:deadalnix at gmail.com>> wrote:
>
>     On Sunday, 8 December 2013 at 05:37:09 UTC, H. S. Teoh wrote:
>
>         Or maybe this is just another one of those cultural old age
>         indicators?
>         Has the term "refactoring" shifted to mean "variable renaming"
>         among the
>         younger coders these days? Genuine question. I'm baffled that
>         these two
>         things could even remotely be considered similar things.
>
>
>     Refactoring is changing your code, without changing what it does. It
>     is done in order to make your code easier to understand, more
>     maintainable, more testable, or whatever.
>
>     Both extracting some code into a function and renaming a variable
>     are refactoring operations.
>
>
> With effective semantic analysis, there are many useful refactoring
> tools that become possible.
> Renaming things is the simplest and probably most common, so it's
> usually a good starting point.
>
> Other possibilities for instance:
>   * Not just renaming functions, but changing it's signature in general.
> If types are changed, then some handling likely needs to be performed
> (or at least alerted) at call sites
>   * Renaming modules (required when moving source files within the
> source tree); update imports, etc.
>   * Reordering function parameters automatically reorders terms supplied
> to calls of the function (how many times have you wanted to reverse 2
> function parameters, and they've both been int? impossible to update all
> references without error)
>   * Assignments to delegates may automatically produce an appropriate
> function stub, along with typical function name
> 'On[event-name-being-assigned-to]() { }' or whatever is conventional,
> and proper parameters
>   * Hilight some text, 'refactor into own function' can move a block of
> selected code into a separate function, and correctly update the call
> site with the appropriate call, automatically adding function parameters
> for previously referenced local variables (seriously, how many times
> have you done this, and then carefully had to chase up the locals that
> are referenced to build the parameter list?)
>   * In addition to the prior point, scan for additional instances of the
> code you just refactored, and offer to also replace with calls to the
> new function (again, properly hooking up arguments)
>   * Auto-magic @property/accessor generation from member variables
>   * Auto-magically produce stubs for methods declared in interfaces
>   * And many more possibilities...
>   * Produce tools to statically encorce project coding standards; ie,
> produce red underlines beneath terms in the editor that don't conform to
> project standards
   * Add/Remove import automatically
   * Underline in red errors without compiling


More information about the Digitalmars-d mailing list