Code:
Code
I’ve mentioned before that, of all of the C dialects available, Objective-C appeals most to me from the standpoint of simplicity and elegance. The language isn’t perfect but, prior to version 2.0, I found the syntax to be relatively clean and intuitive, unlike that of C++.
When examining the syntax of the language, particularly the use of bracketed statements to indicate method calls (messaging), it's easy to see that Smalltalk features were imposed on the underlying C syntax rather than being added as a natural evolution of the language -- but I’d guess that this was because the initial "compiler" for Objective-C was something closer to a pre-processor than a full-blown parser. Nevertheless, the syntax does make method calls easy to recognize in long stretches of code; and the ability to "tag" parameters also helps to clarify the purpose and use of each object.
Unfortunately, Objective-C never really caught on as a mainstream language, and Apple seems to have abandoned it in favor of a language with semantics that are closer to C++ (read: uglier, in my opinion). Much of the reluctance to use the language seems to revolve around the idea that Objective-C code can never compete with C and C++ in terms of performance: Objective-C resolves method calls (messages) to their implementations at runtime, while traditional compilers do so at compile time. In general, the former approach is supposed to provide the most flexibility in implementing of a given method, while the latter approach will provide the greatest speed. But does the flexibility offered by Objective-C actually actually penalize code execution times?
For the Apple implementation of the Objective-C runtime, the answer would appear to be "yes" -- at least, this was the case in 2003. But that was more than twenty years ago, and with the traditional Apple runtime. The question is whether the Objective-C runtime implementation presently offered by GCC suffers from the same speed penalty.
Note: This article is a work in progress.
I'm partial to C for its simplicity and power, but I prefer to work in an object-oriented mindset when I write code. I'm no fan of the hot mess is C++, however. So I was quite excited when I found Objective C a few years ago. Although from a syntactical standpoint, the language is clearly an imposition on the underlying C syntax, I think the overall effect is more intuitive and elegant than the Arcane Wizard Scrawl(TM) that C++ has become. I'd hoped to start using Objective C, by way of GCC, as my main programming language -- but their desire to keep pace with Apple's slow destruction of the language ruined those plans.
In an effort to find an alternative, I stumbled across the Portable Object Compiler. The basic syntax is the same as what Apple brought out of NeXT, except that protocols (interfaces) are not supported -- though there are ways to live without this -- and categories have to be implemented in a different fashion, albeit one that makes sense.
Intrigued, I downloaded the bootstrap compiler and compiler sources and...they didn't compile on my Linux box. Continue reading...
Note: I cannot guarantee that any of the links to Microsoft documents which appear in the following article will continue to work, only that they worked when this article was written. Microsoft's documentation pages appear to move around entirely at the whims of madmen, and a link that works today may result in a 404 error tomorrow. Now you know what your favorite search engine is for.
I was recently asked to determine why a group of machines at work were running slowly. The machines in question exist in a shared environment and are used by multiple individuals throughout the course of a given day. There were a few things causing them to malfunction, but one of the more interesting issues I found was that the users were not logging off when they were finished with the machines; instead, they would walk away and the next person would simply hit "Switch User" to log into them. Therefore multiple disconnected user sessions remained in memory, many with programs still running -- and collectively, these abandoned sessions served as an anchor which weighed down the performance of the machines.
...you run into compiler bugs that prevent successfully compiling your library...
While testing some advanced features of the parsing library in preparation for the next step toward building causerie, this is exactly what happened: an obscure bug with the Free Pascal runtime that seems to defy debugging with GDB and which crashes the program every time it runs. (If you're really interested to know, it seems to have something to do with the way that TObject handles memory allocation).
It's proven to be a rather large setback for causerie, but it isn't the end of the world. I was already developing a C interface for the libraries, to make them as portable as possible, and if all else fails I can expand upon that to take the whole thing into C. I'll have more information here soon.
Previously: Writing a Command-Line Parser, Part 1
In the previous article, we defined the basic elements that are required in order to produce a parser: tokens, opcodes, the general language syntax, statements, expressions, and symbols. Tokens and opcodes are fairly similar across parser implementations, typically differing only in the types of characters allowed to be part of a token and in the data type used to represent the corresponding opcode. The next item that must be addressed, then, is the syntax of LinearC, our command-line argument "language". The syntax will inform the opcodes used and the types of statement and expression handlers we must define. It will also help the tokenizer to correctly classify the tokens read from the command line. Continue reading...
