[prog] Joel on Software: Leaky Abstractions

[Robert J. Hansen]

> I'm not sure I understand the point of this article.  Is anyone able to
> determine Joel's reason for wanting non-leaky abstraction?  I just don't
> understand what the big deal is.

Leaky abstractions ==> bugs.  

People like to think in terms of simplicity, abstraction and metaphor. 
This is wonderful, as long as whatever they're working with maps
accurately to the metaphor.  More often, there are subtle and vexing
disconnects between the metaphor and the way the code really is.

Look at strcat as an example.  In university programming classes, it's
usually described as "strcat() splices two strings together".  Okay, we
understand how splicing works, so now we know how to use strcat().  What
we aren't told, and what most people don't think about, is that strcat
has O(kN) complexity due to the stupid way C strings are handled.  It's
not as simple as a splice; the metaphor is broken in this regard.

> Concerning the example of C++ string class, I don't know the reason why
> the C++ designers didn't make it a built-in (native) type.  But my reason

They did.  It lives in the std:: namespace, which is where almost all of
C++'s native classes live.

They didn't make literal strings objects of the std::string class for
purposes of backwards compatibility with legacy C code.  That's also why
you can use a char* to store a string in C++, even though C++ says const
char* ought be used instead.

The weird string literal behavior you have here exists as part of C++'s
C legacy, by the by--it's not a C++-ism.

#include <stdio.h>

int main(void)
{
  printf("%s", "Hello " "World!" "\n");
  return 0;
}


-- 
Robert J. Hansen <rjh at sixdemonbag.org>