The hand-waving comes from other languages which can’t do anything to prevent their users encounter such bugs and the ensuing CVEs.

Safety is a nice side-benefit. The main reason why I like the safety is because it allows you to fearlessly write high-level code without being constantly paranoid about memory as in C++. It’s more about enabling ergonomics without loosing performance, rather than security or correctness.

I'd disagree with this point, there is more typing involved with a first draft of code than Python or Typescript, that's certainly true, but if we bring all the tools (e.g. docblock comments for "type declaration") that are habitual to make up for the shortcomings in most developer's minds then that gap shrinks and, imo, ends up swapping. It's cheaper to have automatically enforced and consistently maintained checks than moving that information out of band and the resulting code in a strictly typed and memory enforced language ends up removing a significant cognitive overhead when reading and maintaining the code.

I have a strong aversion to boilerplate code so it's important to try and allow terse expressions when possible - but unstated assumptions are worse than overstated assumptions.

With access to inline asm, all speed is ultimately more a measure of effort applied than PLang. So those perf ideas are just "with my level of effort". Even Python via Cython has pretty direct access to asm. The "do it in pure X" that Sun popularized (even in a meta-/cross-PLang-sense) as a business attempt to define Java virtual machines as The platform has had many casualties, not the least of which is the quality of discussion of PLang practicalities, not just on HN, but everywhere.

PS: I was very enthusiastic about Cython for a good while and I went deep into it, but I found that it is rather a mess to use in practice. Yes you get C performance within Python, kinda, but you also get all the C footguns, amplified by the complex interactions with Python features.

EDIT: With Cython how I mostly kept things organized was the "caller allocation" so common in C where memory was always managed the usual mostly refcounting way of CPython/NumPy, but I had dozens (maybe even 100) little "kernels" I could pass that memory into that could even use Intel/MSFT "intrinsic" asm calls (things like immintrin.h) or even just #include C code which did similar. It didn't seem too bad to me, but Nim always seemed a more complete solution (at the PLang level - not counting ecosys). (And these days there is even NimPy (https://github.com/yglukhov/nimpy) to write low-level speed-up code for Python in Nim.)

Yes, you can pass around an object of procedures, but that is awkward, doesn't have any support from the language or stdlib, and from what I can tell isn't a normal thing that is done.

I think you & I are really back & forth-ing "the PLang not enforcing/strongly encouraging a very specific way of doing things that a whole ecosystem/community organizes around". Relying instead on self-organization has many pros & cons, to be sure. Lisp suffered much the same "until" Common Lisp (which still leaves many things open). My tag line lately is: delegation affords so much, but trust sure is tricky. Much of the time people seem to discount the often rather large cost of establishing/maintaining trust. (I'm not saying you are - just that it's an easy thing to do. I think it's why there is this is a big megathread on "trusting rust", even though "rust" is a veritable suffix of "trust". Lol.)

If I need the absolute fastest code, then that code will be tortured under valgrind. That’s non-negotiable in my book.

Code is not done until its memory management is proven correct.

If not, why would they be allowed to do the same in C++

[0] https://safecpp.org/draft.html

C++ has a terrible reputation which is well associated with, say C++98, if you have a good linter you can bop people on the head for using news anywhere outside a few limited locations where you consider it warranted. All working environments have language features or even programming paradigms that are considered detrimental to code ecosystem health and fighting against these is an organizational lift when working in any programming language. Full type security doesn't mean someone can't create an overly generic object and just start breaking code contracts across the code base. C++ has an awful lot of footguns and more warts than most but it can be made to be sane for development and the new language features really bring it on par with other modern languages.

I have worked in C++ (primarily within the Qt framework which pushed hard into const refs instead of pointers) and it's fine. I've also worked in PHP which can also be fine. Rust isn't something I've worked at scale in but it certainly is very attractive if I ever jump to an org working in it - but even in Rust you'll want to restrict style divergence and bad patterns with linting.

    std::unique_ptr<int> p(foo());
    std::print("{}\n", *p);

These issues will exist for all time. The only question is how rare can we make them.

The obvious follow-up is to find a minimal set of rules that allow us to express what we want without permitting temporal unsafety. The borrow checker is one set of fairly minimal rules that works pretty damn well. Alternatively you could define away the unsafety by giving it semantics, like fil-C does.

It is kind of annoying to use, but at least there is an obvious default choice.

Consider reading past the hashtag.

1) First issue: I do not know what your manufacturing constraints are for PCBs...the number of layers is not documented. I don't even know if you support FlexPCBs.

2) I suppose I could figure out if you could make my boards in seven days if I played your upload game...but I should have to do that. Even the following site, with its clunky UI, makes it more clear what they can or can't do: https://quickturnpcb.co.kr/

3) You say you ship "tested" boards, but what does that mean? Firmware testing? Emissions testing? If you ultimately choose the MPNs, does that mean you own the failures if the board doesn't come up?

4) It's not clear if you accept consigned parts. It's not even clear if you are properly storing the parts you are kitting with respect MSL, ESD, etc.

5) In the end, what makes you any different from a typical broker like Millenium Circuits Limited? (Not that I am endorsing them, as I have had terrible experience from them as well)

6) If you are owning testing and promising quick turnarounds, I would assume you are actually shipping test fixtures to the CM before they ship so they can rework if necessary. But again unclear from your description

Just stop working on this site for 3-4 days and get your mission statement together. Maybe put some pictures of actual test fixtures if you test boards or any of your rework equipment. Every PCB/PCBA shop out there puts rework videos on its 'gram. It's just really hard to understand your business with this edgy/terse hustler kind of talk. Or your careers page where I get the sense that move fast and break things is the backend philosophy. Not a good look for someone who wants PCBs fast.

I so want this to work but holy cow I can't even understand where you guys are coming from.

So if someone is telling you not to trim the lead...I'll let you draw your own conclusion.

As a matter of fact I even put my finger up to the screen to verify that the edges were not in any way wobbling. The subtracted shape is a gyroid, which in no way has natural axes, so I beg your forgiveness for still not understanding the question.

I meant what I said, that it appeared that you hadn't bothered to read the page, or to fully read the comment. Your question is talking about a sphere (which can, btw, be rotated "off axis"), while the original comment was indicating one of the subtracted spheres from the page. Any of those subtracted spheres could be rotated off axis. So either you were ignoring a pertinent part of the original comment, or hadn't bothered to look at the subjects that comment was directed towards (either of these scenarios would violate HN guidelines).

Off-axis rotation could mean many things in the context of the original comment, as is pointed out by other responses to your first comment. While it's true that a gyroid has no planar natural axes (by design), a gyroid can have many natural axes, depending on the space it is modelled in and the criteria for axis selection. For example, an axis can be found in the radial symmetry about the center of mass of a gyroid, in an infinite number of planes.

A sphere can also be rotated off axis. If the axis of rotation is not projected across the center of mass of the sphere (rotation would be different than the infinite number of natural axes going through center of mass) is one way. Another way would be if the axis of rotation tended toward one of the COM natural axes at both ends, but was non-linear. Another off axis rotation would be if the axis of rotation was the natural axis, but was not co-planar with the rotation of the viewing axis, which would make it appear to wobble.

Was there a need for this attitude (which, by the way, violates HN guidelines)?

I was looking, not unreasonably, at the linked page. I see that indeed the first example on the "Examples" page exhibits this wobble - thanks to user jmiskovic who was actually helpful.

As far as being helpful, I don't think your first comment falls into that category either.

We have the empty string: "\0"

We have the null string: NULL

There is no concept of an INVALID string, as float has NAN.

This would be the result of trying to copy a string to a buffer that is too small.

Or sprintf() into a small buffer.

Or a raw string parsed as UTF-8 and is invalid.

Correctness over efficiency.

You've mentioned NaN propagation in another comment and I think that's a perfect example of the problem with this approach. Sorting a vector of arbitrary floats is a notoriously thorny problem because any float could be NaN, and as NaN is incomparable to any other float, there is no total ordering of floats. There is no general solution to this problem that doesn't involve making assumptions that could be faulty for some applications.

There are sensible answers. But they are weird.

I would say let an INVALID string be length 0. Then accept that catting a valid and invalid string would result in a shorter length.

Which one do you think is safer?

Negative lengths are not compatible with unsigned representation.

A system implementing invalid string values must choose a text encoding such as UTF-8 that supports the concept of an invalid character. Null termination is too flexible. As such is simple length prepending.

I understand how one could shoot down implementations, but none has made a convincing argument about shooting down the idea.

memcpy and company are strictly for raw unencoded buffers.

C doesn’t have the notion of “size of buffer” (yes, arrays have a size that can be queried by sizeof, but only at compile time). You would have to fix that, first.

Isn’t that just NULL?

  strstr(NULL, /* valid string */)

  strstr(/* valid string */, NULL)

  #include "Protocol.h"

  #include "comms/comms.h"

  namespace cc = comms_champion;

  namespace demo
  {

  namespace cc_plugin
  {

  Protocol::~Protocol() noexcept = default;

  const QString& Protocol::nameImpl() const
  {
      static const QString& Str("Demo");
      return Str;
  }

  }  // namespace cc_plugin

  }  // namespace demo

https://github.com/arobenko/comms_all_protocols

the ublox example seems a reasonably complex protocol of messages.

However, I'm not really sold on the framework to do it this way.

  // Put this in header to help user calculate allocation needs but hide size from user
  size_t LIBNAME_alloc_size(param1, param2, ...);

  // Put this in the header to hide the size from user code but allow inlined size calculations
  extern const size_t LIBNAME_ALLOC_X;

  // Put this in the header to make size known to user (for static const allocation)
  #define LIBNAME_ALLOC_Y ((size_t)42)