dmytroi

Probably just so they look better in the final build.

I also work in gaming industry and IMHO it depends on games, usually the biggest fun is on consoles market, people start making AAA games with engines like Unity, Unreal Engine 3/4, Autodesk Stingray (recently was bitsquid) and then they suddenly realize "oh, we are not getting 30 fps here, because of Lua/C++/etc" and then the fun starts: IIRC one game company was even asking Microsoft to add missing intrinsics to xbox one compiler because they were used in PS4 code, and PS4 and X1 are basically almost the same chip :)

I really love time restricted environments, in my opinion they truly liberate programmers: instead of using language/library/tech/pattern/etc-of-choice they suddenly realize "oh, we don't have time for that". Do we need GC? We don't have time for that. Do we need to allocate memory? We don't have time for that. Can we maybe do this enterprise-like tens thousands source code files OOP hierarchy thing? We don't have time for that.

Realtime forces people write less, writing only what actually matters, and all this in my opinion helps people to be better engineers (in-a-way). I just wish it looked more attractable for people - hacking your way out in time/resources constrained systems (like MCU's for example) can be as fun as hacking html/js to make your site behave as you want.

Well, to be honest, very few programs are able to orchestrate >2GB allocations correctly when complied to 32 bit binary, like Visual Studio linker is not aware of >2GB sizes by default (one need to /LARGEADDRESSAWARE flag for it), which was a trouble for modern browsers because linker was unable to fit everything in limited virtual address space.

And another to be honest, very few programs on desktops/mobile are actually checking return values of malloc/calloc, because of amount of data that program operates is usually much smaller than amount of RAM available. It's sure a case for embedded, but you simply usually don't use malloc for embedded.

Ehm, FPGA/CPLD are everywhere, it's hard to say, but my educated guess is that hardware market consumes similar amount of SoC-like and FPGA/CPLD chips, look, even Pebble smartwatch uses Lattice iCE40 FPGA, MacBooks also usually have few FPGA's here and there. FPGA/CPLD's are essential to implement "glue-logic", which does what it says - glue different pieces of hardware together. Of course you can do "glue" in software, but than your customers will enjoy poor battery life time and random glitches here and there. And nobody gonna spend big-money (it's actually depends, sometimes it 1kk+$, sometimes you can get away by 30-50k$) by running their own ASIC's when you can just buy jellybean FPGA's.

Indeed phone/desktop market might move to more one-chip-for-everything solution, but even then we need glue-ish logic to control something like screen backlight DC-DC converters, charging IC's, etc, which is much more easier done from FPGA/CPLD-like devices. On the other hand FPGA/CPLD's are essential in some classes of devices, for example test instruments: modern oscilloscopes usually have 3+ FPGA's in them, companies like Keysight usually only run custom ASIC's when they hit limitation of current silicon tech, like their N2802A 25GHz active probe (starting from 23500$) uses amplifier IC made with indium phosphide process (InP), which is kinda far away from whatever current consumer product companies are doing, you can check the teardown of this beast here https://www.youtube.com/watch?v=jnFZR7UsIPE

So in my opinion FPGA/CPLD market will live long and strong, players might change, but demand is enormous. The only problem in my opinion is that whole market is more B2B-like (FPGA's are usually just a humble IC's inside end customers products, you don't see stickers "Altera inside" or anything on products themselves), so it's kinda hard to get grasp what's going on.

I think "don't make header file libraries" is a good assumption to have, but reality is - stb libraries are one of the best library set I ever used in C/C++ domain. They are small enough to avoid "messy and a nightmare to modify" and powerful enough to be a great replacement for more "bloated" libs.

For example I recently replaced libjpeg and libpng with one stb_image.h, it reduced 100kb of executable size, improved image loading speed by around 2x, reduced crashes on invalid image data for about 30% (we use american fuzzy lop fuzzer for testing).

Yes, and this .h file will be used from .c/.cpp because looks like it's way to bulky to add additional .m/.mm file just for OSX/iOS case when creating cross platform applications. Check tigr - it's possible to run exactly the same C/C++ code on Windows and OSX without any changes at all.

Not really, because everything is C/C++ there by means files are .c, .cpp and not .m or .mm, its a bit tricky from build system point of view to treat the file with extension .c/.cpp as Objective-C.

One practical example would be tigr [1] - a cross platform window framework for making simple applications, could be compiled as one header drop-in only lib. You simply cannot make it one header without making calling ObjC runtime from C. Why it's necessary to make it work as one drop-in header? Well it's a new trend in C libraries, which allows using libraries with the least resistance possible, it's like a package manager but nicer - you only have one file! Great example of modern one header libs is probably the famous stb package [2].

- [1] https://bitbucket.org/rmitton/tigr/src

- [2] https://github.com/nothings/stb

I would recommend you to try CodeFlow from celedev [1], it's a dynamically generated Lua binding to Objective-C. Plus a nice editor with hot reloading support and other cool features.

- [1] https://www.celedev.com/en/codeflow/

It depends, most of important and heavy lifting stuff in Apple platform, aka Core frameworks, are written in C, for example a quote from Core Text documentation [1]:

> Many of the low level libraries in OS X and iOS are written in plain C for speed and simplicity.

And don't forget that OSX/iOS are based on Darwin BSD, where most of heavy lifting is done by programs written in C.

- [1] https://developer.apple.com/library/mac/documentation/String...

IMHO it depends, C/C++ work very nicely with immediate mode UI frameworks, for example nuklear [1], imgui [2]. Though retained mode C/C++ UI frameworks are also quite popular, for example Qt, wxWidgets, GTK.

- [1] https://github.com/vurtun/nuklear

- [2] https://github.com/ocornut/imgui

Thanks for the comment!

On OS X if OBJC_OLD_DISPATCH_PROTOTYPES is not defined, you will get this declaration with zero arguments: void objc_msgSend(void /* id self, SEL op, ... */ ), which is possible to call from C without cast by using implicit function declaration, but this call will fail if compiled as Objective-C code with error "too many arguments to function call", I've decided to write in a style that compiles as C and Objective-C code.

PS. Would be nice to be able to use functions from clang Objective-C runtime [1], but for some reason they are not exposed in the public headers.

- [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#r...

From the first blog post:

> Files are represented by strings

I think it's especially true for make - looks like it was designed to efficiently express operations for transformations of the same type (like .cpp -> .o/.obj). So in different use case it may become a bit clumsy to use. Ninja should help a bit in this case - you can define a rule, and just use rule name when defining inputs and outputs of a build statement, though it still operates on files.

>[Problems with] combinatorial dependencies

Yes, partially this could be fixed with wildcards in make. Ninja doesn't have wildcard support, so I've created the buildfox [1] to fix it :)

>Non-representable dependency structures

I think it's a limitation of this type of build systems, their configuration language oriented on expressing "how" to achieve things, not "what" to achieve.

- [1] https://github.com/beardsvibe/buildfox/

Honestly the format looks a bit over-engineered IMHO. The task is quite simple: make build system that executes jobs on clusters. So why not get best build configuration format practices and just make them run over network? For example ninja build system [1] format is quite good in my opinion, so just make runtime execute commands over network. Or travis-ci [2] is another example of well designed configuration format, and it really enables developers to write small and powerful configurations. Sure it was even done before (though mostly for C/C++ stuff), like IncrediBuild [3] for example, or FASTBuild [4] or distcc [5]. Though the case with precise control of pipes could be improved in current build systems, but not sure how important it is for this application.

- [1] https://ninja-build.org/ - [2] https://travis-ci.org/ - [3] https://www.incredibuild.com/ - [4] http://fastbuild.org/ - [5] https://github.com/distcc/distcc

Would be awesome to combine it with something like https://bitbucket.org/rmitton/tigr which is a small and tidy window creation/input processing lib, because I find glfw and SDL too bulky for casual C/C++ programming.

Currently I work as engineer in video games, and I would like to say that next step is just to write software completely without malloc+free and GC : you just allocate virtual pages directly from OS, create your own pool allocators in them, and that it. When you need to "free" stuff you just wipe whole virtual page, O(1) free, faster then anything you could imagine. We have only three special cases : string operations (usually implemented with special string pool), heap (malloc + free) for libraries that cannot live without it, and everything else on stack.

That said, I honestly don't understand why everyone only talks about GC and malloc+free abstractions, because they simply do not materialize in physical world at all (even if malloc needs a new page, it will call kernel for it), cpu/kernel do not have such mechanisms, so this is only abstract limitation in developers heads. So why not just talk (if we actually end-up in situation when we need to talk about memory, 'cause usually it's just work) and measure about what's actually real?

I would agree on some of your points : few minutes initialization times and 1-2 GB heaps may sound not that bad, and when we are talking about product that just provides a fancy, over engineered way to run bunch of shell scripts (considering jenkins doesn't integrate sandboxing from the box) ... honestly there is no excuse to spend 2 gigs of ram just to run shell scripts with web UI. It would be much better in a long term to improve energy/resource efficiency of software like this, just to make it more sustainable and reliable.

Edit: configuration-as-code feature is available in jenkins 1.x with job dsl plugin [1], I'm using it at work, because managing 50+ jobs by hand was just insane. Nowadays we just have few dsl files :)

[1] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin

FMOD [1] sound framework provides one of the best C API's in industry : stable, works everywhere, clean and beautiful. Please find API example at [2].

[1]: http://www.fmod.org/ [2]: https://github.com/fmod/ue4integration/blob/master/FMODStudi...