[ale] Ruby vs C, a non-technical chat

Michael Trausch mike at trausch.us
Thu Aug 6 15:15:37 EDT 2015


Indeed. It was windows and a lack of glib/gobject being tiny and rapidly usable that convinced me to look closely at C++ to assist with the complexity. I like gobject but all the free desktop stuff doesn't apply on windows and its several weeks of work to replace it with fully functional shell API integration that makes people happy.

I dropped glib; I now use the C++ object system, and export those to C when needed through trampolines. Implementing a new platform-specific class is relatively easy by just using a $PLATFORM subdirectory in src/ and telling the build system to compile those. Generic code is in src/.

I have a base framework that I created which eliminates differences in event loops, port I/O, network I/O, and GUI rendering/API access. My same API works on Linux framebuffer, X11, and Windows. Adding Cocoa to that as soon as I can, then I can add next step, gnu step, and os x to the list of supported environments. I would like to make one more component, to hide winsock2 behind a real BSD sockets interface so that I can easily use third party libraries without worrying if they've been ported to winsock. But I am currently doing just fine without it since a lot of libraries let you decouple them from the network without an issue, using in-memory buffers as the temporary placeholder.

Perhaps the biggest benefit of all, though, is the syntactic sugar you get for making objects behave as primitive scalar or array values. Operator overloading, judiciously used, saves me a lot of time and helps me to reduce duplication and typing, without sacrificing ease of reading or adding tons of runtime bloat. The fact that one can choose to make it an inline or a true method call is nice, too.

Well, that and the fact that I can do cross platform development without thinking about platform quirks anymore. Holy crap that is nice. I don't have to worry if I am poll()ing file descriptors or using MsgWaitForMultipleObjects() on a set of HANDLEs: I just have an EventSource and EventLoop class which handles all that for me.

POSIX AIO vs NT overlapped I/O? Ain't gotta worry about that, either. Or threads. Or services. I do hate the way a daemon is overly complicated on windows but one little class and I can compile a daemon to behave as it should under sysvinit, systemd, or windows.

And don't get me started on serial ports! Why Microsoft took inspiration from VMS and not POSIX is beyond me. 

Sent from my iPhone

> On Aug 6, 2015, at 2:06 PM, Chris Fowler <cfowler at outpostsentinel.com> wrote:
> 
> Microsoft's idea of 'handles' motivated me to add objects to C code.  As I started using higher level languages we needed to code in I started taking time replicating their APIs in C and we use those.  ServerSocket, Socket, Vector, String, etc are ones I implemented in C libraries based on the Java doc.



More information about the Ale mailing list