oldnpastit – Member
1. KISS. Being stupid is actually an advantage to a computer programmer. Up to a point.

This is important. Don’t be clever if you can be simple. Clever is a complete pain to debug and/or maintain. If you have to be clever please document your cleverness in a way that seems like you’re explaining it to a moron. Because if you have to fix it in 6 months or a year or even later you’ll be feeling like a moron as you scratch your head over the convoluted code your younger, stupider self thought was clever.

This is important. Don’t be clever if you can be simple. Clever is a complete pain to debug and/or maintain. If you have to be clever please document your cleverness in a way that seems like you’re explaining it to a moron. Because if you have to fix it in 6 months or a year or even later you’ll be feeling like a moron as you scratch your head over the convoluted code your younger, stupider self thought was clever.

In addition, it turns out you can’t add developers to your project, because your new developers just won’t be able to figure out what the blazes you are/were trying to do. Especially if it’s anything involving complicated lifetimes and std::shared_ptr<>.

Or so I’ve heard anyway.

What have you got against std::shared_ptr<> oldnpastit?

Work pretty well in my experience. Certainly a lot less error prone than managing raw pointers . The only real issue I’ve had is with programmers who are still trying to write in C and just don’t understand them.

Bit like in C# world, rewriting everything as LINQ expressions, because it’s cool. Actually I fell for that a bit, but ReSharper didn’t help as it kept advising this or that could be rewritten in one cool LINQ statement. Looking back at the code and especially if it’s someone who doesn’t know LINQ and got no idea what’s going on there.

Has its place though. A nice bit of LINQ vs some hideous big loop and conditional checks.

There’s the opposite end where a team lead or project manager decides to ban the cool stuff because basically they don’t understand it, so you’re stuck on legacy stuff and have frustrated developers.

I am a full-time employee to a company that essentially contracts us out to other companies. Any work off the clock or that could be construed as threatening privacy of a client would be very frowned upon.

My old job was with a small consultancy. We preached the open source way and the contracts said that where possible code would be freely licensed and public, if the client wanted proprietary code the rates were higher…

Worked surprisingly well!

What have you got against std::shared_ptr<> oldnpastit?

Work pretty well in my experience. Certainly a lot less error prone than managing raw pointers . The only real issue I’ve had is with programmers who are still trying to write in C and just don’t understand them.

They are slow – there’s an extra load of locking/unlocking that goes on in the background. Usually that’s OK, but sometimes it can cause weird slowdowns.

Worse than that is it encourages program design that doesn’t think up-front about how lifetimes and ownership will work.

It also goes horribly wrong if people take the raw pointer out of a std::shared_ptr<> and then stuff it into another, unrelated shared or unique ptr. While you might think that people shouldn’t do this (and you would be right) it turns out that they do.

Also they look really ugly.

They are slow

Slower, yeah, but slow? As in measurably so? Not IME. Not unless you are absolute hammering them with billions of objects. (And if you are sharing billions of objects then your code is.. interesting).

Bear in mind that if you don’t use them then you may need to roll your own thread-safe code to manage the lifetime of raw pointers to dynamically allocated resources. That’s not easy! It often ends up with more overhead than shared_ptr. Plus it’s a major source of bugs.

Worse than that is it encourages program design that doesn’t think up-front about how lifetimes and ownership will work.

Lifetimes and ownership don’t matter though – that’s the point. A shared object has shared ownership and lives as long as at least one owner still cares. That’s perfect.

In contrast smart pointers force people to make up-front design decisions about whether an object should be unique, shared or weak – something you can’t even express with raw pointers.

e.g. if a public method returns a raw pointer then I need to go trawl the source to figure out if I need to delete it or not (and also how to delete it). If that method changes those ownership semantics later, then it can impact my code without me even noticing.

But if the method returns a smart pointer then I know exactly where I am and any later changes to that design are explicit in the signature.

It also goes horribly wrong if people take the raw pointer out of a std::shared_ptr<> and then stuff it into another, unrelated shared or unique ptr. While you might think that people shouldn’t do this (and you would be right) it turns out that they do.

Yep true. Those people are C programmers pretending to write C++. 🙂 That should be caught at peer review.

But likewise there are a hundred and one ways to get raw pointers horribly wrong and many of them are very hard to catch.

In ”Effective Modern C++” Meyers say:

…we might try to enumerate the reasons why a raw pointer is hard to love:

1. Its declaration doesn’t indicate whether it points to a single object or to an array.

2. Its declaration reveals nothing about whether you should destroy what it points to when you’re done using it, i.e., if the pointer owns the thing it points to.

3. If you determine that you should destroy what the pointer points to, there’s no way to tell how. Should you use delete, or is there a different destruction mechanism (e.g., a dedicated destruction function the pointer should be passed to)?

4. If you manage to find out that delete is the way to go, Reason 1 means it may not be possible to know whether to use the single-object form (“delete”) or the array form (“delete []”). If you use the wrong form, results are undefined.

5. Assuming you ascertain that the pointer owns what it points to and you discover how to destroy it, it’s difficult to ensure that you perform the destruction exactly once along every path in your code (including those due to exceptions). Missing a path leads to resource leaks, and doing the destruction more than once leads to undefined behavior.

6. There’s typically no way to tell if the pointer dangles, i.e., points to memory that no longer holds the object the pointer is supposed to point to. Dangling pointers arise when objects are destroyed while pointers still point to them.

Raw pointers are powerful tools, to be sure, but decades of experience have demonstrated that with only the slightest lapse in concentration or discipline, these tools can turn on their ostensible masters.

(Very good book by the way)

Also they look really ugly.

I’ll give you that one too. But C++ rarely an elegant looking language. 😆

I am primarily a C programmer. While C’s raw pointers can be the source of a lot of trouble it is at least nice to think that I don’t have to understand quite as many different ways to handle pointers (and therefore how to handle each sort of pointer safley) as I would in C++.

C raw pointers are a bit easier compared to C++ raw pointers, but there is a good reason why various safety standards (e.g. MISRA C) completely ban the use of dynamically allocated memory.

Experience shows it is just too dangerous.

My limited exposure to MISRA suggests that it’s a right old barrel of laughs.

One friend had some sort of connection to a group that contributed to MISRA or something similar. His impression was that the people assigned to work on it were put there to keep them from doing the harm they’d inflict if assigned to real software projects.

It’s a pretty tough standard – but it’s also the reason your car doesn’t randomly stop because it has run out of memory 😀

It’s easy to work around MISRA – write it in assembler instead.

If you can’t do it in assembler, you probably have an over-complex design.

Or, y’know, just stick to statically allocated memory.

If you can’t do it in assembler, you probably have an over-complex design.

Surely if you can’t do it in assembler, then neither can the compiler? Unless commercial compilers have secret access to the hidden / undocumented processor features, and you’re doing something weird and very low level (that probably needs C with inline assembler anyway) ?

One of the things I like about some of the unit test frameworks is that I can structure my tests into a series of assertions, or even use case descriptions, of how my software components work.

That, in conjunction with good naming and good software partitioning into focused libraries/dlls, can provide good ‘living’ documentation for the system that someone can be sure is still relevant, unlike technical documentation produced at the start of a project.

We’re using Mocha at the moment for unit up to end-to-end tests and the descriptions are structured to provide even nicer documentation.

Even writing embedded stuff we rarely go down to assembler, except for the really really low-level hardware interface stuff where you need to get clock cycle timing perfect.

1. You can’t write your own crypto. You might think you can but you can’t, so save your users a lot of trouble and use the platform crypto instead. And make it easy to upgrade.

2. Parsing XML is difficult, so use the platform XML parser. It will save you so much trouble in the future.

3. When you are ripping off Open Source components, credit the teams that wrote it and make their code easy to upgrade.

4. Leave your ego behind. It might be code you have spent hours, days or weeks on, but that should not stop you from accepting that it may have bugs. The last thing a project needs is someone getting defensive and not fixing problems.

5. Architect and design the system defensively. There will be security vulnerabilities in your code, so if the whole system is geared up to defend agains them, it will be less painful to fix.

"1" + 1 == 0
'1' + 1 == '2'
'1' + '1' == 'b'

Damn C 😀

I like c++ but working as a 3ds max developer have to put up with shit like this on a daily basis 😀

BOOL ShapePickMode::HitTest(IObjParam *ip, HWND hWnd, ViewExp *vpt, IPoint2 m,int flags) {
if (!mpEditPoly) return false;
if (!ip) return false;
return ip->PickNode(hWnd,m,this) ? TRUE : FALSE;
}

this is relatively mild rubbish from the sdk I just happen to have open when reading this thread

Klunk: Mmmmm….

Poorly named parameters? Check.
Unused parameters? Check.
Hiding errors as valid return values? Check.
Passing pointers when they should probably be references? Check.
Not using const? Check.
Not using the built in true/false constants? Check.

All good stuff. To be fair though, you can write a crap API in just about any language.

The golden rule of writing good software is “look at how Garmin have done it then do the exact opposite”.

Or, y’know, just stick to statically allocated memory.

I do, I do. My current gig is genuinely easier in assembler.

Anybody else waiting eagerly to see what molgrips has to say ? 🙂

My current gig is genuinely easier in assembler.

Blimey, that’s rare these days.

We tend to design in a C/C++ interface layer on top of any assembler stuff. That way we can build the suitable Mocks/Fakes/Stubs/Spies for unit testing purposes against that interface without necessarily needing them to run on the target hardware.

Still do most of my work in assembly as well (low power DSP/comms stuff). Except for the actual assembler for the DSP we use, which I wrote myself in nice clean portable C 🙂

And since unbelieveably no-one’s posted it yet, here’s the obligatory XKCD …

Definitely the engineering rule of “pick two” applies for software –
– cheap (quickly written)
– light/fast (performance)
– strong (robust/reliable)

I had the misfortune to try and maintain a colleague’s piece of code, I think it was a TIFF manipulation routine. C. I swear to god there was *a* routine, and best part of 3,000 lines of code. I may have wept.

10. When you find yourself writing stuff “just in case” or for future upgrades, be very wary!

Anybody else waiting eagerly to see what molgrips has to say ?

I’m not reading this thread.

Exception in molgrips.cpp: molgrips not found.

2. Two mutexes good, four mutexes bad.

2. Two mutexes good, four mutexes bad. No mutexes best.

here are some more …….

Adding extra unwanted stuff because they think it might be needed later

Not refactoring

Editor inheritance

Not handling the unexpected

Saying they are complete when what they actually mean is ‘I’ve nearly done typing it in and I think it will compile’

Surely just create a mock/fake/stub molgrips and have it say whatever you like?

Because molgrips is written in Java.

So first we’ll need an AbstractMolgrips class produced by an AbstractMolgripsFactory, realised by a RealMolgripsFactory and MockMolgripsFactory then we’ll want an AbstractMolgripsFactoryFramework to take care of selecting the factory… …and probably some Beans too for good measure… 😉

SELECT name
FROM stwers
WHERE bighitter = TRUE
AND currently_flouncing = FALSE
AND unwilling_mac_user = TRUE
;

Or something. I don’t do this for an actual living, which is probably for the best where our codebase is concerned.

We tend to design in a C/C++ interface layer on top of any assembler stuff.

I’ve worked on a project with a C/C++ interface layer underneath the assembler stuff.

That was slightly leftfield.

Yeah, that’s an erm… unusual design decision 😕

'1' + '1' == 'b'

What the shit is this?

What the shit is this?

In C the char type is an integer type (usually a 8 bits) and it just holds the ASCII value of the character.

So
'1' + '1' == 'b'
works because it is equivalent to
49 + 49 == 98

😀

Can you figure out the other two though?

"1" + 1 == 0
'1' + 1 == '2'

Ok, so '1' + 1 == '2' is essentially the same – you’re incrementing the ASCII value?

"1" + 1 == 0 – is that just a type mismatch, adding an integer to a string? Sounds like a tenuous explanation but…?

I should add, I’ve never touched C++ in my life. Beyond Pascal at Uni I’ve only really dabbled. Despite that I was actually employed as a programmer at one point, but that was glorified web dev building an intranet system. HTML pages with client-side Javascript and server-side VBscript, often with all three on the same line of code. Fun times.

“Well, actually”

I see what the point is: “1” is a pointer to an array of characters, specifically two characters ‘1’ (ascii 49) and ‘<turns out its impossible to write backslash-zero here>’ (ascii 0, the null byte). Adding to an array is moving the pointer, so the pointer now points at the null byte.

But if you put that into a compiler then that isn’t what it would say…

const char *s = “1”;
puts(s); // prints ‘1’
puts(s+1) // prints a blank line