any1

A similar thing happened in Iceland a few years ago. Article is in Icelandic: https://www.mbl.is/frettir/innlent/2017/05/05/snaebjorn_daem...

I'm cross-compiling, meaning I'm not compiling on ARM. ;)

It might be helpful though for 64 bit ARM, but my target architecture is 32 bit and because I need webengine I suspect that it will not compile on a 32 bit platform. The problem is that the linker requires more memory than can be addressed in a 32 bit address space for linking chrome/webengine.

I just used google cloud.

Well, I've actually spent 3 days trying to get Qt5 to cross-compile for a custom arm platform. It might be easier for something common like the raspberry pi, but still, you may have dodged a bullet there. ;)

The worst thing about cross-compiling Qt is that I always run into different issues with new releases, and it's not even always consistent between builds. I ended up renting a 64 core VPS to build Qt so that I could iterate faster though build failures, but it's still at least half a day's work to get it to build properly.

Yes, which is why I would always use the second example for the print function.

Edit: In fact it is possible to handle the cases explicitly while enforcing types by having the X-macros call functions in the switch/case and declaring prototypes via the macros:

  #define X(type, ...) void printSettings_ ## name(type);
  SETTINGS
  #undef X

  void printSettings(const Setting& s) {
    switch(s.tag) {
    #define X(type, name) \
      case t_ ## type: printSettings_ ## name(s.name); break;
      SETTINGS
    #undef X
    }
  }

Then you define printSettings_... and have them do stuff with the data.

Yes, this would work. I can see that variant may prove useful for the case that you present, but it is much less elegant for the usecase which the author tries to present.

Edit: Replaced second "useful" with "elegant"

Sum types can actually be implemented quite effectively using X-macros in both C and C++. In fact, I feel like they're simpler and more intuitive than this variant stuff.

Edit: Let's use the same example.

  #define SETTINGS \
    X(string, str) \
    X(int, num) \
    X(bool, b)

  struct Setting {
    union {
      #define X(type, name) type name;
      SETTINGS
      #undef X
    };
    enum Type {
      #define X(type, ...) t_ ## type,
      SETTINGS
      #undef X
    };
    Type tag;
  };
  

Printing settings like in the example becomes this:

  void printSettings(const Setting& s) {
    switch(s.tag) {
    case t_string: printf("A string: %s\n", s.str.c_str()); break;
    case t_int: printf("An integer: %d\n", s.num); break;
    case t_bool: printf("A boolean: %d\n", s.b); break;
    }
  }

We can also load more things into the x-macro, so it's possible to define the switch cases above just like in the structure definition. We could add a third parameter called full_name:

  void printSettings(const Setting& s) {
    switch(s.tag) {
    #define X(type, name, full_name) \
      case t_ ## type: std::cout << "A " full_name ":" << s.name << "\n";
    #undef X
    }
  }

Disclaimer: I have not compiled or run any of this code.

The printing was only a simple example. A less contrived example would be to evaluate an AST. E.g. you would want the '+' operator to do different things for strings and numbers.

Also, your visit function does not do exactly the same thing as the author's example. The author's example also prints the type's name. How would you do that without making the visitor cases explicit?

I used this for my router: http://pcengines.ch/apu2.htm

No complaints yet, except pfSense is not that great with Wifi. It's probably best to do wifi separately if you want to run a BSD flavour on it. I haven't tried installing Linux on it yet, since WiFi is functioning well enough, albeit sub-optimally.

It's usually managers who buy the hype. They're the ones who need to be told to be sceptical.

Nice post, by the way.

During my time as a systems programmer, I've gone from C to C++ to C again.

At first, I didn't understand it so I feared it. Then I understood some of it, so I liked it. Finally, I understood most of it, so the mirage dissolved in front of my eyes and I no longer seek it.

Exactly.

A few reasons:

* It's easier to find people with JS skills than C++ skills

* It takes ages to build Qt and it's unreasonably hard to compile. Building the Linux kernel is far less painful.

* It takes ages to build a single Qt project and we have multiple architectures to deploy to (ppc, arm, x86).

* Remote connections are trivial. People only need a browser to connect remotely.

The people at the company who have been using it like it a lot. They just have to put together a few tags and boom there's your GUI.

The GUI has access to some system variables via WebSocket. We have a two-way binding abstraction so people don't have to think too much about events and such.

I wouldn't recommend HTML for a small company though. Better stick to Qt if you're a small group of competent C++ programmers.

I work at a company that's in the food industry.

Currently, we're running Linux with Qt 4 on PowerPC.

We're moving to a newer CPU (i.MX6 quad core). Freescale announced that they would continue manufacturing and supporting it for 15 years and it comes in industrial grade and consumer grade packaging depending on your needs.

We're moving away from Qt for the GUI. HTML5 is the way of the future. ;)

For people who are starting out, I'd recommend using Yocto. It's a build/development environment for embedded Linux. Look it up.

Edit: By they way, if it's not real-time critical, there's nothing stopping you from using any programming language you like except how difficult they can be to cross-compile.

For hard real-time stuff you need a dedicated rt system and you'll have to use C, C++ or maybe Rust.

For soft real-time stuff you can get away with RT-patched Linux. Any language with GC is generally bad with the exception of Erlang, Go and Nim; where the GC is optimised for low latency rather than bulk through-put.

I made a "JSON parser generator" a few months ago. There is no memory overhead because it just puts the json data straight into a C struct while it's parsing.

https://github.com/marel-keytech/jsoncc

nim has some sort of automatic cycle detection. You might want to look into how they do it. It doesn't hurt to check it out.

Excellent! I was hoping that the answer would be that there is no GC.

Does it have GC? Or does it perhaps use reference counting? Can it detect cyclic references?

s/everything/ready-made sandwiches/;

I live in Iceland. The trick is to either prepare your own sandwiches or eat something else.

This works quite well on my Nvidia Shield Android TV. Now I just need a way to easily shift between the browser and the terminal.