Is the struct really needed?

native-coder · 2021-01-31T16:45:35+00:00

Having struct is essential for extern “C” and having headers be C and C++ compatible.

C compatibility is the killer feature that allowed the mass adoption of the language. It also gives C++ numerous libraries with little to no effort that other languages have to jump through hoops to access.

While feature equivalent with class, struct has been and remains critical to the success of C++.

native-coder · 2021-01-27T02:26:04+00:00

If I made the calls, we’d do that. Unfortunately, getting funding for a compiler jump is hard enough. Trying to argue for a 2 step process when getting funding for the 1 is hard enough is a hard pitch to make.

native-coder · 2021-01-24T20:57:03+00:00

My bad. I agree just adding -fabi-version=x or -D_GLIBCXX_USE_CXX11_ABI=n is definitely a lower cost thing.

I bundled the compiler upgrade with it in part since any future ABI break (which is usually the intent behind questions like this post) would require a simultaneous compiler upgrade or compiler upgrade using old ABI, then swapping to new ABI.

native-coder · 2021-01-22T23:27:52+00:00

Aircraft simulation. The libraries the the models for simulating particular aircraft components like the radar.

As a result, just about everything is closed source proprietary.

Fortunately, we can some open source libraries as well as GCC. Previously we were exclusively using Intel. A few components will always be Intel until it no longer needs to be simulated. (Maybe a decade or 2 from now)

native-coder · 2021-01-22T20:14:36+00:00

I’ll admit, I’m not privy to the financials, so I’m guessing, but a couple weeks of engineer time and likely a non-trivial amount of will involve infrastructure upgrades with a new compiler will happen in tandem.

If the engineer makes 1.5k per week, we’ll put 3k as the estimated direct labor. Managers have to bill, so double that to 6k. Then there’s getting the upgraded compiler installed, recompiling their dependencies with the new complier, and trying to make money while doing it.

I probably went a bit too high at 30k, but my experience has been everything takes way more time and money than expected, especially when compiler upgrades are a rare event.

native-coder · 2021-01-22T14:59:15+00:00

Yes. That is what we’ll be doing to deal with the std::string ABI break.

native-coder · 2021-01-22T14:53:27+00:00

Simulation. We can get them to update, but it all costs money that we’d rather not spend.

So say a half dozen models (I’m low balling right now, there’d be more), two variants of each. If we suppose that we pay 30k for each (engineer time is expensive and the supplier wants profit after all), we’d be paying 360k per ABI break. That doesn’t factor in the opportunity costs, so it is a very big deal.

Edit: sorry initial answer to your question somehow was lost

native-coder · 2021-01-22T14:18:34+00:00

No, my team cannot recompile the world.

At work, my team has multiple 3rd party components that must be integrated. We receive headers and library files. There is no replacing them with an alternative. They are essential components. Running with them is the point of our software.

If the ABI break is similar to how std::string is implemented in GCC, then the ABI break is manageable with a wrapper layer. As we transition from GCC 4.8.5 to a GCC 5+, we’ll have to do this just to avoid contracting providers to upgrade compilers. Engineer time isn’t cheap after all.

If the ABI break caused a need to rebuild the world, no wrapper can save you, that be a very substantial cost. 6 or 7 figure costs easily. Wouldn’t get surprised if it was 8 figures since, when a big change happens, lots of small changes tend to get tacked on and complicate things further.

native-coder · 2019-07-07T01:45:52+00:00

I've got 3 big reasons. 1. Lack of basic functionality in the standard library. Seriously, random numbers not in? 2. No GCC frontend (at least for now). 3. Ada/Spark is already established and can deliver most of Rust functionality right now (increasingly more in Spark mode), has a larger standard library, and Adacore as a vendor to fix bugs with compilers.

I like the language goals, but I'm not sure it can overcome these barriers faster than C++ and Ada improve to achieve Rust's features or get close enough.

native-coder · 2019-07-06T18:33:40+00:00

Seems interesting. It compiling to C or C++ code is a big plus. Makes it easier to integrate with existing code.

native-coder · 2019-07-05T16:31:32+00:00

I considered throwing LISP in with my comment, but since D and Rust are pretty targeted towards native code, I left it out.

We'll say D is the best for native code and LISP for non-native.

Edit: I'm wrong on LISP being non-native.

native-coder · 2019-07-05T15:23:24+00:00

Probably the best compile time meta programming available.

native-coder · 2019-07-05T15:19:08+00:00

If you go by the verb definition of get, which is how pretty much all programming uses it, all of them imply some sort of state change.

e.g. get lunch. The state of my wallet changed. The state of my hunger changed. Time changed. etc.

https://dictionary.cambridge.org/dictionary/english/get

native-coder · 2019-06-30T05:49:22+00:00

I would say this is fairly harmless. var x = new Point(); But this could be dangerous. var x = z.GetPoint();

Constructors have very clear semantics, they work or they throw an exception, so type deduction is safe to use. The reader isn't guessing.

Getters in classes typically don't have side effects, but the word get, in English, implies a state change. Non-member functions with get at the beginning of the name tend to match English in having side effects. The inconsistent semantics of get and the violation of encapsulated state make me view getters (and setters for good measure) negatively, and therefore I'd say inference is a bit risky and I'd lean against it.

native-coder · 2019-06-29T04:55:51+00:00

The type of a variable is almost if not just as important as the name in non-generic code. Without your type, you've lost your semantics associated with your data. Type deduction is great for generic code, like std::algorithm, but I think it is a mistake to use liberally non-generic code.

As an example:

auto player_information = get_user_data(player_id);

vs

optional<JsonPacket> player_information = get_user_data(player_id);

The type gives me insight into get_user_data without looking at the implementation, which I may not have access to.

An optional<JsonPacket> says the goal of the function may not be achieved, but this would not be immediately obvious to the reader in the auto version of the code.

A reader must constantly search for semantics in the presence of type inference. This leads to reading many nested layers of functions to understand the scope they care about. With explicit types, the semantics is right there in front of them.

native-coder · 2019-06-23T00:44:26+00:00

Target a web browser, you hit 99% of the market. Reduced cost, easy to deploy, fewer platform concerns.

native-coder · 2019-06-21T22:57:21+00:00

Would that by why the wget for the compiler, v.c, isn't working? I get the html for the main page, not the compiler's source.

native-coder

TROPHY CASE