Hmm, well it seems like there are reasons to be pragmatic. You may also need to get someone who is as familiar with dot net is are the guys who've come up with the java solution. You're getting the opinions of people who've thought about it for about 10 seconds before posting.
I think it's a common pattern to use StringBuilder as a memory buffer for strings as I suggested in my post. It's done all the time for pinvoke when taking a LPSTR as an out buffer. You may have to figure out what you need to do to lock down the memory while accessing it, which I assume the runtime has to do before the call, but it will work. I think some of the other suggestions will work as well. -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Jon Rothlander Sent: Tuesday, November 14, 2006 10:48 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? I just wanted to point out the reason we are doing this because a number of post have suggest not try this at all. Here's the basic reasoning behind attempting to this and not just wanting to rewrite it. The options for the client are really pretty simple. If there is no solution in .Net, the client will simply throw out .Net as a solution, as .Net doesn't look like it can handle this. They would have the option of working with other .Net languages such as COBOL for .Net, which kind of destroy the whole point of moving to .Net in my opinion. So I find it hard to recommend that to a client. The odd thing here is that this is being done in Java without any issues... or at least the issues where not big enough to throw out the solution. So in my opinion the client would simply choose Java over .Net since .Net cannot handle this. The estimates that we are coming up with are about $20M to rewrite and about $300K to $600K to migrate the code in Java. So it would be hard for a $10M company to pick .Net over Java with the price tag of $20M compared to $600K. No matter how many points we give them in regards to how .Net compares to Java, the price tag along will kill it. I don't know how Java is able to do this, but it does. There are legacy tools to translate this code into Java... and they work. Whatever solution the Java tools are using would seem to be something I could use in .Net. Maybe that's the direction I should go with this. De-engineer a Java solution. =================================== 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
