Stefan Says

2. LIGHTWEIGHT
Ok I said debugging pure C++ code etc is more lightweight. Not sure why but that's my experience. However, more important when talking overhead, the C++ generated EXE will be more lightweight. A C++ exe file will most certainly use less memory. It will also start up faster. I've heard/read some posts andf articles stating that "there will be a slight delay/overhead" when firing up a .NET exe file bla bla. Well, my experience says it's not that small. And there could be large consequences. Say you have an app being called 10 times a second - I talk more about that in the conslusions. Also, memory usage. Have you ever wondered about why your PC of today (which, technically speaking is countless times faster than the one you used 8 years ago) still feels pretty much like it did back then. All apps consumes more and more memory.

I remember when I put pride in delivering the smallest possible exe file, linking to a mimimal crt library cause the standard one was soo "bulky", at least 20KB could be stripped or whatever the numbers were...    I have some more meaningless numbers: I took a small console app I had in C# and started it up and looked up used memory in task manager. 27000KB. Rewrote it in C++. Exact the same inpout/output. It took 7000KB. 

3. PERFORMANCE
Ok. This is controversial. If I say something general like "C++ in faster than C#", I know people will say things like "it's not true, C# compiles to machine code as well". And I know all that. My point is that the framework classes does contain a lot of  (sometimes unnecessery) code, for error checking etc...There's also code and time delay involved when talking garbage collecting etc. Not saying  that's bad (in most cases it's good, I mean I do have it on #4 for reasons to use C# instead of C++). But from a pure performance perspective the freedom of pointers and things like pointer aritmetics etc in C++ is a big plus. However of course, also to consider is that in the "real" world, slow actual code execution is seldom a problem - whenever I need to do some optimization for my own/other peoples code, database access/correct indexing etc is always where I start. Nontheless there *are* areas where code execution speed really matters.

4. THERE ARE LOTS OF GREAT LIBRARIES AVAILABLE
Say you want to do some image handling. From C++ you'll have full and quickest access to ImageMagick dlls. I was also pleased to see (since I am now a complete MySQL geek) : mysqlpp.
Code like:

 CFoo *pRes;
 try
 {      
  mysqlpp::Connection conn("db", "localhost", "root", "whatever");
  mysqlpp::Query query(&conn);
  query << "select * from foo where bar='" << szUrl << "'";
   if (mysqlpp::UseQueryResult res = query.use())
   {
   if ( mysqlpp::Row row = res.fetch_row())
   {
    pRes = new CFoo(row);
   }

   }

  return pRes;
 }
 catch (const mysqlpp::BadQuery& er)
 {
  // Handle any query errors
  std::cerr << "Query error: " << er.what() << std::endl;
 }

And where CFoo is defined as (thanks to preprocessor)

sql_create_3(CFoo,
    1, 0,
    mysqlpp::sql_int_unsigned, id,
    mysqlpp::sql_datetime, createdate,
    mysqlpp::sql_varchar, bar
 );

I can live with code like that!

Also there is boost libraries as well of course.  Only problem with those is they are developed by guys a million times smarter than me. It does take some time to figure it out how to use it. For example I was struggling for hours with understanding the program options library, but when I did get it to work I found out that, hey, I can use config files and have them overridden by command line if I want to.   

5. NATIVE WIN32 APIs
Must be a plus for some, a minus for other. For me its a plus since I have my roots in the world of Win32 system programming. I still have trouble with the semaphore/mutexes etc in .NET but as I said, that's just because I nowadays use them rarely and I am no used to the raw APIs.

And 5 reasons I wanna use C# instead of C++...

1. ONE UNIFIED ENVIRONMENT
Whether it's a website (asp.net), console app, Windows GUI app for even a Windows Service. All done with the same programming language in the same IDE. That's the main reason I have been able to stay in the C# line for seven years or so without complaining.

2. LINQ
Still just starting out, but the elegance of LINQ code is just remarkable. Now, I would point out that I would never go as far as using LINQ to SQL (the day I leave control over how SQL is constructed and exactly when a statement is executed will
*never* happen. My own handcoded sql generator is good enough, at least for me and my modest projects). But LINQ to objects - any day of the week, and LINQ to DataSet - sure!

3. DLL, LINKING, INCLUDEFILES.
no dll hell. I mean in the C++ world: include header files/linking/. Setting paths here and there in the settings. Dont link your debug version with a third party release version etc...Also things like forward declarations etc : I think I'd go so far and say that C# as a programming language is superiour than C++. Also the whole development process as a whole is a lot more easier.

4. POINTERS, MEMORY, GARBAGE COLLECTING
Speed comes with a cost. In 99 percent of the time I choose convinience over speed. I remember in the middle of 1990, when pointer faults (especially when debugging in VC 1.52) caused the whole Win3.11 box to reboot. I'd say 80 percent of my time in this first C++ project in seven or so years was spent dealing with pointers due to me being so rusty with them. And reading up on the third party dlls I used - i.e who allocates memory, who frees it.

5. DEVELOPMENT TIME
Harddisk space is cheap. Memory is relatively cheap. Development time is what costs. Of course I understand that's the main reason frameworks and apps can keep getting bulkier and bulkier. As I say, I use the .NET framework for *everything* to the point I couldn't even remember the parameters to fopen/frwite etc. C# is in my eyes the programming best language ever,  .NET framework IS convinient and with the additions like LINQ etc it's FANTASTIC.

CONCLUSION
So, whats the point with this post? Well, basically none I guess :). No seriously I am saying that I had forgot the positive sides of C++. And I now found that there is indeed room for it as well. I might look into the Managed C++ soon, cause if I am not wrong I think it's possible to lazy load the .NET dlls. Cause while I have found that there are a lot of free C++ classes floating around, I still have some C# code I simply can't find an equivalent of. Not to talk about all my existing "business objects" codebase.

Another idea of C++/C# marriage, which I even already have implemented in another smaller project, is to have a C++ exe signal (through a file or whatever) to a C# program. Here I was faced with a third pary app which had to interface with my own (.NET) code. The only way it could do it was by calling an external exefile. It could be called maybe 10 times a second, so I really didn't want the .NET framework process overhead. Solution was to create a C# exe constantly running (could/should be a service of course) waiting for a file in a certain directory. Always running is the key here.
I then created a small C++ exefile which was the one being called from the third party app. Lean/small app, low overhead, all it does is signal to the C# app through the file. So the C# app does all the work using my existing classes and code, and returns back through another file. And my C++ exe then exits - returns to the external app.

Anyway: considering my last talk about MySQL vs MSSQL and the fact that I decided to choose MySQL sure deserves a followup. I will tell you how it's working out for me.

I will also talk some about where I'm heading with regards to development, cause while .NET will continue to be my platform I am not sure MS and Visual Studio will be.

Anyway lets start with an update on databases and database management tools. MySQL is simply looking better and better to me each single day. Performance is pretty amazing. Had some full text indexing issues which basically comes from the fact that MySQL only uses one single index per query when it comes to optimization. In short I wanted to do a where matches(...) and anothercol=somevalue. Actually it was even worse, it was a join with another table and it basically had my 2 million record first table being table scanned even though I did have an index on anothercol.  But it was easily solved by adding the information joined in into the full text index . Makes update and inserts a somewhat slower but in the end that doesn't matter.

As for the administration tools: Of highest importance for me is,an admin tool needs to start up ASAP. And I mean *A*S*A*P*.  To be honest, I feel happy every day I *DONT* need to fire up SQL Server Management Studio. Since I have some clients running SQL 2000 I do need to run SQL 2000 Enterprise Manager and I feel ok with that. It loads up quickly and feels "light" and responsive. And Management Studio simply doesn't. 

Cause lets face it. I am a developer. I understand MS is going for the slick look when it comes to OS (Vista glass gui etc) but when it comes to development and management, my opinion is MS should focus to improve performance and load time for each version. Not adding slick GUI features and stuff making it slower and slower.

With SQLYog on the other hand, I mean, I can't even blink before the GUI is up.  

Now lets turn to IDE. I have been a fan and practically lived in Visual Studio since VS 97. Yes, I am that old. Actually I'm even older - even did som Visual C++ 1.52 development (maybe there are some other dinosaurs out there who knows what I'm talking about, otherwise lets just say, it was an integrated IDE for compiling 16 bit Windows apps, MFC and C++...). Must have been 1995 or so. But VS 97  was a match in heaven. I still keep all the keyboard bindings from VS 97 in my Visual Studio of today. Which by the way is VS 2005.  VS 2008??? Lets start talking about that. I honestly don't know what to do. If you had asked me 10 years ago I would probably have drewled cause "a new version, technically much better is available". But nowadays, I really feel like, will it really make my apps that better??  Cause in the end that's what matters. And the reality is - I do have VS 2003 solutions I still need to maintain. I simply can't have yet another version of VS on my box.

So what to do? Exploring other options of course. Searched for Borland C# Builder - seems to be gone, now integrated into a RAD Studio or something, gives me the feeling of another beast. So - downloaded SharpDevelop. Just a 8MB install file. I can live with that :) Took a minute to install. Opened up a Windows Forms solution I have (pretty small and simple). Compiled. Run. Set a breakpoint. Everything is WORKING!!! Simply fantastic. So lightweight, still all I need! Next - one of my ASP.NET sites. Loaded the solution. Ok, no ASP.NET visual designer. I really can live with that. Next, run. Nothing happened. "Cant start dll project" or something. Make sense, but how to fix it? Googled some and found that we need set the "Start external program" to C:\windows\Microsoft.NET\Framework\v2.0.50727\WebDev.WebServer.EXE.
I hooked up the command line arguments /Path:C:\working\systementor\sites\airengines\airengines  /port:8001 /vpath:/

And hey, it's running. Set up a breakpoint. Browsed to the page. Hey - back in debugger!!! All is working. I am amazed.
So, I will give this a serious try. I honestly mean it. Of course, so far I have opened up two simple solutions, I have one solution consisting of around 15 different projects being console apps, class dlls , Win Forms apps. If that one works I know I am home. I will report more on this, I promise.

So, tip to MS: the view of the world for us developers might not be yours. What's important is

- quick and lightweight tools and IDEs. Quick to fire up and responsive.

- small installs. It's not reasonable to spend hours and hours to install the IDE - and then database engine. Not to forget hour(s) to download first. 

 -Flexibility - in the dreamworld I could take any computer at all, and have it fixed and ready for compilation and work in just 15 minutes.
  
Cause I am moving to a Internetnet oriented architechture for all my stuff. I already keep all my sourcecode on a remote box (with SourceGear - yes it's free for a single user). I need/want to get rid of the dependence on my specific development box for compilation and code writing - and to be able to do that I simply need to be able to set up a new box in minutes, not hours.

So I will try to keep you all updated on this matter, however, kind of depends on the baby when you'll here from me next :)

+ built in full text index. I have never needed full text index until a project I entered a few months ago. I looked at getting it up and running on my SQL 2005 Express development box. However, an extra download of 250 MB was needed. I also *think*

+ paging. My favorite! This is SOOO typical a web application. Implementing paging in MSSQL is not fun at all. Getting acceptable performance out of it is possible, but coding hard to generlize and reuse.  In MySQL it's a matter of adding LIMIT X,Y to the end of the select statement. And not to talk about SQL_CALC_FOUND_ROWS. Cause typically you need to get the page of rows  but also the total number of rows, as if we were not using the limiting. Typically you do
two queries, one select count(*)... and one select * limit x,y. But with SQL_CALC_FOUND_ROWS you get that anyway.
Yes, might not be SQL standard, but I don't care. I don't get paid by creating the most standardized solution, I get paid by delivering a solution with good performance and preberable a low footprint. I have published an article on this, ASP.NET, MySQL and efficient paging.
   

You can even reduce it further - another example is this site on aircraft models http://www.aircraftdata.net. To reduce the dataset I took the liberty to split it into different subdomains - that being step 1. Then you get listings for that subset.

I will do some more investigations in this matter - cause it is very interesting and the task of creating an accessible, yet easily navigatable - yet again USEFUL - site might not be as simple as it sounds when dealing with larger data volumes.