Right on the first one. ‘2’ follows ‘1’ in the ASCII table so the addition sort of “works”.

The second one is a bit more subtle. Strings in C don’t really exist. They are really just a pointer to a block of characters that terminates with a null character.

So adding 1 to it just shifts the pointer along by one element, so that it is now pointing at the null character, which is zero.

(in actual code you’d need to dereference the pointer with a * to read its contents – but that’s just confusing things further)

So in terms a brain whose strongest programming language is Pascal can understand,

A string in C has a nul terminator at the end (I think I knew this somewhere at the back of my brain next to the cheat codes for Jet Set Willy).

Adding an integer to a string is handled as an array so you step into it.
So "dave/0" + 1 == "ave/0" (using the wrong slash here so it displays)?

Try this ross:


const char *s = "1";
puts(s);
if (*(s + 1) == 0) puts("YUP!");


https://ideone.com/BzPr1G

Yep, that’s it Cougar.

Though it’s not really that it “is handled as an array”, it’s really that you are doing pointer arithmetic by adding a value to the pointer.

The pointer is just the memory address where your “dave/0” characters are stored, let’s say 0x00114000.

When you add an integer to a pointer, C (and C++) interprets that as “add this number, multiplied by the size of the things I’m pointing to, to this pointer address”

So you “dave/1” + 1, becomes 0x00114000 + (1 * sizeof(char)).
So, assuming that on your system a char is one byte, the pointer ends up being 0x00114001. If a char is two bytes it would be 0x00114002. Either way it would end up pointing to the next char.

Array notations in C are really just a prettier way of doing exactly the same pointer arithmetic.

This might help:
https://ideone.com/JxoMrw

Fascinating. yes, thanks.

What’s the asterisk signify in the variable declaration?

It indicates that s is a pointer to a character. Or to an array of characters, i.e. a string, which is actually the case. See an earlier post in this thread about how C pointers don’t distinguish between the two.

Aha. Ta.

The asterisk is part of the type.

char *s

says that s is a pointer to a char.

Whereas

char s

would say that s is a char.

Edit: too slow. 🙂

Yeah, that’s an erm… unusual design decision

More of a certification decision. C’est la vie.

I can’t believe there is a thread about good software and no-one has mentioned Uncle Bob.

Follow the teachings of Clean Code. This is a must read for all my Devs.

Ooh good shout. “Code Complete” by Steve McConnell is also good.
http://amzn.eu/8e1FlA7

Ooh good shout. “Code Complete” by Steve McConnell is also good.

a bit old school I would have thought – and I wasn’t impressed by it back then really.

some interesting stats in there though – like the people that do the small ‘patch’ fixes often introduce more bugs that the person that makes the larger changes – maybe as part of a refactor – as their bigger changer has made the effort to understand the software, whereas the smaller changer is just patching it up and may not understand it as well.

From that era I thought Writing Solid Code was much better :

although not so relevant nowadays if you are using test frameworks and that style, this is more from the ASSERT days.

Interesting where he says he went round Microsoft to persuade people to use these good practises, as they weren’t, and had resistence.

There’s a good quality story in there which still stands.

He had two coffee shops near his work, both used the same beans and the same machines – one had very good and consistent coffee and the other was low quality and very variable.

The difference was that the good shop had two lines drawn on their perc jugs.

When you ordered a coffee the server would pour from the available jug, and if the coffee went below the top line the would then put the next percolator on, and then finish serving the customer.

Then they could continue serving from that same jug and by the time it was empty the other one had finished and was ready. I think the bottom line determined when it was ready, you couldn’t serve from it until the coffee was over the bottom line.

In the other shop the server would pour the coffee, finish serving the customer, and then start the other percolator up if the current one was low.

Because of the timing difference and the lack of a defined line marking when the coffee should be deemed low and to therefore start the other one, often the new percolator would not be finished before the other one had run out, so a customer at that time would get strong coffee frmo the new percolator and the following ones would get weak coffee.

That is one story I always remember, a simple process is all that is needed to ensure quality.

The other one is a quote from Marc Anderson that A grade people hire A grade people, B grade people hire C grade people.

a bit old school I would have thought – and I wasn’t impressed by it back then really.

2004 apparently. Blimey now I feel old 😀

I quite liked it. Been a long time since I read it, but still seems to be scoring highly on Amazon reviews so hopefully people still find it useful. I agree that something like Clean Code with a more TDD/Agile approach is probably more suited these days, but you can’t read enough books on writing good code.

Do your analysis properly and get your requirements right.

All the clever stuff programming stuff doesn’t matter if you are building the wrong thing.

Do your analysis properly and get your requirements right.

that’s a bit old school as well – the rise of XP and Agile processes is based on the fact that no-one can actually capture the requirements completely and unambiguously, and requirements often change during the project, particularly as incremental versions of the product are delivered and the end-users change their view of what they can do with the product.

There are detractors, but there are so many good and battle-worn aspects to XP, and agile based, processes that they are hard to argue against, and very little in waterfall based processes to argue for.

particularly as incremental versions of the product are delivered

That’s your problem right there.

What’s wrong with the good old fashioned approach of spending a day or two gathering requirements and then not speaking to your clients until you deliver the final product 2 years later?

😉