Say you want to aggregate a list of ints.

var s = new int[] {1, 2, 3};
int sum = ints.Aggregate((a,b) => a + b);


This works great if your list has elements in it, or they aren’t filtered out in a where clause. Say you had a function that took a list of ints and someone passed that list of 1,2,3 to your function:

int SumOverTen(IEnumerable<int> ints)
{
int agg = ints.Where(i => i > 10).Aggregate((a,b)=> a+b);
return agg;
}

Everything now goes pear-shaped and you get an InvalidOperationException “Sequence contains no elements”.

So what do you do to fix this? You could rewrite your function to check for an empty result first:

int SumOverTen(IEnumerable<int> ints)
{
int agg = 0;
var bigints = ints.Where(i => i > 10);
if(bigints.Count() > 0)
agg = bigints.Aggregate((a,b)=> a+b);

return agg;
}

This makes a nice Linq expression into a nasty branching mess. The list will now be enumerated twice, once for Count and once for Aggregate.

Well, it turns out that there is a better way, using Linq:

int SumOverTen(IEnumerable<int> ints)
{
int agg = ints.Where(i => i > 10)
.DefaultIfEmpty()
.Aggregate((a,b)=> a+b);

return agg;
}

This results in the same value as the previous function but is much more legible and throws no exceptions on an empty list. However, I don’t know how DefaultIfEmpty checks for an empty list so it may not be more efficient than the previous code.

What I want to know is, why does Aggregate throw instead of returning the same result as using DefaultIfEmpty?

I’m going to take a look at one of those issues here, and that is using System::String with native functions. The Win32 API is one such body of native functions and they fairly consistently take LPTCHAR parameters for strings. This type is a typedef to TCHAR*, TCHAR in turn is a typedef to wchar_t for Unicode builds and char otherwise.

Toll-free bridge with CString

One easy and automatic way to do this conversion is to bridge it through CString, this is a type that is part of Microsoft’s ATL. I believe it was first part of MFC but it’s since been divorced from depending on the rest of MFC and even the ATL proper or it’s server classes; include atlstr.h instead of cstringt.h.

The char type of CString is internally based on TCHAR as well, so depending on if you are doing a Unicode build the internal representation of the CString will be either wchar_t or char. The CLI has no such type differentiation, String is always a wide character string. This means that in Unicode builds we don’t need to do a conversion, but non-Unicode builds will, and CString takes care of this for us through it’s helpfull conversion constructor that accepts a System::String^.


template <class SystemString>
CStringT( SystemString^ pString ) :
CThisSimpleString( StringTraits::GetDefaultManager() )
{
cli::pin_ptr<const System::Char> pChar = PtrToStringChars( pString );
const wchar_t *psz = pChar;
*this = psz;
}


`PtrToStringChars` retrieves a pointer to the String’s internal memory buffer, no copy here. The pointer returned is then pinned so that the Garbage Collector will not move it while we use it. It then uses an implicit conversion to go from `pin_ptr<const System::Char>` to `const wchar_t*`. Finally it uses the copy assignment operator of CString (which delegates to a base class operator) to copy the contents of the String buffer into itself. In a Unicode build this copy assignment operator decays to a basic memory copy, otherwise a different copy assignment operator is invoked that uses WideCharToMultiByte to convert to the CStrings internal char type.


// This gets called when the right-hand-side pszSrc is the same char type as the internal storage
// It simply delegates to it's base class to copy the source buffer into itself
CStringT& operator=( _In_opt_z_ PCXSTR pszSrc )
{
CThisSimpleString::operator=( pszSrc );

static void ConvertToBaseType(_Out_cap_(nDestLength) _CharType* pszDest, _In_ int nDestLength,
_In_count_(nSrcLength) const wchar_t* pszSrc, _In_ int nSrcLength = -1) throw()
{
// nLen is in XCHARs
::WideCharToMultiByte(_AtlGetConversionACP(), 0, pszSrc, nSrcLength, pszDest, nDestLength, NULL, NULL);
}


Now we can use the CString in place of `LPCTSTR` parameter because it has a user-defined conversion operator that simply returns the guts of the CString. This automatically does-the-right-thing when calling functions in Unicode builds and non-Unicode builds, all with no #ifdefs.


operator PCXSTR() const throw()
{
return( m_pszData );
}


`PCXSTR` is a chain of typedefs that eventually, through TCHAR, finds it’s way to a `const wchar_t*`. PCXSTR means “pointer to a const null-terminated string of the same char type I am”, it also has PXSTR and XCHAR typedefs. In addition to the `X` typedefs it also has a set of `Y` typedefs (PCYSTR, PYSTR, YCHAR) that map to the opposite of the `X` typedefs, if the `X` is wchar_t then the `Y` is char. It uses the set of `Y` typedefs to create a number of copy assignment operators and conversion constructors that convert from either character type to the internal type.

Conversion to Mutlibyte UTF8

There is one problem that this doesn’t cover however, and that is how to convert your Unicode String into a `const char*` for use as parameters to functions that don’t have Unicode counterparts. Stan Lippman has a blog post from back in 2004 where he presents a couple of functions to handle this conversion to char* and to std::string. We’ll see some similarities with the CString constructors.


bool To_CharStar( String^ source, char*& target )
{
pin_ptr<const wchar_t> wch = PtrToStringChars( source );
int len = (( source->Length+1) * 2);
target = new char[ len ];
return wcstombs( target, wch, len ) != -1;
}

bool To_string( String^ source, string &target )
{
pin_ptr<const wchar_t> wch = PtrToStringChars( source );
int len = (( source->Length+1) * 2);
char *ch = new char[ len ];
bool result = wcstombs( ch, wch, len ) != -1;
target = ch;
delete ch;
return result;
}


There are a couple problems with these functions. First, they are not reentrant and hence not thread safe, wcstombs keeps a global internal state during the conversion of a string. Second, they only work with UTF-16, which String always is, but it over allocates for simple single-byte character sets like ASCII. Third, they create an unecissary temporary buffer in the case of the std::string converter. And in the case of the char* converter it put the onus of freeing the buffer on the caller, which is doubly dangerous here because since the function uses new[] to allocate the buffer, the caller needs to know to call delete[].

Lets take a whack at implementing these functions in the way of the C++ standard library while solving these deficiencies (thanks to Kniht on freenode ##C++ for helping me distill this).


#include <limits.h>
#include <wchar.h>
#include <algorithm>
#include <stdexcept>

template<class Cont>
void wcs_to_mb(Cont& c, wchar_t const* s) {
if (s) {
std::copy(s, s + wcslen(s), mb_back_inserter(c));
}
}


This code is completely standards compliant so it will work perfectly well on any standards compliant compiler/OS. In our examples however our source is a System::String and there are two targets we’re interested in, std::string and char*. We can accomplish each of these targets easily using std::copy with our custom mb_back_inserter.


template<class Cont>
void String_to_mb(Cont& c, System::String^ source) {
pin_ptr<const wchar_t> wch = ::PtrToStringChars( source );
wcs_to_mb(c, wch);
}

// the vector and string are automatically deallocated leaving this scope
}


Making effective use of containers, iterators, and wcrtomb(…) we’ve created a solution that doesn’t require caller deallocation and that is reentrant.

I’ve found Jeff to be rather level-headed and analytical during discussions, Joel on the other hand is quite often disruptive. This I’ve found to be a lot like their blogs though I don’t read them often. I also see these traits surface to varying degrees through Jeff and Joel’s joint venture.

I feel that Jeff has been an exceedingly gracious proprietor of the StackOverflow community, balancing monetization of the site with respect for the well from which their success flows. The well obviously being the thousands of users that spend their time providing content and moderation for the StackOverflow site.

Visitiing the site recently — not logged in — using a family member’s computer I found that the StackOverflow site is totally different for the drive-by Googler, the advertisements are much more prominent and inline with the content. Jeff has had the presence of mind to squelch the advertising for their most loyal and content-providing users, this is brilliant and show that the Golden Rule is in full effect at StackOverflow. And why wouldn’t they do this? It is my understanding that their traffic is somewhere around 80/20% anonymous/member mix, it’s a small tradeoff in revenue to take care of their content stream to ensure it will continue to flow.

Unfortunately with their latest attempt to monetize StackOverflow it seems that Joel’s traits (as PM of the venture) have surfaced more than Jeff should allow. Being the consummate businessman, with an office in New York and a home in The Hamptons, Joel wants to monetize on the traffic and content of StackOverflow with more than advertising. Who can blame him, StackOverflow receives millions of page views a month and is ranked in the top 1000 sites on the internet.

Where else would Joel think to go than his tried and true job listing service. This is comfortable ground for Joel, for years he has been providing employers visibility to a well defined demographic of potential employees for a somewhat standard industry rate of $350 per listing. He has been able to make a good living monetizing his blog traffic for years through advertisements and these job listings and extending this service to the even more laser focused programmer demographic of StackOverflow is a no-brainer.

Up to this point the site at jobs.stackoverflow.com has basically been a mirror of the joelonoftware listing, but in true StackOverflow spirit Jeff and Joel have just recently released a much more in-depth whack at the problem of finding and hiring good developers. I think their idea is genious; leveraging the StackOverflow content and infrastructure (tags, profiles, Q&A) to allow developers to effectively cash-in on the time spent on StackOverflow to woo potential employers, and for employers to get invaluable information about developers that could never be communicated on a simple résumé.

But one word with Unicode characters wasn’t enough, so Jeff and Joel decided that developers should fill out a Curriculum Vitæ (CV) instead of a résumé. I find the distinction that they’ve made here to be refreshing and a great fit for the synergy of a developer’s passion, past experience and StackOverflow répertoire. Besides the time, filling out and publishing a public CV is a no cost proposition provided by the StackOverflow team.

Their plans for monetizing the careers site is two-fold. For the first revenue stream — like the jobs listing — there will be a subscription fee for employers to get access to search developer CVs to the tune of $500 per week up to $5000 per year. If you’ve ever tried to find and hire good developers using the standard method of newspaper/dice/monster, you know that this fee is worth every cent. A recruiting agency will charge you 10-25% of a placment’s salary to send people your way, and more often than not they just use the wet noodle approach and throw developers at you until one sticks. For someone that makes $80K it will cost you $8-20,000 for that single placement.

“So wherein does your quibble lie?” you might ask. Well, it’s in the second of the two revenue streams for the careers site, for the measly pittance of $99/year they’ve decided to throw out the baby with the bathwater. On the other side of the employer’s looking glass developers will need to pony up hard cash in order to “file” their CV to be searchable on the StackOverflow careers site. This is an affront to the content providers of their community and I can’t believe that this token filing fee is worth the bad will that it could generate.

It is done under the guise of filtering out those “who knew that they had no reasonable chance of getting a job”[1]. I think Jeff even believes this, but it’s really just an unfortunate scapegoat for making money at the expense of your content providers.

In their latest podcast Jeff was pretty adamant that the job seekers not be sortable by their StackOverflow reputation, he wants people with little or no reputation to have an equal visibility to those that do. This bodes even worse for their plan of charging job seekers to file their CV.

The kind of people that are passionate and give of their time to answer other’s questions are exactly the kind of developers that I want to hire. And these are exactly the same people that are less likely to view this filing fee in an unfavorable way. These are the kind of developers that program at home, are constantly learning new things, work on OSS projects, and are not 9-5 just-for-the-paycheck programmers. Their loyalty when treated well is often unmatched.

Then there’s the other kind of developer; you know the guy I’m talking about, the smooth talker, usually the “Team Leader”. The guy who drives his Audi to work and knows how to play the corporate game better than he knows how to cut-n-paste code from Google. Their loyalty is usually suspect and their main goal is to either climb the corporate ladder (hence team lead instead of in-the-trenches programmer) or jump ship at any time for a higher salary. StackOverflow is a godsend for these types of programmers as it’s rife with snippets free for the taking.

If their goal was to vet potential job seekers, to provide more value to employers, then money is definitely not the way to do it. Even the “smart hiring managers”[1] will have a hard time filtering out these smooth talkers that are always on the market for the highest bidder. These are exactly the people these “smart hiring managers” don’t want, it is expensive to bring people into a company just to have them bail 60 days later.

At my current job we really, really need some talented developers, and there are 5 job seekers on careers in our area. The Salt Lake job market is a small world, I’m sure that I know a third of the people on the list and that’s what scares me; I know a lot of smooth talking “Team Leaders”. With the current criteria to entry I don’t think I can justify finding out who they are for $500.

So in effect Jeff and Joel have ignored they’re best formula for vetting job seekers and instead have opened the doors for anyone who is willing to pay $99/year. If they were really hard up to make money through this channel they could easily provide free filing for anyone who has generated over X reputation on the site in the last rolling year. Similar to their banner advertising this serves the 80% of people who are willing to pay $99 and pays respect to the 20% truly exceptional developers who they owe the success of their site.

Jeff, please doff the cybernetic business suit!

1. http://careers.stackoverflow.com/faq#pricing

To install Subclipse in Eclipse goto the Help menu and choose “Software Updates…”.

Once the “Software Updates and Add-ons” window displays itself we need to add the Subclipse update URL. Choose the “Available Software” tab, click “Add Site” and put in “http://subclipse.tigris.org/update_1.6.x” as the location and click “OK”.

You will now see a new item in the list corresponding to the URL that you just added. Now to add subclipse you need to choose two plugins, subclipse itself and the JavaHL. JavaHL is the API that subclipse uses to talk to your SVN server. You can find these by expanding the tree by clicking the triangle to the left of the URL you just added, and then expanding the Subclipse subnode. After selecting the plugins click install and follow the dialogs through to the end.

Now that subclipse is installed, in the top right of Eclipse click the “Open Perspective” icon choose “Other” and choose “SVN Repository Exploring”, this perspective will give you the tools to work with your SVN repo, assuming you aren’t already happily using a tool like TortoiseSVN or the command line client to do so.

Add your repo location to the SVN perspecitve by clicking the icon at the top right of the repositories view and typing in the URL of your repo. Any repositories added here will also show up in other dialogs when working with SVN in Eclipse such as when adding or importing projects.

Adding Your Project to the SVN Repository

To add a project to SVN go back to your development perspective and simply right click on the project in the “Project Explorer”, expand the “Team” subitem and choose “Share Project…”. Now choose what repository to add your project to, click Next.

Now you will be prompted to choose a folder name for your project in the repo; you can just use the name of the project or specify some folder further down in your repository hierarchy, click Next.

The wizard will now ask for an initial commit comment, click Finish and your project will be created in the repo, but you will still need to commit your changes for the code to actually show up in SVN.

Once you clicked Finish Eclipse will ask if you want to open the “Team Synchronizing” perspective. Click yes and once the perspective opens you can simply right click on the root project node and choose commit. You can also do commits from the SVN perspective, or in your development perspective the project right-click menu now has a bunch of SCM options under the Team submenu.

At this point working with SVN in Eclipse is like working with any SCM tool, make changes, commit changes, rinse, repeat.

Importing a Project from SVN

There may be a project in an SVN repo that you want to import, this is fairly simple. Open the workspace that you want to import the project into. Goto “File” and choose “Import”. Expand SVN in the tree and choose “Checkout Project from SVN”, click Next.

This next dialog lets you choose from which SVN location to pull the project, if you have already added a repo location in the SVN repo perspective it will show on the dialog, otherwise you can specify the location now, click Next. You will now be shown a list of folders on your repository, you can navigate them and click the folder that you’d like to import, click Next.

The next window asks how you would like to setup the local project, including a name and which version to pull. The defaults should usually suffice unless you want to maybe pull and older version or a branch to work on, click Next.

The next dialog simply lets you import to a different workspace than the one you currently have mounted. You should already be in the workspace you want to import to so just click finish. The import process will take a moment after which you should see a new project in your workspace.

Congratulations, you’ve successfully imported the project and since it is bound to SVN you can now work on the code with your coworkers!