Posts Tagged "programming"

Visual Studio 2005 Threading Woes

Published on August 17, 2008

Visual Studio 2005 introduced support for doing parallel builds in solutions that contain more than one project. This is a great idea, especially on systems equipped with multi-core processors. Unfortunately, the developers at Microsoft apparently don’t know how to program a multi-threaded application.

Suppose we’re building two projects within one solution, call them Project A and Project B. If A and B exist in completely different folders, and are mutually exclusive in every way possible, the parallel build option is quite handy (improved build performance). However, if projects A and B share any code, any code at all, you run the risk of build failures. It seems as though Visual Studio doesn’t lock files appropriately during the build process. So, if each instance of the compiler tries to build the same file at the same time, one of them will fall over and die, complaining that “no class instances were found.”

It’s shocking to me that something so seemingly simple could be broken in an application of this caliber.

Default Startup Projects in VS 2005

Published on July 28, 2008

I ran across another weird and subtle bug in Visual Studio 2005. If you’ve got a solution with many project in it, you can set one of those projects to be the default project at startup (i.e. when you open the solution file). But this setting apparently resides in the user options file (.suo), which is something we don’t keep in our code repository (since it differs for every user). So how can you set a default startup project that affects anyone working with your code? Simple: hack the solution file.

Thankfully, the solution file is just plain text. Apparently, if there’s no user options file for a given solution, Visual Studio 2005 simply selects the first project it comes across in the solution file. Here’s a quick example of what a solution file looks like (wrapped lines marked with »):

Read the rest of this entry »

Troubleshooting VS 2005 DLL Issues

Published on July 24, 2008

Recently at work, I spent a fair amount of time debugging some strange run-time errors in one of our test tools (after having ported it from Visual Studio 2003 to VS 2005). When starting up a debug build of the tool, I would get the following error message:

An application has made an attempt to load the C runtime library incorrectly. Please contact the application’s support team for more information.

This error message turned out to be a red herring, though it pointed me in the direction of the actual culprit: a circular dependency chain of debug and release versions of various Microsoft DLLs. In trying to figure out what was going wrong, I ran across an incredibly helpful article on troubleshooting these kinds of issues. The author presents seven different scenarios that can arise with executables built in Visual Studio 2005, along with solutions for each one. It’s a great resource to have if you run into these kinds of problems.

Exiting Batch File Contexts

Published on May 22, 2008

While working on a Windows batch script earlier today, I ran across an interesting side effect of the call and exit commands. Let’s take this simple example, which we’ll name script_a.bat:

@echo off
SETLOCAL

call :function
cd %SOME_PATH%

goto :functionEnd
:function
    set foobar=1
    if "%foobar%" == "1" exit /B 1
    goto :EOF
:functionEnd

Read the rest of this entry »

Be Careful With Foreach

Published on March 3, 2008

I ran into an interesting side-effect with the foreach loop in Perl today. I’m surprised that I haven’t hit this before, but it may be a subtle enough issue that it only pops up under the right circumstances. Here’s a sample program that we’ll use as an example:

#!/usr/bin/perl
use strict;
use warnings;

my @array = ("Test NUM", "Line NUM", "Part NUM");

for (my $i=0; $i < 3; $i++)
{
    foreach (@array)
    {
        s/NUM/$i/;
        print "$_\n";
    }
    print "------\n";
}

What should the output for this little script look like? Here’s what I assumed it would be:

Read the rest of this entry »

Creating Cookies in Perl

Published on February 18, 2008

A little over a year ago, I inherited a productivity tool at work that allows users to enter weekly status reports for various products in our division. The tool is web-based and is written entirely in Perl. One of the mangers who uses this tool recently suggested a new feature, and I decided to implement it using cookies. Having never implemented cookies from a programming perspective, I was new to the subject and had to do some research on how to do it in Perl. It turns out to be quite easy, so I figured I would share my newfound knowledge:

Read the rest of this entry »

Perl 5.10

Published on February 11, 2008

I just found out about Perl 5.10, which has been out for some time now (released on December 18 … how did I miss this?). The perldelta documentation goes into detail on what’s new, but here’s a brief overview of some of the features I find most appealing:

Read the rest of this entry »

A Perl Module Primer

Published on August 18, 2007

I’ve recently been wrangling with some Perl code for a project at work, and have been putting together a Perl module that includes a number of common functions that I need. As such, I had to remind myself how to create a Perl module. During my initial development, I ran into a number of problems, but I eventually worked through all of them. In the hopes of helping myself remember how to do this, and to help any other burgeoning Perl developers, I’ve written the following little guide. Hopefully it will help shed some light on this subject.

Read the rest of this entry »

Understanding Prepared Statements

Published on January 15, 2007

While working on my rewrite of Monkey Album, I ran into an interesting programming dilemma. In the past week or so, I’ve been introduced to the MySQLi extension in PHP. The current Monkey Album implementation makes use of the PHP 4 mysql_*() calls, so I thought I’d try out the MySQLi interface to see how it works.

MySQLi includes support for what are known as “prepared statements” (only available in MySQL 4.1 and later). A prepared statement basically gives you three advantages: (1) SQL logic is separated from the data being supplied, (2) incoming data is sanitized for you which increases security, and (3) performance is increased, since a given statement only needs to be parsed a single time.

It seems to me that the performance benefit can only be seen in situations where the query is executed multiple times (in a loop, for example). In fact, an article on prepared statements confirms this suspicion; the author in fact mentions that prepared statements can be slower for queries executed only once.

So here’s the problem I face: the queries that get executed in Monkey Album are, for the most part, only ever executed once. So, do I make use of prepared statements just to get the security benefit? It doesn’t seem worth it to me, since I can get the same security by escaping all user input (something I already do today). Does someone with more knowledge of this stuff have an opinion? If so, please share it.

Fun With Linux Development

Published on July 20, 2006

After graduating from school with a bachelor’s degree of computer science, I must admit that I knew virtually nothing about developing *NIX based applications (that’s UNIX / Linux based applications for the non-geeks out there). Granted, I did do a little bit of non-Windows based programming while in school, but it was always incredibly basic stuff: compiling one or two source files, or occasionally writing a make-file for larger projects (three or four source files). Having never had a Linux or UNIX box to play with outside of school, I just never got a chance to get my feet wet. Thankfully, my job at IBM has changed that.

Over the past few weeks, I’ve been doing a great deal of Linux programming, thanks to the cross-“platformedness” of one of the projects I’m working on. And this project is way more complicated than your typical school assignment. I’m now horsing around dynamically linked libraries, also known as “shared objects” in Linux land, like nobody’s business. Not only that, the project itself is essentially a multi-threaded shared object, making it all the more exciting. I’ve learned more about g++, ld, and ldd in the past few weeks than I ever knew before.

Unfortunately, debugging multi-threaded shared objects is easier said than done. The debugging tools in Linux (at least the ones I’ve played with) all suck so horribly. They make you really appreciate the level of quality in Microsoft’s Visual Studio debugger, or better yet, in WinDBG (this thing is hard core, and it’s what the MS developers actually use in practice). Fortunately, printf() always saves the day.

One cool trick I recently employed to debug a library loading problem I was having, is the LD_DEBUG environment variable. If you set LD_DEBUG to a value of versions, the Linux dynamic linker will print all of the version dependencies for each library used for a given command. If you have a Linux box, try it out. Set the LD_DEBUG environment variable, then do an ls. You’ll be amazed at the number of libraries that such a simple command involves.

Although Linux development can be frustrating at times, I’ve already learned a great deal and consider my experiences a great success. If I come across any more useful tips (like LD_DEBUG above), I’ll try my best to post them here (as much for my sake as for yours). Until then, you’ll find me knee-deep in my Linux code. I’ve got a few more bugs to squash.

Game Development

Published on June 19, 2006

I just saw a commercial on TV for a (presumably) local college, and they touted their program by showing a bunch of “video game developers.” This motley crew of students looked no older than 20, and one girl commented “Can you believe we get paid to play games?” The people who put together this advertisement clearly understand nothing about the game development industry. I would hazard to guess that game developers spend less than 5% of their time actually playing games. Few people, if any, get paid to play games; the real glory, as well as the real money, is in development. And game development isn’t an easy task.

In college, I had the privilege to take two computer graphics courses. Both were challenging, and both gave me a new appreciation for game development. The folks who create today’s game engines are literally pushing the envelope in computer graphics. I shudder to think of how complex the math is behind games like Half-Life 2, Far Cry, and Quake 4. To think that your average college kid can do this fresh out of a no-name school is a little hard for me to believe.

Excellent Article on JavaSchools

Published on January 5, 2006

My dad pointed me to an excellent article entitled The Perils of JavaSchools. Although it’s a little lengthy, the article is an incredibly worthwhile read on why schools that teach Java as the primary programming language are, to some degree, dumbing down the future generation of computer programmers. My alma mater took this route, but I was fortunate enough to be in the class before this change was made. I picked up C++ first: both on my own (by learning Visual C++ and MFC) and in school (my first programming courses were all taught using C++). After learning the intracacies of C++, learning Java was incredibly simple (almost too simple, in fact). I believe I passed my “Java for C Programmers” course with an A+; a feat that required very little effort on my part.

Once one knows about pointers, objects in Java become rediculously easy to discuss. As does the entire programming language itself. Java is a fine programming language (it fixes a lot of the brokenness in C++), but to know C++ is to feel enabled. I can wield the mighty sword of pointers and memory management; something that many Java programmers do not, and quite possible can not, ever do. I’m not saying that Java programmers cannot become successful C++ programmers; I’m simply making the point that there are more Java programmers who cannot pick up C++ than there are C++ programmers who cannot pick up Java.

Again, I highly recommend the article. The author also has an incredibly enticing reading list, which he uses to train managers in his company. There are a number of books there that look really great. I hope to begin reading The Mythical Man Month, the masterpiece written by Fred Brooks. It’s one that I’ve been meaning to read for a long, long time.

Code Overload?

Published on August 23, 2005

Before I ever began my programming career, I had a sneaking suspicion that an abundance of coding at work would lead to decreased programming activity at home. And I fear that this is indeed becoming the case with me. I write a mixture of C++ and Perl all day long, five days a week. This level of productivity really taxes my mind, and it has recently resulted in an increase of non-computing related activity each evening. I’m reading books more often (Prince Valiant has certainly helped in that arena), and I’m watching more TV than I used to. I even occasionally go outside! Things like Googlebar Lite and my toolbar tutorial are slipping as a result. I dislike it, but my motivation for programming after 5:00 PM has dropped greatly. Weekends provide some level of salvation, but is that enough?

C++ is Broken

Published on July 11, 2005

I do a fair amount of C++ programming these days, thanks to my new career at IBM. C++ is my strongest language, and the first language I picked up when I began programming. As such, it’s fairly special to me. However, the more I time I spend with C++, the more I come to see how broken it is.

For instance, why are strings not a base type? Character arrays simply do not suffice. I am aware of the STL string class (and I make use of it), but adding on this capability after the fact seems cheap. Strings should be a first-class object, and should have all the associated operators directly available (==, +=, etc.). And regular expressions should be directly available for strings, since they are so incredibly useful. There are tons of places in my code where access to regular expressions would make my life profoundly simple. For example, take Perl’s match operator (m//). How many Perl programs out there do not make use of this operator? My guess is that the number is very low. It’s no different in C++; reg-exes could be used all over the place.

Other glaring omissions also crop up. Where is the foreach loop construct? Why use #include instead of packages or modules? Where are the array operators (shift, unshift, pop, push)?

There’s no question that C++ is a robust language. It’s fast, gives the programmer complete control (both a blessing and a curse), and it has an incredible user base (which results in excellent support when you need it). But it’s clearly dated. Will we still hold on to this language in 20 years? Or will something innovative finally come along to push it aside? Let’s hope for the latter.

Copyright © 2004-2018 Jonah Bishop. Hosted by DreamHost.