I agree. The reason cobol allowed this was because it was such a pain to format output it as easier to make the memory structure equal the output format.
-----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ernst Kuschke Sent: Tuesday, November 14, 2006 7:36 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? Hi, My suggestion: stick to simple OO ;o) (Why do you want the fixed 'positional' field in memory???) public class Person { string name; string surname; public string Name { get { return name; } set { name = value; } } public string Surname { get { return surname; } set { surname = value; } } public string FullName { get { return name + " " + surname; } } public Person() { } public Person(string name, string surname) { this.name = name; this.surname = surname; } //Provide extra overloads if you feel you need them... } -- Ernst Kuschke MVP - C# (South Africa) http://www.ernstkuschke.com On 11/14/06, Sebastien Lorion <[EMAIL PROTECTED]> wrote: > > Got some more time to investigate that ... I think the code below does > what > you intended to point out in your original post. That said, for the Full > field to work properly, all other arrays must always be properly padded > with > spaces and not contain a null char. *sigh* I would stay far away from > this... > > using System; > using System.Runtime.InteropServices; > > namespace ConsoleApplication1 > { > class Program > { > static void Main(string[] args) > { > unsafe > { > Name name; > > string first = "f" + new string(' ', 19); > > for (int i = 0; i < 20; i++) > name.First[i] = first[i]; > > //name.First[0] = 'f'; > name.Last[0] = 'l'; > name.Middle[0] = 'm'; > > Console.WriteLine(new string(name.Full)); > } > > Console.ReadLine(); > } > > [StructLayout(LayoutKind.Explicit)] > unsafe struct Name > { > [FieldOffset(0)] > public fixed char Full[60]; > > [FieldOffset(0)] > public fixed char First[20]; > > [FieldOffset(40)] > public fixed char Last[20]; > > [FieldOffset(80)] > public fixed char Middle[20]; > } > } > } > > > -----Original Message----- > > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > > [EMAIL PROTECTED] On Behalf Of gregory young > > Sent: Tuesday, November 14, 2006 3:43 PM > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > > > Yes but you would not be dealing with unmanaged code ... you would be > > dealing with managed code which would be using the reference + and > > offset... So it would avoid the fragmentation. > > > > Cheers, > > > > Greg > > > > On 11/14/06, Sebastien Lorion <[EMAIL PROTECTED]> wrote: > > > My bad, you are right :) That said, if you interact with unmanaged > > > code, you still need to pin the struct which get us back to square > > > one. Also, that struct can get quite large if one is to include all > > > the fields mentioned in the original message. > > > > > > Another thing is I defined the following struct to test this out but > > I > > > cannot get it working like I would think it should, ie making the > > Full > > > field work. Any idea ? My curiosity has been triggered :p > > > > > > [StructLayout(LayoutKind.Explicit)] > > > unsafe struct Name > > > { > > > [FieldOffset(0)] > > > public char* Full; > > > > > > [FieldOffset(0)] > > > public fixed char First[20]; > > > > > > [FieldOffset(40)] > > > public fixed char Last[20]; > > > > > > [FieldOffset(80)] > > > public fixed char Middle[20]; > > > } > > > > > > Sébastien > > > > > > > -----Original Message----- > > > > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > > > > [EMAIL PROTECTED] On Behalf Of gregory young > > > > Sent: Tuesday, November 14, 2006 2:31 PM > > > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > > > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > > > > > > > Sebastien I am 90% sure you are incorrect about fixed buffers in > > > > terms of those being included a struct as "fighting" the garbage > > collector .. > > > > > > > > It should be able to get by without pinning (unlike normal usage of > > > > the fixed keyword) ... remember it defines the memory directly > > > > within the struct so you can just keep the managed reference to the > > > > struct and offset from it. > > > > > > > > ex: > > > > unsafe struct test > > > > { > > > > public fixed char foo[255]; > > > > public int bar; > > > > public fixed bool foo2[128]; > > > > } > > > > static void Main(string[] args) > > > > { > > > > test t; > > > > t.foo[22] = 'c'; > > > > } > > > > > > > > on the access ... there is no need to pin anything in order to > > > > access the variable (it is t + something (he fixed keyword here is > > > > actually putting the array allocations directly in the struct) .. > > > > because of this I would assume no pinning .. no pinning would seem > > > > to disagree with your fragmentation statement and not playing > > nicely with the GC ... > > > > > > > > Cheers, > > > > > > > > Greg > > > > > > > > On 11/14/06, Sebastien Lorion <[EMAIL PROTECTED]> wrote: > > > > > A solution like this is actually fighting against the way .NET > > was > > > > designed. > > > > > Strings are immutable and so you cannot modify a string in-place, > > > > > you need a string builder. Looking on the net you will see that > > > > > there are many benefits to immutability and actually, not only > > for strings. > > > > > > > > > > The problem with the suggested code is that it is very > > inefficient. > > > > > The net result is that you will be creating a new string object > > > > > every single time you read one of the properties. That might put > > a > > > > > lot of stress on the garbage collector and triggers many Gen0 > > > > > collections > > > > and > > > > > thus promote prematurely other objects to an older generation. > > > > > > > > > > On the other hand, by using fixed buffers, you are effectively > > > > working > > > > > against the garbage collector which tries to defragment memory. > > If > > > > you > > > > > have many of these objects in memory, it will be next to > > > > > impossible > > > > to > > > > > defragment it. One of the consequences of that is losing locality > > > > > of reference, one of the most important factor in performance. On > > > > > top of that, using unsafe code requires special permissions on > > the client. > > > > > > > > > > Both solutions also suffer from the fact that you will use 60 > > > > > chars arrays no matter the actual required memory is. "John > > Smith" > > > > > is 9 chars, why waste > > > > > 51 ? > > > > > > > > > > I think one of the point of using such kind of memory layout (ala > > > > > COBOL) was to maximize memory and simplify code. As you can, we > > > > > are far from doing that now. A better and much simpler solution > > > > > would be to have 3 fields (first, last, middle) and concatenate > > > > > them only when FullName is required. Using a method > > > > > "GetFullName()" would further clearly indicate to developers that > > > > > a new object is created and so, they might want to put in a > > > > > temporary variable and avoid calling that > > > > method too many times. > > > > > > > > > > Sébastien > > > > > > > > > > > -----Original Message----- > > > > > > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > > > > > > [EMAIL PROTECTED] On Behalf Of Jon Rothlander > > > > > > Sent: Tuesday, November 14, 2006 1:23 PM > > > > > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > > > > > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > > > > > > > > > > > Thanks for your response. I like your approach this to. This > > > > > > is the kind of thing that I have done in the past to support > > > > > > this sort of issue. Can you tell me why you are not sure this > > > > > > is a good > > > > idea? > > > > > > I want to under the issues people have with this because I am > > > > > > working on a client's code and I want to be aware of any issues > > > > with > > > > > > this approach, as it's similar to what I have been doing. > > > > > > > > > > > > Your solution is very similar to what I have done in the past > > to > > > > > > work around this issue when supporting legacy applications > > in .Net. > > > > > > There's allot of work in translating the code when using these > > > > > > approach, which is what I am trying to avoid by looking at > > > > > > another option. However, the other options seem to be unsafe, > > > > > > and I'm not sure I want to take that leap just yet. > > > > > > That's what I'm currently looking at. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Discussion of advanced .NET topics. > > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Bob > > > > > > Provencher > > > > > > Sent: Monday, November 13, 2006 9:24 PM > > > > > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > > > > > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > > > > > > > > > > > Something like this would work the way you want... > > > > > > > > > > > > public class Line > > > > > > { > > > > > > const int LineLength = 60; > > > > > > const int FirstNameOffset = 0; > > > > > > const int FirstNameLength = 20; > > > > > > StringBuilder sb = new StringBuilder( LineLength ); > > > > > > > > > > > > public string FirstName > > > > > > { > > > > > > get > > > > > > { > > > > > > return sb.ToString( FirstNameOffset, > > > > > > FirstNameLength ); > > > > > > } > > > > > > set > > > > > > { > > > > > > char[] inchars; > > > > > > inchars = value.ToCharArray( 0, > > > > value.Length ); > > > > > > for ( int i = 0; i < sb.Length; i++ ) > > > > > > { > > > > > > if ( i < value.Length ) > > > > > > { > > > > > > sb.Chars[ i ] = > > > > inchars[ i ]; > > > > > > } > > > > > > else > > > > > > { > > > > > > sb.Chars[ i ] = ' '; > > > > > > } > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > } > > > > > > > > > > > > But I'm not sure doing this is a good idea... > > > > > > > > > > =================================== > > > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > > > > > View archives and manage your subscription(s) at > > > > > http://discuss.develop.com > > > > > > > > > > > > > > > > > -- > > > > If knowledge can create problems, it is not through ignorance that > > > > we can solve them. > > > > > > > > Isaac Asimov > > > > > > > > =================================== > > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > > > View archives and manage your subscription(s) at > > > > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > > > > -- > > If knowledge can create problems, it is not through ignorance that we > > can solve them. > > > > Isaac Asimov > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
