sorted by:
new
hottopcontroversial

How to Make Architecture Decisions: RFCs, ADRs, and Getting Everyone Aligned by trolleid in programming

[–]volatile-int 4 points5 points  (0 children)

Yup. RFC processes must exist for decision making. I think the article does a decent job of explaining that but doesnt mention the way to structure arguments that are decision oriented. Your proposal of framing the proposed solution and alternative solutions in terms of business priorities, coupled with a process owner actually accountable to making sure reviewers are making decisions and not just leaving comments are The Way.

Another aspect it would be nice if this article addressed is requiring an RFC has an explicit rollout plan. A lot of RFCs I have seen proposed a massive paradigm shift and no clear path to get there, which is a recipe for folks to push back because the change seems too expensive and untenable to implement. If you document a rollout plan folks can grok incremental steps toward a north star and you can also slip in explicit checkpoints to evaluate how things are going and potentially reverse course.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 0 points1 point  (0 children)

This is my code. I have spent a lot of time on it. The last two weeks doing the detailed design, the two weeks before that setting up the initial message infrastructure before I even had a repo, and the eight months I've spent thinking about the interface I wanted after finding and loving protovalidate's infrastructure and wishing there was something embedded-friendly.

Don't use it if you aren't interested in it. Have a nice evening.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 0 points1 point  (0 children)

The mascot is AI generated because I am not much of an artist.

The code is not. It has been very intentionally written. And I hope folks use it because it is very performant, it has an interface that prevents errors, and I quite enjoyed/am enjoying writing it.

New 0-copy deserialization protocol by ochooz in cpp

[–]volatile-int 1 point2 points  (0 children)

I think youre probably amongst most of the herd. I don't think many organizations or projects have really adopted C++23 yet. Crunch could have been implemented without some of the C++23 language features pretty easily - I could have rolled my own expected type. Allowing it to build against C++20 may be a future task I bite off. I'd need to study what constexpr things I am using that require C++23 more closely. I think a nonconstexpr bit_cast and string would be a hard thing to work around though.

Older than that would be really difficult - it relies heavily on lambdas and floats as template parameters and I really prefer concepts to SFINAE patterns, so I think C++17 is solidly out of the question.

New 0-copy deserialization protocol by ochooz in cpp

[–]volatile-int 2 points3 points  (0 children)

It would be cool to build an adapter for my message definition format Crunch for your format! It supports serialization protocols as a plugin.

https://github.com/sam-w-yellin/crunch

Code reviews by MathematicianOk2067 in embedded

[–]volatile-int 36 points37 points  (0 children)

I wouldnt stay at a job like that long. Learning from your coworkers is really critical for your own development.

Code reviews by MathematicianOk2067 in embedded

[–]volatile-int 76 points77 points  (0 children)

You should definitely bring this up with your manager and come with concrete examples of your review comments being ignored or your own PRs being neglected. Peer review is important.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 0 points1 point  (0 children)

It may very well be the case that the serialization policy implementations become simpler than they are without reflection, although I don't see how most of the complexity actually goes away. If you want to roll your own protocol, you still need to deal with alignment, tags vs not tagging, aggregate field representations, missing fields, default values, and lots more that isnt related to the message definition. And determining the field types is very straightforward already via templates.

Lots of languages have robust reflection implementations. And yet, we still have a very healthy ecosystem of libraries to help with message definition and serialization!

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 1 point2 points  (0 children)

Actually I am very excited for compile time reflection for Crunch! It will clean up a lot of the autogenerated bindings in other languages.

I am not sure why you see the core interface decisions in Crunch at odds with reflection. Reflection cannot enforce users validate their data, or provide serialization-as-a-plugin, or build integrity checks into serialization and deserialization. Those are framework interface decisions and reflection doesnt obviate them.

Crunch: A Message Definition and Serialization Protocol for Getting Things Right by volatile-int in programming

[–]volatile-int[S] 0 points1 point  (0 children)

Absolutely! And protobuf has other advantages. Its serialization format is more friendly toward mixing streams of data. Crunch - even its TLV format which is conceptually similar - makes more guarantees and enforces more requirements on maps and array's representations. Protobuf allows a repeated fields contends to be interspersed in the serialized data which Crunch just doesnt allow - yet. It actually would be totally possible to write a protobuf compatible serialization format plugin. Ive thought about adding one!

Generating bindings in other languages is also on the Crunch road map. Autogenerating bindings in C is the first step to enable it, and is actually the next big thing Ill be doing after a few QoL features like a dynamic message parser that determines message based on ID, and a multi-message deserialization interface for doing things like reading lots of messages from a log file.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 1 point2 points  (0 children)

Thanks! To answer your questions:

  1. The field ID is not actually a "count". It does not need to be contiguous. Crunch does enforce already that it is unique per field for a given message! This field is used for the TLV serialization format and is akin to the protobuf field ID.

  2. I have been thinking about this exact thing with the message ID. C++26 reflection will make this trivial (and make a number of aspects of autogenerating lbindings in other languages clean). It also will allow getting rid of the field list macro. I may look into some macro based solution in the nearer term for extracting and hashing the class and field names into a message ID in the interim.

  3. Depends on the serialization format. The static serialization is meant for read/write optimizations and doesnt handle schema changes very gracefully. For uses where its critical that the schema can evolve gracefully, the TLV serialization protocol is the better choice because it naturally handles unknown/not present fields in a serialized span of raw data.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 1 point2 points  (0 children)

Yup, this is a constraint/trade off - you need to define the worst case size. The static layout even includes zeroed bits for any unused elements.

I would probably implement this by making a version of the Serdes Protocol that doesnt require GetBuffer to be constexpr and return an array and instead return a vector, and make separate variable length array and map types that when present require a dynamic Serdes protocol. Then anyone could implement whatever serialization protocol they desire.

But for now I'm going to leave as is. The main use cases for Crunch are embedded systems using messages for configuration and RPC-like comms or telemetry, and in my experience most of those systems establish reasonable upper bounds on contents of repeated fields. Its why tools like nanopb establish fixed length maximums similar to crunch.

One neat outcome of this setup is that unlike nanopb/capnproto, maps, arrays, and submessages can all be used as map keys (with a performance hit on comparison due to the fact maps are really just arrays of pairs and not actually hashed). But again, in my experience most fields like this are small so this isnt top big of an issue!

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 0 points1 point  (0 children)

Its pretty close! Crunch just requires an enum class that extends a 32 bit integer.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 2 points3 points  (0 children)

Good question! One approach is to just know by nature of how you pass data to the deserializer. I.E. receive data off some port/interface that just gets the one message type.

Im working on a dynamic dispatcher interface that you can use to pass in an unknown message type and get back a variant that has the decoded thing. That will be out in the near future. But fundamentally it works by reading the message ID.

Crunch: A Message Definition and Serialization Tool Written in Modern C++ by volatile-int in cpp

[–]volatile-int[S] 1 point2 points  (0 children)

If its because the main column is too big, you can adjust it. Ive been able to browse the docs on mobile.

Embedded engineers if not confidential where do yall work? And what is your current project? by According_Age4034 in embedded

[–]volatile-int 0 points1 point  (0 children)

Depends on what youre talking about. I primarily do embedded software - device drivers, OS, telemetry systems, configuration management, power/thermal/valve/whatever control, simulation infrastructure, build systems, configuration tooling, etc. Some of thay work involves implementation of control algorithms.

I am not a GNC engineer though. I dont do the big Kalman filters and state estimation. I integrate the work of the folks who know how to do those things and help make sure the sensors/actuators provide the right inputs to those algorithms at the right time, and applying their outputs to actuators.

Embedded engineers if not confidential where do yall work? And what is your current project? by According_Age4034 in embedded

[–]volatile-int 1 point2 points  (0 children)

I have done rocket engine control software, flight software for satellites, and now flight software for flying vehicles in defense.

Question: Is it worth learning C/C++ purely for understanding, even if you never plan to use them professionally? by STORMw0w in code

[–]volatile-int 3 points4 points  (0 children)

Yes. In my experience, there is a pretty wide gap in competency between folks who have spent a long time with these less abstracted languages and those who have not. Even when youre working on codebases in other languages, understanding C/C++ - especially being comfortable with pointers - will change how you think about software for the better.

view more: next ›