Codeslinger

Variable types and sizes

2008-12-08T17:43:00.000-08:00

Just a random thought on variable sizes:

There's an old design decision for programming languages as to whether the variable size for built-in numeric types be static or dynamic. For example, the .NET framework has static sizes: every type in the System namespace (which are all the built-in types) has a size associated with it, eg: Int32. Conversely, in C/C++, int is of dynamic size, dependent on the compiler and the target environment.

There are arguments for both. On the static size, you have deterministic size, so you can predict exactly what values will/won't fit. On the dynamic side, you can automatically use the size which is appropriate for the architecture, which gives you automatic adaptability to architectures with new intrinsic data sizes (eg: 32bit -> 64bit) without speed degradation from extra operations to adapt non-standard variable sizes.

With those trade-offs in mind, I'd propose a new? thought for variable declarations: a concept of "at least" x bits. This would give you the best of both worlds: you could say with certainty that values within a target range would fit in your variable, while allowing the compiler to allocate a larger type if that was more optimal for the target architecture. You would sacrifice predictability of variable size, but you could still use fixed-size constructs as a fallback if you needed them.

With that in mind, variable declarations might look like:

int32p i32bitOrLargerValue;
int64p i64bitOrLargerValue;

... where the 'p' is for 'plus'.

Just a thought.

The enormous problem with highly dynamic languages

2008-11-13T11:50:00.000-08:00

So you're moving from an "old-school" language like C/C++ into a "new hotness" language like C#, and life is so much easier. Memory management is automatic, type information is part of the runtime, everything is dynamic. You can create these very simple expression to perform very complex operations, all auto-magically, and rapidly prototype applications like never before. Life is great, right?

Well, there's a small problem which is the 800lb gorilla in the ideology. See, there's two parts to a language enabling you to writing code which does what you want: letting you express what you want to do, and helping you not express what you didn't want to do. The former is aided by higher level abstractions, patterns, powerful expression syntax, API libraries, etc. The latter is aided by strong compile-time checking, API/structure transparency, clear and predictable behavior, etc. A good language balances both of these.

The problem with low-level languages is that they have a lot of the latter, without much of the former. The problem with highly dynamic languages is that they have a lot of the former, at the expense of the latter. The big problem with languages lacking the latter is that lacking the former just slows you down, whereas lacking the latter makes your applications fundamentally less reliable and more prone to subtle systemic problems. The huge problem is that there's no way around that problem: no matter how clean your structure and methodologies, you're always forced to perform runtime verification, and it's nearly impossible to eliminate systemic errors because the runtime implementation is so convoluted and obtuse.

I would not be surprised if we see a resurgence of "native" code development because of these issues, because they are so fundamentally intractable in dynamic languages. I know I shutter to think of trying to build a reliable .NET application of any meaningful complexity. We shall see.

Fun with COM interop

2008-10-22T15:34:00.000-07:00

So I have a C# object which exposes a COM interface through interop, and it was working. Then I did something, and when I went to reload it, it said the component was not registered. I confirmed that the ProgID was in the registry, and everything appeared to be good.

... It turns out that if the constructor for an object which is being constructed for a COM object instantiation throws an exception, the CoCreateInstance call will return that the component is not registered. This is not normally a problem with native C++ COM objects, since they run the constructor code as part of the registration process, so you'd catch the error earlier. However, C# COM object apparently do not, and the error coming from COM is very misleading.

Just an interesting tidbit for COM interop.

Bizarre error of the day

2008-10-06T13:58:00.000-07:00

So I'm playing with compiling something which is C++/CLI using /clr, and ran across an error while trying to run:
'Could not load file or assembly' of my exe itself!

So to make a long story short, after some research, it turns out that:
- The .NET framework cannot load assemblies which have more than 65k global symbols defined
- Every static string in the code apparently is assigned its own global symbol when compiling with /clr

The solution, equally bizarre, is to enable string pooling for the Debug build of the exe. This reduces the amount of static strings dramatically, which allows the assembly to load, and the program to run. Talk about a random issue.

Oh, and obligatory "yeah, C++/CLI is ready for real world apps...".

COM attributes, C++, and MS's fail

2007-10-15T11:33:00.000-07:00

Attributes... simplified programming model, hides the complexity of COM, allows easy specification without obscure syntax, must be a good idea, right? Nope, FAIL.

The problem lies in the failure of documentation and ubiquitous support for the other MS libraries. Specifically, are you using MFC (and really, most native C++ Windows programmers probably are, duh)? Sorry, attributing breaks your application. Not that you could tell, since converting to attributed leaves all the other files in the project, and creates new hidden files with the current interfaces. Um... UTTER FAIL.

Not to mention the attributes themselves. How do they work? Oh, don't worry about that. Where can I see the source? You can't, it's compiled into DLL's which inject it. How can I see what it's generating? Compile with a special flag, and look for the hidden, undocumented files it might generate. How can I debug issues? Um... online support forums maybe? UTTER FAIL.

Nothing pisses off native developers like not being able to see what's going on. Over 50% of why people stay native developers is a lack of faith in the ability to diagnose and fix problems because the lower level code will be too hidden to figure out what's going on. What could be better to convince these developers to go managed than introduce some managed-like syntax and show how easy things could be? Except the syntax (attributes) exemplifies the exact reasons why those programmers haven't adopted managed code, and solidifies their decision to stay native as the correct one. Two words for MS: UTTER FAIL.

I'm done with attributes for COM objects. Yes, IDL and ATL are hideous, but gobs of hard to read code is better than not being able to fix problems or understand what's going on. You can take that as a free mantra whenever you take the next pass at trying to convert native developers to the next big thing.

Xtreme Toolkit's TaskPanel

2007-07-24T10:43:00.001-07:00

So Codejock has done what I thought someone should do, make a generic, all Windows versions version of the Task Dialog. It's not perfect (points off for putting your copy of the structure definitions in effectively the global namespace), but it's pretty good.

Bootstrapper for installs is cool

2007-07-09T13:32:00.000-07:00

This is cool:

http://msdn.microsoft.com/msdnmag/issues/04/10/bootstrapper/
http://blogs.msdn.com/chrsmith/rss_tag_Bootstrapper+awesomeness.xml

Basically, it's a installer builder for Visual Studio with which you can set dependencies on other modules, which are packaged for the bootstrapper (eg: versions of the .NET framework). When your installer runs, the bootstrapper will verify the installation of the component (including version) you need, and if it's not present, automatically download and install it, before your installer even runs.

What's cool about it (versus just packaging in the MSI's for the dependent components) is that you don't bloat your installer very much (bootstrapper is about 500k), but you get virtually the same effect, due to auto-downloading. Very cool.

Some people are dumb

2007-07-06T11:31:00.000-07:00

So the /. FotD is bashing on the MS proclamation that their vouchers for Novell to distribute linux do not entitle the redeemer to any software licensed under GPLv3. For reference, see:

http://www.microsoft.com/presspass/misc/07-05statement.mspx
http://linux.slashdot.org/article.pl?sid=07/07/06/1333257

Now for their part, MS is being fairly smart. The recognize that GPLv3 is crafted to screw them, and are trying to preemptively disclaim any distribution of GPLv3 code. Basically, if you get linux with a MS voucher, your not getting the right to use anything licensed under GPLv3; a perfectly valid condition to impose.

Enter the dumb zealots, claiming that this is tantamount to MS declaring the law itself invalid by fiat. It's kinda like the fanatics who don't understand that their religion is opposed to killing people... have you guys even read the GPL, or is it just the magic anti-Microsoft golden idol in your minds?

MS doesn't want to distribute GPLv3 code, cause GPLv3's patent provisions are counter to everything MS wants to preserve with their IP (on purpose). They cannot be forced to distribute GPLv3 code; the law just doesn't work that way, as much as the zealots at FSF would like to change it by fiat.

Breaking polymorphism with templates

2007-07-05T17:28:00.001-07:00

Intriguing title, huh?

So here's the issue. Say I want to have a collection of objects, each of which is an instance of a template class (with various template types). Not going to work, you say, cause each template typed version of the object is a different type, and you can't have a collection of different types, unless they are derived from a base type. Fine, no problem, I can have a non-templated base type as the pointer type for the list; something like this simplified example code. Now the fun starts...

class CBaseClass
{
public:
virtual ~CBaseClass();
};

template< typename TYPE >
class CSubClass : public CBaseClass
{
public:
TYPE m_tValue;
};

Say I want to get the value from an element in the list, where the type of the value is the template type of the subclass of the actual object instance. Simple enough conceptually, but wait... there's an issue. Iterating the list give me pointers to the base class, and I need to call a method which is explicitly or implicitly aware of the subclass type. And here we come to the quintessential example for polymorphism: CShape, CSquare, virtual void Draw(), etc.

So I just add a virtual method, specify the type I want to get out as a template parameter, override it in the subclass, return m_tValue, and we're done, right? Something like this, for example:

class CBaseClass
{
public:
    virtual ~CBaseClass();

    template< typename TYPE >
    virtual TYPE GetValue() = 0;
};

bool bHappy = pBaseClass->GetValue< bool >();

Um... see, here's where C++ is kinda broken. You can't have a template virtual method, it's not allowed.

... So how can we get m_tValue, when all we have is a CBaseClass*?

Coding gymnastics, using RTTI, explicit type lists, a whole crap load of ugly, runtime-check-only template code, and very limited extensibility / flexibility. Basically, breaking the whole point of templates and polymorphism. Seriously, the code is simpler if you have one class with a void*, a size, and an enum for the type in it, and you forget about virtual functions, templates, or anything fancy designed to eliminate the need for void*'s, sizes, and explicit runtime type storage.

Somebody in the C++ committee should seriously look at this, figure out a good solution, and fix the standard, cause it's broken.

Microsoft API's blow sometimes

2007-07-05T17:27:00.001-07:00

So I'm calling UpdateLayeredWindow to do transparency effects, and it's failing with no error code set. Turns out it seems to be an issue with running the app through Terminal Services. Would have been nice for Microsoft to actually produce a useful error code, like, say, I dunno, "this API is broken with Terminal Services cause our coders didn't finish it" or something. Kinda like the multi-threaded apartment version of the IShell interface in Windows XP (oops, we ran out of time, sorry).

Seriously, people... documentation, it's what makes a platform usable for developers.