Programming thread

This is just more retardation. If I write a program that has to do even the most basic POSIX without a library, I've just written a completely non-portable program.
So?

Knowing assembly won't teach you network programming, building distributed systems, or how to write good SQL, all of which are major parts of the modern day computing stack, and indeed libraries. Knowing assembly won't even teach you how to use git, which is now a requirement of software engineering.
Obviously not, it'll just make learning that stuff extremely trivial because at the end of the day it's all the same shit.
 
Yeah, you basically threw a bucket of water into the Mississippi. I'd start looking at game dev forums and sites specifically on promoting your new game. One idea that springs to my layman's mind is sending free license codes to Twitch or YouTube streamers or Let's Players - you'll probably have better luck with the smaller ones because I bet Dr. Disrespect and the like get inundated with them. Maybe look for ones who particularly focus on the genre of game you've made; for example, looking for clips of the recent Microsoft Flight Simulator release, I found YouTube channels that focused on flight sims of various types throughout the years that had massive audiences but I had never heard of them.
Yeah, I know, I just wanted to complain. Besides the game is not big enough to attract any letsplayers, it's just a free web arcade game.
 
Anyone seen the new 2020 C++ standard?

Some interesting stuff but I'm not sure if I'm ever going to use much of it.
 
Anyone seen the new 2020 C++ standard?

Some interesting stuff but I'm not sure if I'm ever going to use much of it.

I shat myself when I saw something as simple and useful as a lerp function added to C++20, it's almost as if in the cthonian depths of the C++ committe there's a lost soul looking to aid the average programmer. The trend is generally to provide library writers with stuff to use not the average end user, and on some level I can agree with that. More constexpr stuff (and is_const_evaluated()) is always welcome and the <=> operator will be useful too for day to day use. I hope I can figure out a day-to-day use of the ranges library because it seems very useful but for the time being I dont see much use for it besides math related things. Other than that I wont use much of it either. I want those fancy metaclasses Herb Sutter rambled about.
 
Is it bad practice to make heavy use of public static members in C#? Also, I know you're "supposed" to make your member variables private and make accessor and mutator functions, but I've heard nobody does that outside of school and I don't do it either because it bloats up the code.
It's generally bad practice to have public static fields, but I wouldn't say there's anything wrong with public static properties. The constraint I'd say is use a function if the property computes something heavy, and use a property if you're only fetching a value with some minor modifications.

Anyone seen the new 2020 C++ standard?

Some interesting stuff but I'm not sure if I'm ever going to use much of it.
Constraints are fantastic. I will be glad to never have to do a single other decltype(std::declval<MyClass>().FuncToCheckFor(std::declval<MyArg>()), void())

the <=> operator will be useful too for day to day use
It's going to be great to be able to implement all six of those stupid fucking functions with just a single function in future. I'm always using a ridiculous mix-in pattern to implement shit like iterators because I hate having to retype the same stupid boilerplate endlessly

This kind of shit. I wish more languages had mixins, I mean this pretty much qualifies for C++, but C# would greatly benefit too. Hate having to rewrite basic shit like index-based iterators
C++:
template<typename TImplementor>
class IteratorMixIn
{
private:
    using Iter_ = TImplementor;
    using Type_ = typename Iter_::Type;
    using DistanceType_ = typename Iter_::DistanceType;
private:
    constexpr const Iter_& getImpl() const {
        return *static_cast<const T*>(this);
    }

    constexpr Iter_& getImpl() {
        return *static_cast<T*>(this);
    }

    constexpr int Compare_(const Iter_& other) const {
        return getImpl().Compare(other); // Access impl functionality
    }

    constexpr Type_& Deref_() const {
        return getImpl().Deref();
    }

    constexpr Iter_ Offset_(DistanceType_ offset) const {
        return getImpl().Offset(offset);
    }

    constexpr DistanceType_ Measure_(const Iter_& other) const {
        return getImpl().Measure(offset);
    }
public:
    constexpr bool operator==(const Iter_& other) const {
        return Compare_(other) == 0;
    }
    constexpr bool operator!=(const Iter_& other) const {
        return Compare_(other) != 0;
    }
    // ...

    constexpr Type_& operator*() const {
        return Deref_();
    }
    constexpr Type_* operator->() const {
        return &Deref_();
    }
    // ...

    constexpr Iter_ operator+(DistanceType_ offset) const {
        return Offset_(offset);
    }
    constexpr Iter_& operator+=(DistanceType_ offset) {
        auto& impl = getImpl_();
        impl = Offset_(offset);
        return impl;
    }

    constexpr DistanceType_ operator-(const Iter_& other) const {
        return Measure_(other);
    }
    // ...
    // Blah blah blah why does every iterator need one hundred fucking lines even if it behaves like a pointer?
};

I want those fancy metaclasses Herb Sutter rambled about.
That sounds like a dream come true, and probably true hell for intellisense lmao
 
In addition to the resource hogging and (AFAIK) difficulty of implementing specific things, another major problem I have with fancy drag-and-drop game engines comes from the very idea that they make it so easy for brand-new game developers and people who barely even know programming to make games. I'm playing through a game jam's submissions right now and like over half of the games have fancy physics and other things that would require reasonably involved code, but completely fuck up things as basic as movement.

I think anyone who hasn't developed a game before should be locked out of anything higher-level than hardware abstraction libraries like SDL and MonoGame until they've made five or so games. They'd be forced to learn how to write functioning controls and design half-decent levels, among other things, before being able to slap in half-assed gimmicks.
 
I think anyone who hasn't developed a game before should be locked out of anything higher-level than hardware abstraction libraries like SDL and MonoGame until they've made five or so games. They'd be forced to learn how to write functioning controls and design half-decent levels, among other things, before being able to slap in half-assed gimmicks.
Momentai, dude. If they make bad games, people will choose good games instead.
 
Can anyone give me into how costly RPC calls are a distributed Apache orchestration model? I'm using Luigi workflow.
 

Well, I'm unsure if the Agent model I'm using could instantiate the orchestration pipelines and monitor them.. I don't want to add airflow, and Beam is a requirement for tensorflow extended and I've heard like one truth from everyone this whole project: Apache is overcomplicated.

I'm basically doing a shit ton transforms like discretized fourier transforms and shit. I as well need a good and portable hive-mind swarming intelligence pipeline.

Like, literally need Beam and Flink FLIP-39 runner in one spot of orchestration, but I'm not sure on a distributed beam architecture if the amount of RPC calls would be way too costly. However, the parallel pipeline shit looks to be the right call.
 
Last edited:
In addition to the resource hogging and (AFAIK) difficulty of implementing specific things, another major problem I have with fancy drag-and-drop game engines comes from the very idea that they make it so easy for brand-new game developers and people who barely even know programming to make games. I'm playing through a game jam's submissions right now and like over half of the games have fancy physics and other things that would require reasonably involved code, but completely fuck up things as basic as movement.

I think anyone who hasn't developed a game before should be locked out of anything higher-level than hardware abstraction libraries like SDL and MonoGame until they've made five or so games. They'd be forced to learn how to write functioning controls and design half-decent levels, among other things, before being able to slap in half-assed gimmicks.
TBH I really hate the fact that due to those fancy engines I now have to compete with those noobs, who couldn't even build something basic like tetris or arkanoid from scratch.

But hey, at least some of them are bound to make something worthwhile, so, more great games for me to play.
 
Is it bad practice to make heavy use of public static members in C#? Also, I know you're "supposed" to make your member variables private and make accessor and mutator functions, but I've heard nobody does that outside of school and I don't do it either because it bloats up the code.

It depends what you're putting in the static members. Static values like PI or random strings sure. It's bad practice to have global state everywhere so you should avoid using it in general. Using static members also makes it impossible to write tests for whatever you're writing if the static member is anything consequential. If you're writing classes you should definitely use encapsulation because it allows you to change behaviour of those later without editing any code outside the getters/setters. Also you can set breakpoints inside the getters/setters to help you track down bugs, which is something you can't do when accessing public members directly.
 
The 8-Bit Guy, a retro tech YouTuber who has also created new games for old computers, shows off his latest project: an action game for various Commodore 8-bits called Attack of the PETSCII Robots.


I would love to have a job where I could hack about on old computers for a living - though I'm guessing he makes much more from making videos about his games than selling the games themselves. If you liked this video, go back and watch the ones he made on his Commodore 64 RTS, Planet X-2, and its 640K IBM PC sequel, Planet X-3. They're pretty entertaining.
 
This seems to become more and more common, I've heard of several games here and there that are made for old platforms. I think it's mostly an on-off thing though, at the end of the day it's still an incredibly niche thing and I can't imagine you could make a living off it.
 
What warnings was Visual Studio even throwing up in the first place?
C26451: https://docs.microsoft.com/en-us/cpp/code-quality/c26451?view=vs-2019

Which is to say, any time there could be an overflow (in principle) but that hypothetical overflow could be avoided if you had cast to a bigger type first, it'll throw the warning.
In practice, they're just dealing with a bunch of small constants that come nowhere near the limit of an int.

VS's C++ analysis is full of awful but well-intentioned rules like this lately. "This could crash on unchecked input!" Yeah, but it's not unchecked.
 
  • Informative
Reactions: SIGSEGV
What's the opinion on Electron? What are the other options for cross-platform app development that allows deployment on windows, linux, mac, iphone, android, etc.
 
What's the opinion on Electron? What are the other options for cross-platform app development that allows deployment on windows, linux, mac, iphone, android, etc.
Fuck Electron and everything ever built with it.

There aren't really any easy answers to multi-platform development for such a wide range of platforms (unless you count game frameworks like Unity, but games aren't really expected to behave like standard applications so much). But that's kind of the point. Windows applications behave quite differently than iPhone applications; they have different input methods, different UI/UX expectations, and so on. If you try to make an application which works the same on both, you end up with something that's both a shitty Windows application and a shitty iPhone application. You know, like every single Electron application.

The "correct" approach is to abstract away the core functionality of the application into a separate "module," and then write custom "wrappers" around it for each target OS which interacts with the core module and presents its input and output in an optimized way for the OS. But developers are lazy and too many of them don't care about their users, so now we have shit like Visual Studio Code, where you can run basically a whole other web browser instance for your code editor with a shitty UI… what the fuck?
 
Back