C#: Nested struct unmarshalling problem

[kwaclaw]

I am passing a class by value, which has as a member a struct.
On the other end, the struct arrives initialized to its default values, losing its member values. The method call works OK when I redefine the struct as a class, without changing anything else.

These are the Slice definitions (the struct in question is 'Date'):

module IServices2ICE {
  . . .

  struct Date {
    byte Day;
    byte Month;
    short Year;
  };

  ["clr:property"]
  class PubDate {
    string Id;
    string PubKey;
    string ComboKey;
    ::IServices2ICE::Date Date;
    bool Cancelled;
    bool Produced;
  };

  sequence<PubDate> PubDateSeq;
  . . .
}

The class is actually passed in the form of a sequence (PubDateSeq).
The Date member always arrives with its members set to 0.

I can't see what I am doing wrong, so there is a chance of a bug.
I hope though that this is my fault, as it would be a serious issue.

The Ice version is 3.2.1.

Karl

[michi]

Thanks for the bug report! I'll have a look at what's wrong there.

Cheers,

Michi.

[michi]

I've posted a patch for this. Thanks for reporting the problem!

Cheers,

Michi.

[kwaclaw]

I've posted a patch for this. Thanks for reporting the problem!

Cheers,

Michi.

Thanks for the quick turnaround. it works now.
Build question: The generated binaries are much larger than the original ones,
using VS 2005 and your build instructions. I assume the default is a debug
build. How do i configure your make file for a release build?

Karl

[dwayne]

Edit config/Make.rules.mak.cs and comment out the DEBUG line and uncomment the OPTIMIZE line.

[michi]

In terms of performance, an optimized build will basically make no difference. (At least, that's what I found last time I ran benchmarks and compared debug and optimized builds.)

I have to admit that I never paid much attention to the difference in size. How much of a difference do you see?

Whatever difference there is would be due mainly to the additional symbol information for debug builds. But I would hope that the symbol table would reside in a separate section in the assembly, so it wouldn't have to mapped into memory when the assembly is loaded. But I'm guessing here--anyone know for sure?

Cheers,

Michi.

[kwaclaw]

In terms of performance, an optimized build will basically make no difference. (At least, that's what I found last time I ran benchmarks and compared debug and optimized builds.)

I have to admit that I never paid much attention to the difference in size. How much of a difference do you see?

Whatever difference there is would be due mainly to the additional symbol information for debug builds. But I would hope that the symbol table would reside in a separate section in the assembly, so it wouldn't have to mapped into memory when the assembly is loaded. But I'm guessing here--anyone know for sure?

Cheers,

Michi.

Actually, I am not talking about Ice for C#, but Ice for C++, as this is what I need to rebuild for your patches to slice2cs. The file size differences for slice2cs are: 308 KB for release, 764 KB for debug builds.

Karl

[michi]

Ah, OK, misunderstanding then. I thought you meant the size of the icecs.dll assembly.

For C++, the executable size really doesn't matter, unless you care about disk space. The debug section in the executable is not loaded into memory at run time, so there is no additional overhead. Without optimization, slice2cs will run a tad slower, but not so that you would notice.

Cheers,

Michi.

[kwaclaw]

Ah, OK, misunderstanding then. I thought you meant the size of the icecs.dll assembly.

For C++, the executable size really doesn't matter, unless you care about disk space. The debug section in the executable is not loaded into memory at run time, so there is no additional overhead. Without optimization, slice2cs will run a tad slower, but not so that you would notice.

Cheers,

Michi.

The problem I actually had was that the debug builds would not run on the other developer's machines (they use slice2java), as they were missing the debug runtime libraries, msvcp80d.dll and msvcr80d.dll. On my machine there was no problem as I have VS 2005 installed.

Karl

[michi]

Ah, OK, that makes sense, yes.

Cheers,

Michi.

[bernard]

Note that the debug Microsoft runtime DLLs are not redistributable ... that's why we don't include them in the Ice distribution. You should only distribute "release" binaries (built with /MD, not /MDd).

Best regards,
Bernard

[kwaclaw]

Note that the debug Microsoft runtime DLLs are not redistributable ... that's why we don't include them in the Ice distribution. You should only distribute "release" binaries (built with /MD, not /MDd).

Best regards,
Bernard

Yes, I know, but the default configuration of your build is for debug.

Karl