No computer stuff today; since I am actually in Hungary today on business and it is the the anniversary of the happy event mentioned below, today’s FAIC is a rerun. Enjoy!
I’m back from my fabulous adventures in Austria, Romania and Canada and I had a fabulous time, as you might imagine. We were in Romania for a wedding of some close personal friends who live here in Seattle; much of the groom’s family escaped from Romania during the Communist period and settled in Austria, so we spent some time in Vienna and then headed to Bucharest, and then crossed the Carpathian mountains by bus into Transylvania for the wedding. Some of the highlights included:
One of the questions I’m asked frequently regarding design of C# classes is “should this be a property or a method?” Here are my guidelines:
A lot of questions I see in the C tag on StackOverflow are from beginners who have never been taught the fundamental rules of pointers. (I note that these rules apply to C# as well, though it is rare to use raw pointers in C#.) A lot of introductions to pointers get caught up on the implementation details of what pointers are for a particular compiler targeting a particular architecture, so I want to be a bit more abstract than that. So, without further ado, here are the fundamentals: Continue reading
For a change of page, today on the Coverity Development Testing Blog’s continuing series Ask The Bug Guys I’ll talk about mostly C and C++, with a little Java and C# thrown in at the end. I’ll discuss a very common question I see on StackOverflow in the “C” and “C++” tags: “here’s a clearly buggy program that I wrote; why does it not AV / segfault / crash when I run it?” Check it out! Continue reading
Last time on FAIC I described how language designers and compiler writers use “lowering” to transform a high-level program written in a particular language into a lower-level program written using simpler features of the same language. Did you notice what this technique presupposes? To illustrate, let’s take a look at a line of the C# specification:
e as T produces the same result as
e is T ? (T)(e) : (T)null except that
e is only evaluated once.
This seems bizarre; why does the specification say that a higher-level operation is exactly the same as a lower-level operation, except that it isn’t? Because there is no way to express the exact semantics of
as in legal C# in any lowered form! The feature “evaluate a subexpression to produce its side effects and value once and then use that value several times throughout its containing expression” does not exist in C#, so the specification is forced to describe the lowering in this imprecise and roundabout way.
A nice principle of programming language design that C# does not adhere to is that all the higher-level features of the program can be expressed as lower-level features. Why is this nice to have? Well, not only is it a big convenience for writers of the specification, it also is a big convenience for writers of language analyzers. If you can programmatically transform a high-level language into an exactly equivalent program in a language with far fewer complicated concepts then your analyzer gets simpler. Continue reading