[Mono-dev] [PATCH] Implement internal Encodingsusingunified code base

Kornél Pál kornelpal at gmail.com
Fri Mar 21 16:17:58 EDT 2008

>The calls is my proposal about to the generated code that performs the
>call, say 20 bytes for a method with 3 arguments. The additional virtual
>unsafe method itself would be 50 bytes just in additional metadata
>and virtual table costs. So the amounts are small, but they are
>definitely not a benefit of your design.

My conserns are much about source code duplication than about binary code 
duplication because I believe that duplicated source code will go out of 

>Everything your proposal does can be implemented with static methods
>instead of virtual unsafe methods. Static methods may not be the cool
>new thing of the day, but they are more efficient and allow us to
>immediately check where potentialy ostile data is manipulated.

Actually I think that the source code looks more pretty with single line 
implementations in encoding classes this is why I don't see using static 
methods being cool.

public override byte [] GetBytes (string s)
  return GetBytesInternal (s);

In contrast to:

public override byte [] GetBytes (char[] chars)
  ValidateArguments (s);

  if (chars.Length == 0)
    return new byte [0];

  fixed (char* charPtr = chars) {
    int byteCount = GetByteCountImpl (charPtr, chars.Length);

    byte [] bytes = new byte [byteCount];
    if (byteCount == 0)
      return bytes;

    fixed (byte* bytePtr = bytes)
      GetBytesImpl (charPtr, chars.Length, bytePtr, byteCount);

    return bytes;

With static methods the above source code has to be duplicated while it can 
be moved to Encoding.cs when using virtual methods.

>So the only high-level difference is that my version avoids doing
>unnecessary virtual calls and that potentially the code can be inline
>exactly where it is used without hard to follow flows (important both
>for performance and for security checks).

This is why I tend to be convinced of the benefits of using static methods.


More information about the Mono-devel-list mailing list