C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

What are the official prerequisites for this course?

# ? Nov 15, 2023 16:58

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 10:50

Ihmemies: Oct 6, 2012

ultrafilter posted:

What are the official prerequisites for this course?

Programming 2: Basics, where we learn how classes and pointers etc basic stuff works with c++, and where we make a graphical Snake game with Qt Widgets in the end.

I finally got the dynamic graph building to work, when more data is added. It even appears to work as expected based on tests. It took quite a bit of thinking to realise what kind of problems I need to solve for the graph building, and some experiments to implement them.

For example if one publication is added to n affiliations, I need a Cartesian product of the affiliations, and add connections between them, or strengthen new ones..

Next I�ll try to implement BFS for the get any path function.

Now every node stores an unordered set of ConnectionID�s, which can be used to access the node�s connections form an unordered map. This should allow at least BFS to work!

I guess I need to implement some hashing functions for these umaps and usets too, like this:

C++ code:


struct ConnectionHash {
    std::size_t operator()(const Connection& conn) const {
        auto hasher = std::hash<AffiliationID>();
        auto hash1 = hasher(conn.aff1);
        auto hash2 = hasher(conn.aff2);
        // Combine hash values with a "magic" number for better distribution
        return hash1 ^ (hash2 + 0x9e3779b9 + (hash1 << 6) + (hash1 >> 2));
    }
};

# ? Nov 15, 2023 18:43

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

That doesn't seem to line up with the assignments you've posted. Are they limited in how many students they can accept to upper level courses? In that case, maybe this is the weedout course. If not, it sounds like it's just incredibly badly taught.

# ? Nov 15, 2023 18:47

Ihmemies: Oct 6, 2012

ultrafilter posted:

That doesn't seem to line up with the assignments you've posted. Are they limited in how many students they can accept to upper level courses? In that case, maybe this is the weedout course. If not, it sounds like it's just incredibly badly taught.

Well, actually I just noticed they suggest the book Introduction to Algorithms, Second Edition from Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein as the course book. I don�t remember it being mentioned but I found it from the course description (who reads those?!). They don�t reference the book in any course material, perhaps they assume students will figure it out by themselves what chapters they need to read, if they are in a need for more information.

So totally my fault. Sorry for the n00b questions here :doh:

# ? Nov 15, 2023 18:58

epswing: Nov 4, 2003; Soiled Meat

I've got an C++ app (MFC running on Windows 10/11) every few seconds polling (via libcurl) an ASP.NET site running on IIS on the same PC. I'd like to stop polling and reverse this communication, by having the ASP site signal the C++ app somehow. The content of the signal is small (a few bytes) and not frequent. SignalR comes to mind but the .NET Framework (i.e. pre .NET Core) cpp SignalR client library seems abandoned. Named pipe? Socket? MSMQ? Is there a recommended/modern mechanism for this?

epswing fucked around with this message at 21:58 on Nov 22, 2023

# ? Nov 22, 2023 21:33

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

epswing posted:

I've got an C++ app (MFC running on Windows 10/11) every few seconds polling (via libcurl) an ASP.NET site running on IIS on the same PC. I'd like to stop polling and reverse this communication, by having the ASP site signal the C++ app somehow. The content of the signal is small (a few bytes) and not frequent (once every few seconds). SignalR comes to mind but the .NET Framework (i.e. pre .NET Core) cpp SignalR client library seems abandoned. Named pipe? Socket? MSMQ? Is there a recommended/modern mechanism for this?

If the thing being polled is a web server then the way to do that is typically either "long-polling" or websockets. Long-polling is significantly easier to implement but maybe easier to make a mistake with.

# ? Nov 22, 2023 21:36

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

if "thing being polled" is always going to live on the same host, and both programs have access to the file system, you could drop a flag file and use inotify to watch for the file being created/modified/whatever.

(I've seen this done with a bunch of different mechanisms: UNIX domain sockets, UDP datagram, long-polling over TCP, websockets. All things being equal, none are any better or worse than any other, but certain choices (websockets, I imagine, in particular) might be more difficult to do in MFC-land.)

# ? Nov 22, 2023 21:51

nielsm: Jun 1, 2009

Also, if it's happening on a single machine within the same login session, you can also consider just using Win32 messages (SendMessage or PostMessage) if the data is small. Or you can expose a local out-of-process COM server from one of the two ends and have the other register a callback object with the other.
Win32 messages is perhaps not "modern", but it's very robust and well-understood in my experience, and definitely not going out of support any time soon. Neither is COM, but it definitely requires a bunch more being familiar with various concepts, but if you do it right then it gives you a very flexible RPC interface.

# ? Nov 22, 2023 22:19

nelson: Apr 12, 2009; College Slice

MFC is still a thing?

# ? Nov 22, 2023 22:51

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Dijkstracula posted:

(I've seen this done with a bunch of different mechanisms: UNIX domain sockets, UDP datagram, long-polling over TCP, websockets. All things being equal, none are any better or worse than any other, but certain choices (websockets, I imagine, in particular) might be more difficult to do in MFC-land.)

I would argue that UDP datagram is worse in most situations because you *generally* don't want to miss messages, or implement your own thing for detecting and re-sending potentially missed messages. And if we're talking like the level of UDP datagram then there isn't long-polling over TCP, there's just a TCP socket, long-polling is for http (which, yes, is generally over TCP, but it would be a weird way to describe it). Other than that though, yes.

Also this now has me wondering would long-polling over http3 (which is not over TCP) make sense or not.

Edit: also realizing maybe long-polling wasn't quite the right term for what I meant, that's generally for notification of rare updates. HTTP subscription for fast small updates is *similar*, but instead of one-poll one-eventual-reply, it's one-poll, stream-replies, re-poll-when-client-or-server-timeout-nears. I don't know if there's a name for that. It also has a good chance of playing poorly with proxies.

roomforthetuna fucked around with this message at 23:43 on Nov 22, 2023

# ? Nov 22, 2023 23:40

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

epswing posted:

I've got an C++ app (MFC running on Windows 10/11) every few seconds polling (via libcurl) an ASP.NET site running on IIS on the same PC. I'd like to stop polling and reverse this communication, by having the ASP site signal the C++ app somehow. The content of the signal is small (a few bytes) and not frequent. SignalR comes to mind but the .NET Framework (i.e. pre .NET Core) cpp SignalR client library seems abandoned. Named pipe? Socket? MSMQ? Is there a recommended/modern mechanism for this?

I wouldn't use signalR because you're a native app and signalr is more oriented towards making it so browsers don't have to poll. Also, I hate signalR.

Named pipe will work fine in your scenario since everything is on one machine.

If you ever plan on making it so the app and IIS live on different servers then you might be better off with socket.

Message queue is another way that would work but seems to be overkill for your use case.

You could potentially get any of these solutions to work though, I think named pipe is easiest so that's my vote.

# ? Nov 23, 2023 07:22

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

This discussion makes me think of 0mq. Did anyone ever take/use it seriously? I enjoyed reading their docs but never found a use for it.

# ? Nov 23, 2023 07:29

nielsm: Jun 1, 2009

Named pipes can also work over network, but it's probably difficult to ge it just right if you don't have both machines joined to the same domaine. And if you expose a pipe to the network, you need to mess around with their ACLs too.

# ? Nov 23, 2023 08:04

Ralith: Jan 12, 2011; I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

roomforthetuna posted:

Also this now has me wondering would long-polling over http3 (which is not over TCP) make sense or not.

Pretty sure in HTTP/3 the server can just straight up send you stuff without being asked first.

# ? Nov 23, 2023 09:40

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Joke answer for interprocess communication, grpc.

Not a joke in that it wouldn't work, but a joke in that every 3 months you'd have to restructure your entire build system because Google decided to change protobuf and/or absl and/or grpc again in a not-backwards-compatible way AGAIN and it's a massive pain in the arse.

# ? Nov 23, 2023 13:35

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

roomforthetuna posted:

I would argue that UDP datagram is worse in most situations because you *generally* don't want to miss messages, or implement your own thing for detecting and re-sending potentially missed messages

granted, yes, this is a thing you'd have to consider but this is why I qualified over localhost/behind the same rack switch; the OS will only drop messages when OS buffers fill up and, say, you're blasting huge quantities of datagrams with huge payloads over loopback

e: but yeah the point of my list was to say "hey any number of solutions will do"

Dijkstracula fucked around with this message at 15:55 on Nov 23, 2023

# ? Nov 23, 2023 15:46

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

roomforthetuna posted:

Joke answer for interprocess communication, grpc.

Not a joke in that it wouldn't work, but a joke in that every 3 months you'd have to restructure your entire build system because Google decided to change protobuf and/or absl and/or grpc again in a not-backwards-compatible way AGAIN and it's a massive pain in the arse.

Wait, I thought protobuf was really stable?

But also, just because Google does something doesn�t mean you have to upgrade unless they�re fixing something that�s an issue for you. Your software works, you can leave it alone.

# ? Nov 23, 2023 16:13

korora: Sep 3, 2011

pokeyman posted:

This discussion makes me think of 0mq. Did anyone ever take/use it seriously? I enjoyed reading their docs but never found a use for it.

Yes, we use it for same-machine IPC for robotics at my company. (Think ROS but not ROS). The API is very C but cppzmq is a nice C++ abstraction layer.

# ? Nov 23, 2023 18:30

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Subjunctive posted:

Wait, I thought protobuf was really stable?

Protobuf is definitely not really stable, they keep changing build APIs all the time, and they added the 'Any' type which potentially makes the "stable" serialization unstable again, and the switch from proto2 to proto3 changed a lot of things (especially cross-language compatibility) and the addition of map types was the thing that originally destabilized serialization, especially for golang, and the golang API changed its implementation of the oneof type, and the javascript protogen moved out of the main library and then the *next* update of the main library was incompatible with the separated-out google-owned javascript library for over a year, to pick just a few examples of things that have made my life difficult that I happen to remember.

quote:

But also, just because Google does something doesn�t mean you have to upgrade unless they�re fixing something that�s an issue for you. Your software works, you can leave it alone.

As for not needing to upgrade, yeah, this was a work rant really - at my work we have a monorepo and use envoy, and updating envoy requires us to update absl, protobuf and grpc (and other things too), each of which typically breaks everything else so it's a huge pain in the rear end every time.

(Having any dependency that uses tensorflow would be another thing that probably would force you to update the whole chain of google libraries.)

Though actually not just a work rant - I moved my personal project from protobuf to flatbuffers in the hope of escaping google-churn, and even that wasn't stable so I ended up just writing my own serialization API that's better for my purposes in literally every way anyway. (Smaller generated code, simpler API, smaller serialized size, and embedded types.)

# ? Nov 23, 2023 20:17

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

None of those things you've mentioned change the wire format though? Like, if you haven't changed the proto definition itself, you can upgrade the libraries and then keep reading protos serialised by the old version (and serialise protos that the old version can read). Unless you're using the weirdo "serialise to json instead of to the actual proto wire format" thing, I dunno how that one works.

proto3 is only a big change if you actually choose to use it, and no-one's forcing you to do that - you can keep using your existing proto2-formatted definitions and they still compile to the same thing.

# ? Nov 23, 2023 23:24

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Jabor posted:

None of those things you've mentioned change the wire format though? Like, if you haven't changed the proto definition itself, you can upgrade the libraries and then keep reading protos serialised by the old version (and serialise protos that the old version can read). Unless you're using the weirdo "serialise to json instead of to the actual proto wire format" thing, I dunno how that one works.

proto3 is only a big change if you actually choose to use it, and no-one's forcing you to do that - you can keep using your existing proto2-formatted definitions and they still compile to the same thing.

I didn't say they changed the wire format. My point is the library keeps changing API and build stuff so it will absolutely be a pain in the rear end every time if you have some other thing that has a dependency on it that you have to update, and a triple pain in the rear end if you have two or more things that depend on it because inevitably one of them will update before the other and until they sync up you have to build with two different versions of the proto library in the same environment, or patch one of your dependencies yourself so it will build against a different version, and it absolutely sucks balls.

Google pretty explicitly does not give a poo poo about open source clients of their libraries except *maybe* abseil, and it shows in how they migrate APIs with no kind of bridge deprecation period. Or, perhaps the best example, in how they literally had their protobuf open source library become build-incompatible with the protobuf-javascript open source library that is also owned by Google, and stay that way for over a year, with a front-page readme on the github repo that straight up said as a gently caress you "this is broken, we have this working internally and don't have funding to support the open source version, we expect to have it fixed by November 2022", up until about 2 weeks ago (in November 2023) when it actually updated.

So anyway, it was a throwaway joke about overkill using grpc for a task where it wouldn't be necessary or helpful, because it's front-of-mind for me because I've been doing a version update *for over three loving weeks* it's so bad this time. The serious comment I'm making is "if you don't have to, and there's not a really big benefit, don't use a Google library because the future cost is almost certainly higher than it would be for other similar libraries."

Edit: We all know this about google products in general of course, but for some reason it remains a bit shocking when it happens with libraries.

roomforthetuna fucked around with this message at 03:28 on Nov 24, 2023

# ? Nov 24, 2023 03:25

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

I guess I misunderstood what you meant by stable serialisation.

# ? Nov 24, 2023 03:30

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Jabor posted:

I guess I misunderstood what you meant by stable serialisation.

Oh, I see. Yeah, that's a different thing entirely from what I was originally talking about, but is also a thing! What I'm talking about there is:

1. in old proto, you *could* have the same message serialized different ways, but if you had the message in native form and serialized it, you would always get identical output bytes. This means you could compare two messages with a memcmp of the serialization, or hash it, for example.
2. when map types were added, this changed because a map is an implicitly unordered type. In golang, map types became *intentionally unstable* for serialization, which at the time intentionally broke many existing unit tests even inside google.
3. to compensate for this, a "serialize deterministically" option was added to various serializers, so you could optionally get back the behavior from timepoint 1. This would deterministically sort map types when serializing.
4. when the "any" type was added, it broke the behavior of that option, but the option still exists, making the behavior quite surprising. The TextFormat serializer will, in the current version, serialize deterministically even through Any types, if you set the right options, but the binary serializer does not have the options to do this; if there's a map type inside the message inside an Any field, or if the Any field was previously serialized a different way (as has been valid all along), asking for deterministic serialization will get you nondeterministic serialization.

For a fun sequence of events around this, here's a little adventure through the years:
https://github.com/envoyproxy/envoy/pull/5814 - "oh no it's not deterministic"
https://github.com/protocolbuffers/protobuf/issues/5668 - "you can make it deterministic" "oh yeah, okay, we did that, we're good"
https://github.com/protocolbuffers/protobuf/issues/5731 - "actually no we're not, they still aren't deterministic" "oh yeah, Any fields aren't supposed to do that. Try just not using them."
https://github.com/envoyproxy/envoy/commit/647aea1d97be232930306183f94536d3e1f7d9ed - "aha, text formatting supports this"
https://github.com/envoyproxy/envoy/pull/30761 - "yeah but the performance of that loving sucks"

# ? Nov 24, 2023 03:52

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

I'm real happy that I convinced an architect of a project I worked on 8 years ago not to use protobuf, need to give past me a high-five.

# ? Nov 24, 2023 04:56

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I don�t think any of our other in-use serializers are guaranteed to be deterministic, so that�s probably fine for us. Weird that they want it to be deterministic but also not?

# ? Nov 25, 2023 23:35

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Subjunctive posted:

I don�t think any of our other in-use serializers are guaranteed to be deterministic, so that�s probably fine for us. Weird that they want it to be deterministic but also not?

Also weird, in the C++ library there is a GetRepeatedRef<type> template for repeated fields, but no Get<type> or GetRef<type> for non-repeated fields which makes writing handlers for that frustrating (you have to either repeat poo poo a lot or use gross macros so that you can do like int32_t x = reflection.GetInt32(args) and uint32_t x = reflection.GetUint32(args). I don't think there's any reason not to template - it would also be a nice place to add Get<string_view>, instead of making the existing interfaces change from std::string& to string_view in a way that breaks existing code!)

# ? Nov 26, 2023 00:28

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Today I learned that the gRPC and protobuf teams at Google are separate!

# ? Nov 27, 2023 18:54

OddObserver: Apr 3, 2009

Subjunctive posted:

Today I learned that the gRPC and protobuf teams at Google are separate!

Why wouldn't they be?

# ? Nov 27, 2023 19:37

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

OddObserver posted:

Why wouldn't they be?

Sorry, I was typing while distracted and forgot to add that per my source they are �not very close�.

I could definitely see the same team doing both though, and that would probably be my instinct rather than staffing two teams each with all the language and platform expertise. It seems like the rate of change to that stuff is (should be?) low and want to evolve in a coordinated way, but maybe that�s a misconception.

# ? Nov 27, 2023 20:55

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Subjunctive posted:

Sorry, I was typing while distracted and forgot to add that per my source they are “not very close”.

I could definitely see the same team doing both though, and that would probably be my instinct rather than staffing two teams each with all the language and platform expertise. It seems like the rate of change to that stuff is (should be?) low and want to evolve in a coordinated way, but maybe that’s a misconception.

Thing of Google as a government. Why buy one when you can buy two?

# ? Nov 27, 2023 21:48

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Subjunctive posted:

Sorry, I was typing while distracted and forgot to add that per my source they are �not very close�.

I could definitely see the same team doing both though, and that would probably be my instinct rather than staffing two teams each with all the language and platform expertise. It seems like the rate of change to that stuff is (should be?) low and want to evolve in a coordinated way, but maybe that�s a misconception.

This is actually a good reason for them to be separate teams, in that changing protobuf should be as painful within google as it is outside, and that pain should be screamed about to discourage disruptive changes.

Unfortunately it doesn't actually work like that because neither of them use the open source repository, they both build in a shared monorepo so the changes are easy and simultaneous, the victim team doesn't even have to fix it themselves, and any breakages are just foisted onto open source users later without much of a care.

# ? Nov 28, 2023 01:43

Xarn: Jun 26, 2015

So I have this in my code

C++ code:

#if defined(__cpp_lib_uncaught_exceptions)
#  define YEP_WE_CAN_USE_UNCAUGHT_EXCEPTIONS
#endif // __cpp_lib_uncaught_exceptions

and later,

C++ code:

bool uncaught_exceptions() {
#if defined(YEP_WE_CAN_USE_UNCAUGHT_EXCEPTIONS)
        return std::uncaught_exceptions() > 0;
#else
        return std::uncaught_exception();
#endif
}

(names changed slightly :v:

)

Today I got a bug report from someone building for MacOS, targetting 10.9, that the build fails with

code:

error: 'uncaught_exceptions' is unavailable: introduced in macOS 10.12 - see https://conda-forge.org/docs/maintainer/knowledge_base.html#newer-c-features-with-old-sdk
        return std::uncaught_exceptions() > 0;
$BUILD_PREFIX/bin/../include/c++/v1/exception:185:63: note: 'uncaught_exceptions' has been explicitly marked unavailable here
_LIBCPP_FUNC_VIS _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS int uncaught_exceptions() _NOEXCEPT;

And I want to know, how is MacOS a real platform real people build for? Why the gently caress does the library define the feature macro, just to mark the function as "UNAVAILABLE, gently caress YOU FOR EVEN TRYING"?

# ? Dec 11, 2023 11:30

Twerk from Home: Jan 17, 2009; This avatar brought to you by the 'save our dead gay forums' foundation.

Xarn posted:

So I have this in my code
C++ code:
#if defined(__cpp_lib_uncaught_exceptions)
#  define YEP_WE_CAN_USE_UNCAUGHT_EXCEPTIONS
#endif // __cpp_lib_uncaught_exceptions
and later,
C++ code:
bool uncaught_exceptions() {
#if defined(YEP_WE_CAN_USE_UNCAUGHT_EXCEPTIONS)
        return std::uncaught_exceptions() > 0;
#else
        return std::uncaught_exception();
#endif
}
(names changed slightly )

Today I got a bug report from someone building for MacOS, targetting 10.9, that the build fails with
code:
error: 'uncaught_exceptions' is unavailable: introduced in macOS 10.12 - see https://conda-forge.org/docs/maintainer/knowledge_base.html#newer-c-features-with-old-sdk
        return std::uncaught_exceptions() > 0;
$BUILD_PREFIX/bin/../include/c++/v1/exception:185:63: note: 'uncaught_exceptions' has been explicitly marked unavailable here
_LIBCPP_FUNC_VIS _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS int uncaught_exceptions() _NOEXCEPT;
And I want to know, how is MacOS a real platform real people build for? Why the gently caress does the library define the feature macro, just to mark the function as "UNAVAILABLE, gently caress YOU FOR EVEN TRYING"?

Did you read the docs that were linked? That person isn't just building on a Mac, they're building inside of conda, which is its own incredibly hosed up environment. On Linux I've run into a whole host of problems because by default on Linux Conda ships and compiles against a CentOS 6 sysroot, which isn't actually C++11 compatible. They considered moving to a Centos 7 Sysroot last year in 2022, and decided that it was too soon and to stick with Centos 6.

The docs on that link say that the build failure only happened because

quote:

The libc++ library uses Clang availability annotations to mark certain symbols as unavailable when targeting versions of macOS that ship with a system libc++ that do not contain them. Clang always assumes that the system libc++ is used.

However, since conda-forge ships its own (modern) libcxx we can ignore these checks because these symbols are in fact available. To do so, add _LIBCPP_DISABLE_AVAILABILITY to the defines.

It looks like conda on mac as configured uses the system Clang but ships its own libcxx. System Clang pre-emptively decides to tell you that uncaught_exceptions is not available because they are not in the system libc++, but if you're building in conda you aren't using the system libc++. Conda has so many nasty edge cases, welcome to this one.

Also, Mac OS 10.9 launched in 2013, support ended in 2016, tell them good luck with their problems with their OS that has been out of support for 7 years.

Edit: All this to say, if you want this to work in conda on Mac OS, add -D_LIBCPP_DISABLE_AVAILABILITY to your CXXFLAGS. I've also had a lot of maintainers just tell me "conda isn't supported, gently caress off, use a real distro" because at its core, conda has turned into the stupidest possible rolling release distro of linux.

Second edit: The other way that I would tackle this is that you can also use the non-Apple vanilla clang compiler on Mac OS in Conda by adding "llvm-openmp" to your dependencies in the conda meta.yaml. Apple clang does a lot of weird stuff so people tend not to use the system clang in order to make things work more consistently across Mac OS / Linux.

Twerk from Home fucked around with this message at 16:16 on Dec 11, 2023

# ? Dec 11, 2023 16:09

Xarn: Jun 26, 2015

I've read that specific section.

But as I understand it, the sequence of events goes
* Conda targets some ancient version of MacOS. Not great, but also not a crime.
* libc++ has the ability to tell you that such and such API is not available in the target version of MacOS, because it knows it is tightly bound to specific version. This is actually really nice.
* libc++ happily defines the macro for a feature it will not let you use when targetting older versions. <-- this is actually terrible and can gently caress right off.

# ? Dec 11, 2023 16:51

Twerk from Home: Jan 17, 2009; This avatar brought to you by the 'save our dead gay forums' foundation.

Xarn posted:

I've read that specific section.

But as I understand it, the sequence of events goes
* Conda targets some ancient version of MacOS. Not great, but also not a crime.
* libc++ has the ability to tell you that such and such API is not available in the target version of MacOS, because it knows it is tightly bound to specific version. This is actually really nice.
* libc++ happily defines the macro for a feature it will not let you use when targetting older versions. <-- this is actually terrible and can gently caress right off.

I haven't run into this landmine personally, but my impression of what's happening is:

* Conda targets some ancient version of MacOS. Not great, but also not a crime.
* Apple clang has the ability to tell you that such and such API is not available in the target version of MacOS's system libc++, because it knows it is tightly bound to specific version. This is actually really nice.
* You aren't actually using system libc++! You are linking against a newer version of libc++ that conda-forge provided, that does have the features you want. The macro is defined because those symbols are there, they're usable. However, system clang doesn't know that you're using a different libc++, and system clang tells you that it's not available before actually trying to link and finding those symbols.

Edit: the suggested fix is just telling clang not to check, because when you link it will actually work.

Twerk from Home fucked around with this message at 17:00 on Dec 11, 2023

# ? Dec 11, 2023 16:57

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

This specific problem is Conda's fault. They're shipping their own copy of libc++ to enable backdeployment to older OS versions, including their own copy of the headers, but they haven't updated the headers to reflect that and instead the headers are configured for using the system deployment. Bundling libc++ isn't a particularly exotic thing and they're just doing it wrong; they're supposed to be defining _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS.

Apple's availability system is really awesome for Apple SDKs, but for complicated reasons doesn't really work for libc++. For most symbols, the availability check is a warning that's silenced by guarding uses with if (__builtin_available(macOS 13.0, *)) { ... } and handling the case where it's not available at runtime. If you ignore the warning and hit the use of the symbol on a platform where it's not available you crash. A few c++ symbols are instead a strict availability check and don't support the runtime check. Usually this is for things like vtables that can't be weakly linked, and I'm not sure why uncaught_exceptions is one of them.

# ? Dec 11, 2023 18:04

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Availability is a more sophisticated feature than you�re giving it credit for. �That feature requires macOS Y, but your deployment target is older than Y� isn�t an unresolvable problem because you can dynamically test the OS version you�re running on with if (__builtin_available(macOS Y)), and the availability warning will be suppressed within that block. Of course, that means you have to have a fallback path for when you happen to run on an older OS. If you�ll never actually do that, you should just increase your deployment target.

That�s not integrated with feature-test macros because the right solution probably never to compile as if the feature is unconditionally unavailable. It would also have a bunch of practical difficulties around lexer/parser layering and the presumption that those macros give consistent results everywhere in the TU.

If you�re building with the macOS SDK and using a macOS target triple but not actually targeting macOS, that seems like a You Problem.

# ? Dec 11, 2023 18:23

Twerk from Home: Jan 17, 2009; This avatar brought to you by the 'save our dead gay forums' foundation.

Plorkyeran posted:

This specific problem is Conda's fault. They're shipping their own copy of libc++ to enable backdeployment to older OS versions, including their own copy of the headers, but they haven't updated the headers to reflect that and instead the headers are configured for using the system deployment. Bundling libc++ isn't a particularly exotic thing and they're just doing it wrong; they're supposed to be defining _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS.

This would have to go into the header that conda-forge bundles with their newer libstdc++? This is probably an easy fix and I've gotten them to accept all sorts of other stuff too. The conda-forge project just happened, nobody is really making sure that everything works or is done the right way.

rjmccall posted:

If you�re building with the macOS SDK and using a macOS target triple but not actually targeting macOS, that seems like a You Problem.

Do you mean compiling stuff on Mac OS in the conda forge environment? They ship their own libcxx, headers, all libs, sometimes their own compilers but sometimes the system compiler. I am in past my depth (like everyone who touches conda, it seems) and don't know quite what you mean.

# ? Dec 11, 2023 19:53

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Twerk from Home posted:

This would have to go into the header that conda-forge bundles with their newer libstdc++? This is probably an easy fix and I've gotten them to accept all sorts of other stuff too. The conda-forge project just happened, nobody is really making sure that everything works or is done the right way.

They should set -D LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS=NO when building libc++, which will result in the generated config header having the appropriate define set.

# ? Dec 11, 2023 20:22

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 10:50

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Weird question: does the first function called in a C++ program absolutely have to be called main, or can we rename it to something else?

The reason I ask is because I just started some work on an embedded microcontroller with an asymmetric dual core, one is a (relatively) beefy Cortex M7 and the other is a weaker Cortex M4 on the same silicon. When kickstarting the chip from power on and doing all of the stuff to init the processors before handing off fully to the software side I end up with two functions, both called main(), when a more natural naming might be main_m7() and main_m4(). My IDE absolutely rejects me naming them that, but having two different things with the same name is mildly confusing in the code.

I suppose I can just make each main() call a pass-thru function to main_m7 and main_m4, but it's just an interesting thought experiment to consider naming them something else natively.

# ? Dec 12, 2023 05:55

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »