Replies: 4 comments 9 replies
-
Hi DJ. First, thank you for your feedback. And in case you're wondering about how careful you need to be with it 😜, just about all my programming is done in Delphi and I accept that my C# knowledge is very limited. So, while I'm keen to host both C# and C++ Clipper2 ports here, I will be relying on those with proficiency in these languages. In fact I'm looking for a couple of poeple with considerable proficiency in either C# or C++ to take the lead in managing those ports here. Are you interested 😁?
Good question. It's a balance as you obviously understand between getting the performance from newer ,NET features vs compatibility with older frameworks. My hope would be to have Clipper2 useful to a significant majority of C# users (eg >70%).
This is critically important as long as changes are supported by target .NET implementations as above.
I'm all for consistency and appreciate that this has been compromised by my focus on coding. Go for it 😁. |
Beta Was this translation helpful? Give feedback.
-
Great. And thanks for all your help so far.
Yes, that a good idea. It seems that the Clipper Nuget package is actually a package of my original Clipper code. I could ask the package owner to retire it, but I suspect the better way is to post a Clipper2 package.
Probably, but I'm open to suggestions. |
Beta Was this translation helpful? Give feedback.
-
Hi Peter. Nothing now as I've just uploaded Clipper2 to NuGet! |
Beta Was this translation helpful? Give feedback.
-
Yes, it's gone. But nevertheless Clipper2 is a lot faster than Clipper1. |
Beta Was this translation helpful? Give feedback.
-
I'd like to start a quick discussion about the C# implementation and potential goals. I was initially intending to have the #11 PR be multi-pronged, but it was merged already into the main branch so I think here is a better place to handle discussion.
Targeting
What is the target of the .NET implementation? If we can target the current .NET Core, we gain significant performance features which is available in the newer and current release of the language. If we need to maintain compatibility with the older frameworks, we can do that, it just significantly complicates the logic as some features don't exist in the older .NET Frameworks.
https://dotnet.microsoft.com/en-us/platform/dotnet-standard#versions
Performance
There are several dotnet systems which can be used to help performance out here I believe. Here are just a few initial items I see.
List<List<Point64>>
(and such) makes the management of the lists easy, but it eats through memory quickly especially when the list's backing arrays are constantly re-sizing. I am doing research about some potential other methods of handling this.Consistency
How opposed would you be to making the C# code consistent between the different clipper CS files?
Clipper.Core.cs, Clipper.Offset.cs and Clipper.cs uses two spaces while Clipper.Engine.cs uses mostly tabs with some spaces mixed in.
Can I make these consistent between each of the source files? Tabs or spaces don't matter much to me. The dotnet community has mostly centered around spaces, but any good IDE worth its salt will work just fine either way. The mixture just becomes irritating sometimes and this seems like a good time to address it.
There is even a standard system in place to have the
dotnet
command format which I can setup to keep the formatting consistent.Beta Was this translation helpful? Give feedback.
All reactions