The Daily WTF: Curious Perversions in Information Technology

dubwai · 2005-09-22 Reply Admin

Otto:

dubwai:
I'm not sure what you are getting at here. 'String' is a programming abstraction as is 'character array'. What does that have to do with hardware?

A character array is generally based on the functionality of the hardware itself. A "char" is one byte, whatever size a byte happens to be. So in dealing with chars, you are dealing with memory in a much more direct manner.

And a String is generally just a wrapper of a char array. I don't see the distinction between wrapping the character array operations in a class and writing them over and over again. At a hardware level a char array is a series of bytes. At a hardware level a String is a series of bytes. the hardware doesn't give a rat's ass what that series of bytes represents in your program.

Otto:

When you do some lower level programming, like coding something designed to run directly on a microcontroller or a PIC or something like that, you usually use C. Generally because that's what it supports. On such hardware, your choice of languages is limited. You can't just put any language onto any piece of hardware, unless you feel like rolling your own compiler.

I fail to see why that means people should not use Strings and avoid char arrays in C++.

Maurits · 2005-09-22 Reply Admin

dubwai:
Otto:

When you do some lower level programming, like coding something designed to run directly on a microcontroller or a PIC or something like that, you usually use C. Generally because that's what it supports. On such hardware, your choice of languages is limited. You can't just put any language onto any piece of hardware, unless you feel like rolling your own compiler.

I fail to see why that means people should not use Strings and avoid char arrays in C++.

It doesn't, and Otto didn't say it did.

You must admit there is value in learning to manipulate character arrays, even if the value is limited to "someday you might need to code a lower level program w/o C++"

If you're prepared to put a design constraint on yourself to the effect that "I will never need to use character arrays", by all means stick to the string library. There's a good argument for this... the string library is easier, and you gain time to learn other things.

dubwai · 2005-09-22 Reply Admin

Maurits:
dubwai:
Otto:

When you do some lower level programming, like coding something designed to run directly on a microcontroller or a PIC or something like that, you usually use C. Generally because that's what it supports. On such hardware, your choice of languages is limited. You can't just put any language onto any piece of hardware, unless you feel like rolling your own compiler.

I fail to see why that means people should not use Strings and avoid char arrays in C++.

It doesn't, and Otto didn't say it did.

You must admit there is value in learning to manipulate character arrays, even if the value is limited to "someday you might need to code a lower level program w/o C++"

If you're prepared to put a design constraint on yourself to the effect that "I will never need to use character arrays", by all means stick to the string library. There's a good argument for this... the string library is easier, and you gain time to learn other things.

You're right, he wrote:

Otto:
As long as there is hardware which does not directly implement string constructs, we will need character arrays.

This is what I am questioning, I don't know how we got into this whole "you might need C one day" discussion. Hardware doesn't need to "directly implement String constructs" in order for a language to allow them. What hardware does have a direct implementation for Strings? This implies that you might not be able to use Strings when the target platform's hardware doesn't support them. It also implies that common hardware does have direct support of character arrays. I'm not saying that hardware could not do this but it's clearly not a requirement in order to use either construct.

dubwai · 2005-09-22 Reply Admin

Maurits:

You must admit there is value in learning to manipulate character arrays, even if the value is limited to "someday you might need to code a lower level program w/o C++"

I never said there wasn't value to it. As far as I'm concerned, arrays is arrays. Bytes is bytes. I solve problems as needed.

emptyset · 2005-09-22 Reply Admin

dubwai:
What hardware does have a direct implementation for Strings?

<FONT face="Courier New" size=2>the kind of hardware that has native support for times new roman, courier, lucidia console, comic sans, and helvetica.</FONT>

Beek · 2005-09-22 Reply Admin

dubwai:
Otto:
As long as there is hardware which does not directly implement string constructs, we will need character arrays.

This is what I am questioning, I don't know how we got into this whole "you might need C one day" discussion. Hardware doesn't need to "directly implement String constructs" in order for a language to allow them. What hardware does have a direct implementation for Strings? This implies that you might not be able to use Strings when the target platform's hardware doesn't support them. It also implies that common hardware does have direct support of character arrays. I'm not saying that hardware could not do this but it's clearly not a requirement in order to use either construct.

I think Otto just momentarily confused hardware with libraries. On the microcontroller I've worked with (Atmel ATMega16), you don't get the C standard library. And you don't have the tools (MMU, or in some cases, stack space) to build a String abstraction. So you have to work with character arrays directly.

dubwai · 2005-09-22 Reply Admin

Beek:

I think Otto just momentarily confused hardware with libraries. On the microcontroller I've worked with (Atmel ATMega16), you don't get the C standard library. And you don't have the tools (MMU, or in some cases, stack space) to build a String abstraction. So you have to work with character arrays directly.

OK, I'll take your word for it. But, from my perspective, a basic String abstraction can be a set of subroutines that work on character arrays. Are you saying you can't define subroutines? The memory requirements for this type of abstraction are exactly the same as for a character array.

2005-09-22 Reply Admin

Maurits:
Here's a version of RemoveColonsFromString(char *s) that actually compiles and runs and works and everything :)

void RemoveColonsFromString(char *s)
{
    char *t;

    for (t = s; *s != '\0'; s++)
    {
        if (*s != ':')
        {
                if (t != s && *t != *s)
                {
                        *t = *s;
                }
                t++;
        }
    }

    if (*t != '\0') { *t = '\0'; }

    return;
}

OK, but I see absolutly no need for the innermost tests -- if (t!=s && *t != *s) -- if it were me I'd do the copy unconditionally. The tests waste cycles figuring out if doing the copy would be the equivalent of doing nothing.

I'd do it this way:

void RemoveColonsFromString(char *s)
{
    char *t;
    char c;

    t = s;
    do {
        c = *s++;
        if (c != ':')
        {
            *t++ = c;
        }
    } while (c != '\0');

    return;
}

To me, that's the simplest, clearest way to do it.

brazzy · 2005-09-22 Reply Admin

Jens:

Btw, i love working with char arrays :-) Incidently, somebody mentioned that modern string implementations are not based char array. What are they based on then? Linked lists?

BTW I just now thought of an answer to this. A proper string implementation should be able to deal with the full range of Unicode characters, which means the char type is useless. You need 2 or even 4 bytes to represent one character, so you'll define a type for that and work with arrays of that type.

Beek · 2005-09-22 Reply Admin

dubwai:
Beek:

I think Otto just momentarily confused hardware with libraries. On the microcontroller I've worked with (Atmel ATMega16), you don't get the C standard library. And you don't have the tools (MMU, or in some cases, stack space) to build a String abstraction. So you have to work with character arrays directly.

OK, I'll take your word for it. But, from my perspective, a basic String abstraction can be a set of subroutines that work on character arrays. Are you saying you can't define subroutines? The memory requirements for this type of abstraction are exactly the same as for a character array.

Some microcontrollers have no stack at all. And some have such a small stack space that you're limited to only going 3 or 4 subroutines deep. (Although you might be able hack something together with a preprocessor - I haven't worked with such a chip myself.)

But the point is, the subroutines you're creating aren't usually general enough for me to consider them an abstraction in the same way as the C standard library or a String class.

brazzy · 2005-09-22 Reply Admin

dubwai:

Mung Kee:

As CS programs across the country, and likely the world, are removing curiculum that involves low-level concepts, we're generally getting a lower grade of a developer. There are surely some very sharp mathmatical minds coming up but if the others can't understand a char array, what prayer do they have understanding why a StringBuilder/StringBuffer is so much better or, as you said, regular expressions?

If that's the case, it's a horrible thing.

I agree, though you both seem to be a bit too focused on C/C++. I got my degree (in 2002) without ever formally learning C and without writing more than a hundred lines of it. It was Java right from the beginning and for most classes teaching abstract concepts. However, the mandatory classes also included assembler and even microcode.

While I've never actually used either outside those classes, don't expect to do so in the future, and am glad about that, I'm certain that these classes were very important because they (in combination with a few other "useless" ones) gave me a complete (if non-detailed) understanding of how a computer fundamentally works on all levels, from the logic gates on the CPU IC up to the user applications.

I actually think this has a measurable value for my work, even though that is situated pretty much exclusively on the highest of those levels (distributed Java apps), because it made me view the computer as a fundamentally deterministic and understandable (if complex) machine and given me the confidence to know that I can always and completely control that machine if I put my mind to it. There is nothing magic or scary about it. Any bug can be found and fixed if you dig deep enough. Any piece of code must have a reason to exist (even though that reason may be to satisfy stupid quirks of some routine written by a programmer who does believe in magic).

dubwai · 2005-09-22 Reply Admin

Beek:

Some microcontrollers have no stack at all. And some have such a small stack space that you're limited to only going 3 or 4 subroutines deep. (Although you might be able hack something together with a preprocessor - I haven't worked with such a chip myself.)

I feel like you are assuming that I have never programmed a microcontroller. That is not the case. I have worked on many different low-level technologies from building circuits with loose trasistors to writng assembly interpreters in machine code.

I can't recall exactly, but I seem to remember building subroutines with no hardware stack. Anyway, I can imagine how I would do it if were necessary.

Beek:

But the point is, the subroutines you're creating aren't usually general enough for me to consider them an abstraction in the same way as the C standard library or a String class.

My point is that the code you write whether it be in C, C++ or Java, all compiles down to the same types of instructions. Saying my hardware doesn't support Strings doesn't make sense.

brazzy · 2005-09-22 Reply Admin

Mung Kee:

This reminds of sales clowns using "leverage" as a verb. It is now in the dictionary as transitive verb but wasn't always.

I love it. It's the perfect marketing drivel litmus test. Whenever it is used as a verb, you know you're reading/hearing content-free strings of words that can be safely ignored.

dubwai · 2005-09-22 Reply Admin

brazzy:
dubwai:

Mung Kee:
I agree, though you both seem to be a bit too focused on C/C++. I got my degree (in 2002) without ever formally learning C and without writing more than a hundred lines of it. It was Java right from the beginning and for most classes teaching abstract concepts. However, the mandatory classes also included assembler and even microcode.

I don't think Java is a bad language to learn to program in. I actually think it's a good language because it forces a level of stucture on the programmer and frees that programmer from a lot of confusing an arcane syntax.

But a CS degree is more than just a programming degree. I think they need to create a more business/computer mixed curriculum for people who aren't very interested in the fundamentals. I think part of the problem is that this would re-marginalize CS departments and the heads don't want that.

dubwai · 2005-09-22 Reply Admin

brazzy:
Mung Kee:

This reminds of sales clowns using "leverage" as a verb. It is now in the dictionary as transitive verb but wasn't always.

I love it. It's the perfect marketing drivel litmus test. Whenever it is used as a verb, you know you're reading/hearing content-free strings of words that can be safely ignored.

I think leverage is actually a pretty good verb. I don't know of a better word for it. It's probably overused but don't throw the baby out with the bathwater. Verbing is a fact of life these days. Best to just agreement it.

2005-09-22 Reply Admin

hank miller:
Anonymous:
Now to take it back in the opposite direction: obfuscation (why? Because I'm bored.).
void RemoveColonsFromString(char *s, char *t) {
  *s-58?0[t++]=0[s++]:s++;
  0[s-1]?RemoveColonsFromString(s, t):t;
}
Can anyone make it more obfuscated?
Well there are lots of tricks with #define that I could come up with, but anyone can add them. Try this version:
void RemoveColonsFromMac(char *s, char *t) {
  0[t++] = 0[s++];0[t++] = 0[s++]; 
  *s?RemoveColonsFromMac(++s,t):t;
}
I'd like to use the comma operator in there, but then it only operates correctly on some compilers.

Either you're a true master of obfuscation, or you've neglected to actually check for the ':' anywhere in there.

hank miller · 2005-09-22 Reply Admin

Anonymous:
hank miller:
void RemoveColonsFromMac(char *s, char *t) {
  0[t++] = 0[s++];0[t++] = 0[s++]; 
  *s?RemoveColonsFromMac(++s,t):t;
}
Either you're a true master of obfuscation, or you've neglected to actually check for the ':' anywhere in there.

I assure you that this correctly removes colons from Mac addresses. (Barring minor bugs as I have not actually tested it)

Thank you. I don't know that I'm a master, but it this is a good start on the path.

Note the function is RemoveColonsFromMac? That should be your clue. My version will not work for anything other than well formed mac addresses. (Such as the origonal MacAddrToChar would produce)

I'll give it away tomorrow, but I'll give you overnight to sleep on the trick I'm pulling.

Maurits · 2005-09-22 Reply Admin

hank miller:
I assure you that this correctly removes colons from Mac addresses.

Heh. Yes, I see how it works. :)

2005-09-22 Reply Admin

brazzy:
Mung Kee:

This reminds of sales clowns using "leverage" as a verb. It is now in the dictionary as transitive verb but wasn't always.

I love it. It's the perfect marketing drivel litmus test. Whenever it is used as a verb, you know you're reading/hearing content-free strings of words that can be safely ignored.

I've used Context Free Grammars but not Content Free [:'(]

travisowens · 2005-09-23 Reply Admin

An OO language with no public or private identifiers? What sick language is this?

2005-09-23 Reply Admin

travisowens:
An OO language with no public or private identifiers? What sick language is this?

Smalltalk? Python? Javascript?

2007-03-07 Reply Admin

Spoken like someone who learned to program from "Teach yourself VB in 21 days"

Colonitis

Leave a comment on “Colonitis”