adaptiveconsulting / simple-binary-encoding Goto Github PK

see https://github.com/real-logic/message-codec-bench

It appears that real-logic have deleted the c# code base that adaptive (?) contributed as it was not kept up to date (real-logic#310)

Are there any plans to bring the c# code up to the latest RC3 implamentation that is supported in the real-logic repo?

Related to this, I think I have found an issue with the CURRENT c# code generation, and its unclear if this should be reported in this repository or in real-logic's one (I'm pretty sure its here...)

Can you elaborate on how you see this going forward?

The code generation is currently generating expressions with pointer logic which will be hard to test and DirectBuffer leaks a byte pointer... which forces consumer of SBE to compile their code with unsafe flag (which is clearly not acceptable).

Tasks:

• create methods on DirectBuffer to read and write to the underlying buffer
• update the code generation to use those new methods
• write unit tests covering new DirectBuffer methods

I ported the java API which uses iterators to access groups. This makes the C# groups API very weird to use. We should review that but we should not introduce memory allocation..

We want to define acceptance tests to validate the code generated is valid, from SBE spec perspective.

The schema contains optionally a description of the different properties, we should display that when available and also other information which can be useful during development (Optional/required, null_value, sinceVersion, Min/max values, etc...)

Optional fields, exposed as C# properties should encapsulate null values (the value used to represent null, as defined here: https://github.com/WeAreAdaptive/simple-binary-encoding/blob/master/main/java/uk/co/real_logic/sbe/PrimitiveValue.java)

Current generated code is very close to Java API, which is not very idiomatic for a C# developer. We need to go through the generated code and decide how the different SBE constructs (fields, composites, bitsets, etc..) should be implemented and exposed in .NET.

Output of this task should be a list of the changes to apply in the code generation.

Some initial ideas:

• optional fields as Nullable<>
• set to be implemented a C# enum with [Flag]
• groups API is horrible, need to be looked at

We may want to target portable class library and environments which won't be able to call unsafe code.

Once the API is stabilised we should add a wiki page to document the .NET API

review real-logic#42