Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[csharp] use IDirectBuffer implementation from Agrona.NET #492

Open
bpb1 opened this issue Aug 5, 2017 · 17 comments
Open

[csharp] use IDirectBuffer implementation from Agrona.NET #492

bpb1 opened this issue Aug 5, 2017 · 17 comments

Comments

@bpb1
Copy link

bpb1 commented Aug 5, 2017

It would be nice if Aeron.NET and the generated c# from sbe referred to the same IDirectBuffer interface. I guess this is dependent on AdaptiveConsulting/Aeron.NET#57

@mjpt777
Copy link
Contributor

mjpt777 commented Aug 2, 2018

@JPWatson Should anything be done on this?

@swimtver
Copy link

Hello,
Do you have any plans to implement it?
Or could you give me some tips how properly manipulate bytes from Agrona IDirectBuffer to DirectBuffer from this package.

Thanks for advance.

@mjpt777
Copy link
Contributor

mjpt777 commented Nov 28, 2018

@swimtver I hear that @JPWatson plans to push a C# generator that uses this.

@JPWatson
Copy link
Collaborator

Yes, I have been working on it. We've got an early stage generator for SBE that uses .NET implementation of Agrona.

For the time being, there is a workaround. You can use the pointers to wrap the same underlying memory.

public static unsafe void Wrap(this DirectBuffer target, UnsafeBuffer source, int length)
{
   target.Wrap((byte*) source.BufferPointer.ToPointer(), length);
}

@swimtver
Copy link

@mjpt777 , @JPWatson thank you very much!

@juddgaddie
Copy link
Contributor

@JPWatson Any update on how you are getting along with this?

@JPWatson
Copy link
Collaborator

We have been incubating a generator that mirrors the Java generator and uses the Agrona.NET interfaces. Would be happy to share that if you're interested?

@juddgaddie
Copy link
Contributor

That would be much appreciated.

@JPWatson
Copy link
Collaborator

@juddgaddie Feel free to have a place around with this:
https://github.com/JPWatson/sbe-generators

@JPWatson
Copy link
Collaborator

Eventually, I hope to get this into the main repository once it has some tests around it.

@JPWatson
Copy link
Collaborator

JPWatson commented Mar 21, 2019

I also use this generator in Aeron.NET to generate the Archive/Cluster codecs.
https://github.com/AdaptiveConsulting/Aeron.NET/blob/master/scripts/generate-archive-codecs.bat

Source for this build of the JAR is here:
https://github.com/JPWatson/simple-binary-encoding/commits/csharp-update

@juddgaddie
Copy link
Contributor

Thanks for sharing, @JPWatson which version of CSharpGenerator is more up to date https://github.com/JPWatson/sbe-generators or https://github.com/JPWatson/simple-binary-encoding/commits/csharp-update ?

@JPWatson
Copy link
Collaborator

AFAIR there isn't any difference between the generators themselves.

@juddgaddie
Copy link
Contributor

@JPWatson is the bounds checking not implemented simply because you didn't get around to it or is there any technical reason?

@JPWatson
Copy link
Collaborator

JPWatson commented Apr 5, 2019

@juddgaddie There is bound checking code in UnsafeBuffer but it's set at compile time rather than runtime. From what I remember, there just wasn't an obvious way to mirror the same behaviour as the java version.

@juddgaddie
Copy link
Contributor

Like Java, C# (unlike c/c++) is typically not compiled from sources for that reason I think the bounds checking would be better served with a runtime toggle we could use system environment variables (the same approach as c or c++ code uses for runtime configuration)

I also would think the default build that goes to Nuget should have bounds checking enabled by default.
@JPWatson thoughts ?

Happy to send PRs

@juddgaddie
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants