C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

Aramis: Sep 22, 2009

floWenoL posted:

I can't think of a reason to return a pointer-to-const over a const reference for an accessor.

That's not true at all. If your member is dynamically allocated you better use a pointer instead, on account of the whole "dereferencing a NULL is kinda bad". You could make an argument that for members that are allocated at construction time dereferencing the pointer in a reference would be safe(ish). But that's asking for trouble in the long run.

However, if the member is not a pointer, a reference is always better.

Simple rule of thumb: A reference -> equivalent pointer cast is always fine. If you ever have to do pointer -> reference then something has generally gone wrong. Because of that, always use references where possible, since you can always bail to a pointer if something requires it anyways.

Edit: I am talking about high-level organizational structures here. Operators and small operations are a different matter.

Aramis fucked around with this message at 08:28 on Dec 21, 2009

# ¿ Dec 21, 2009 08:22

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 18:26

Aramis: Sep 22, 2009

Paniolo posted:

code:
assert(m_ptr != nullptr);
return *m_ptr;
Or throw an exception.

The fact that it's feasible changes nothing to the issue at hand. C++ is riddled with ways to do things that work but are totally inadvisable until you are painted in a corner. const_cast is a great (possibly best) example of this. In your example, if the pointer is null, you still de-reference it (in a release build). It's way, way safer to address this at the call point of the function.

code:

MyClass * ptr = obj.getPtr() ;
if( ptr )
{
  //this is fine unless we have a dangling or uninitialized pointer
  call_function_that_takes_a_reference( *ptr ) ;
}

I cannot stress this point enough, and I get pissed at junior programmers on a regular basis for it: possible/works != license to use.

edit:

That Turkey Story posted:

I'm sorry, but that's total poo poo. There is nothing wrong with dereferencing a pointer and forming a reference unless you have a null pointer, which you either know by design or by an explicit check. Something has not "generally gone wrong" when you are correctly working with dynamically allocated memory or simply working through indirection and you need to form a reference from a pointer.

Remember the context, we are talking about an accessor here. Which means that there is no possibility of a fallback, unless you throw an exception you'll need to dereference something.

Aramis fucked around with this message at 09:35 on Dec 21, 2009

# ¿ Dec 21, 2009 09:31

Aramis: Sep 22, 2009

It's "kinda" feasible with expression templates, but that's a rabbit hole I wouldn't recommend going down.

For an example, you can look at boost::spirit::qi and boost::spirit::karma where that sort of symmetric logic is applied in theory.

# ¿ Feb 3, 2016 08:34

Aramis: Sep 22, 2009

clang-format will help for indentation, spacing, braces style etc... But at the end of the day, the really important parts of coding style, like naming schemes and identifier formatting, is just something that you'd have to tackle with good old fashioned elbow grease.

If the codebase's standards are really inconsistent accross the board, then slapping a coat of paint with astyle or clang-format will be a pretty minor improvement against the general incosistencies, and messing up the revision history for it is of debatable value in my opinion.

# ¿ Nov 15, 2017 05:05

Aramis: Sep 22, 2009

Captain Cappy posted:

In the source file? Who cares, it's fine.

It's very much not. the std namespace is so large that ensuring that you dodge every single identifier for every single symbol you declare in your own namespace is simply unrealistic, and generally unpleasant

# ¿ Dec 8, 2017 08:10

Aramis: Sep 22, 2009

Are you looking for a stack sampler, or something more aggressively instrumented?

# ¿ Dec 8, 2017 14:53

Aramis: Sep 22, 2009

baby puzzle posted:

The problem that I keep having with C++ is that very often there are often multiple different ways to accomplish the same thing, like with arrays. So I'm wondering if the future plans for C++ will ever involve becoming more simplified, or if the backwards compatibility thing is going to stick around forever, with the language growing new appendages forever. I guess I'm looking at how nice other languages seem, and questioning the massive amount of investment I've put into C++.

The language itself will probably never be simplified by design. However, you can expect tools like clang-tidy to become gradually more and more pedantic about what passes and what doesn't. Get in the habit of running it as part of your build process and you will get the stricter language you want.

# ¿ Jan 8, 2018 08:47

Aramis: Sep 22, 2009

The Phlegmatist posted:

C++ should eventually have std::span<T> (C++20 maybe?) which is a non-owning view into a contiguous area of memory, making it easier and safer to work with C style arrays.

std::span<> is incredibly overrated in my opinion, unless you are interacting with a C library or the OS, odds are pretty good that whatever function you are writing that would take a span<> should be operating on iterators instead.

# ¿ Jan 8, 2018 23:35

Aramis: Sep 22, 2009

Bruegels Fuckbooks posted:

what the hell is the compiler supposed to do with AR_Quiz[] in your function prototype? A prototype needs a data type and the name of the variable for every parameter in the function. Where is the name of the variable?

Nope! Prototypes do not need the arguments to be named since since that does not impact name mangling.

In fact, a function whose argument names are implicitely deductible from context is generaly a good sign, since they are likely to be correctly self-documenting at the call site.

# ¿ Aug 16, 2018 07:37

Aramis: Sep 22, 2009

Honestly, I've switched to just making "private but accessible to tests" members public with a python style underscore postfix. It's just not a fight worth fighting. It's obvious, trivial to catch in a code review, and prevents me from comprimising designs just for the sake of testability. Maybe one day I'll write a clang-tidy tool to check for that, but I seriously doubt that'll actually improve anything.

Aramis fucked around with this message at 21:32 on Jul 29, 2019

# ¿ Jul 29, 2019 21:18

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 18:26

Aramis: Sep 22, 2009

**Edit** Upon re-reading, nah, forget it, I'm off base.

Aramis fucked around with this message at 00:59 on Apr 14, 2020

# ¿ Apr 14, 2020 00:28

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread