Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

Absurd Alhazred posted:

You want a coding horror? C++ has a const modifier suffix for methods, which tells all and sundry that nothing in the method body is going to change anything about the object...

Except that you can change members if you declare them with a mutable modifier prefix!
C++ code:
class Test
{
public:
	void canDoNothing() const
	{
		ActuallyModifiableSucker++;
	}
private:
	mutable int ActuallyModifiableSucker;
}

C++ code:

class Test
{
public:
	void canDoNothing() const
	{
		const_cast<Test*>(this)->ActuallyModifiableSucker++;
	}
private:
	int ActuallyModifiableSucker;
}

# ? Jan 18, 2018 22:59

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 01:55

Xarn: Jun 26, 2015

Ultimately, the type system in C and C++ contains enough escape hatches to let you do anything. Used indiscriminately, they will lead to horrors. Used sparingly, they are what makes everything run :shrug:

# ? Jan 18, 2018 23:02

Soricidus: Oct 21, 2010; freedom-hating statist shill

Munkeymon posted:

My thought was that there might be optimizations the JIT could do given that guaranteed structure around property code, but maybe not, I dunno.

Properties are a C# thing; they don�t exist in the bytecode that the CLR works with. The C# compiler just turns them into fields with get/set methods, so the JIT literally sees exactly the same thing whichever way you write it.

# ? Jan 18, 2018 23:54

The Phlegmatist: Nov 24, 2003

Xarn posted:

Ultimately, the type system in C and C++ contains enough escape hatches to let you do anything. Used indiscriminately, they will lead to horrors. Used sparingly, they are what makes everything run

The trick is figuring out when to use them and when to run away from them. This is difficult and has led to coding standards like "never use static or mutable ever."

At least you can't use const_cast to actually modify const data members. Or, well, you can and the compiler will generate code for you but it's undefined behavior and likely to mangle random memory and segfault.

# ? Jan 19, 2018 03:58

Hunter2 Thompson: Feb 3, 2005; Ramrod XTreme

Absurd Alhazred posted:

You want a coding horror? C++ has a const modifier suffix for methods, which tells all and sundry that nothing in the method body is going to change anything about the object...

Except that you can change members if you declare them with a mutable modifier prefix!
C++ code:
class Test
{
public:
	void canDoNothing() const
	{
		ActuallyModifiableSucker++;
	}
private:
	mutable int ActuallyModifiableSucker;
}

There are scarce situations when you need an object to be �conceptually� const rather than actually const. One example is an object that has an internal cache. That�s what mutable is for. Iirc Meyers has a section in his Modern C++ book about it. You�ll know it when you need it, otherwise don�t use the mutable keyword.

# ? Jan 19, 2018 06:18

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Absurd Alhazred posted:

You want a coding horror? C++ has a const modifier suffix for methods, which tells all and sundry that nothing in the method body is going to change anything about the object...

Except that you can change members if you declare them with a mutable modifier prefix!

Well it beats allocating the mutable fields as separate objects and keeping a pointer to them

vOv posted:

If you didn't have mutable then you couldn't have an internal mutex with const getters because you'd have no way to lock it.

Yes! That's my main use for mutable

# ? Jan 19, 2018 09:37

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Soricidus posted:

Properties are a C# thing; they don’t exist in the bytecode that the CLR works with. The C# compiler just turns them into fields with get/set methods, so the JIT literally sees exactly the same thing whichever way you write it.

Not quite. If you use reflection on a compiled .NET assemblies, properties will appear as their own thing, distinct from methods.

# ? Jan 19, 2018 09:55

SirViver: Oct 22, 2008

NihilCredo posted:

Not quite. If you use reflection on a compiled .NET assemblies, properties will appear as their own thing, distinct from methods.

Well yes, but to clarify, reflection only looks at the assembly metadata and doesn't do any decompilation, so that doesn't really tell you anything regarding what the IL/JIT actually does underneath. On that level properties are methods.

Look at this example. While the IL output does contain information about a property existing and a link between it and its getter, the actual IL itself does not reference it anywhere but only makes direct calls to the "normal" method and generated getter method. And of course if you look at the JIT Asm output the notion of a property completely vanishes altogether (but that's beside the point I guess).

# ? Jan 19, 2018 10:39

feedmegin: Jul 30, 2008

The Phlegmatist posted:

At least you can't use const_cast to actually modify const data members. Or, well, you can and the compiler will generate code for you but it's undefined behavior and likely to mangle random memory and segfault.

Um, well, I doubt that. It'll probably either just work (with something allocated on the stack/via new()) or not mangle anything and just segfault (with a global that the linker ended up putting in .rodata, thus in memory that's set to read only).

# ? Jan 19, 2018 12:11

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Well, the compiler's free to assume that the const method didn't modify the object, so anything you do with it immediately afterwards could pretty reasonably be poisoned with some old values and some new.

# ? Jan 19, 2018 12:54

eth0.n: Jun 1, 2012

Jabor posted:

Well, the compiler's free to assume that the const method didn't modify the object, so anything you do with it immediately afterwards could pretty reasonably be poisoned with some old values and some new.

The compiler's free to assume that a const object doesn't change. The const-ness of any methods called on it, or pointers/references to it, is immaterial to that assumption. Those are just type-checking to help avoid the UB of changing a const object.

For example, even without const_cast, a const method could end up modifying its object through means other than the this pointer, such as another non-const pointer, or access to the underlying object directly (e.g., if it's global).

# ? Jan 19, 2018 15:22

quiggy: Aug 7, 2010; [in Russian] Oof.

The Phlegmatist posted:

At least you can't use const_cast to actually modify const data members. Or, well, you can and the compiler will generate code for you but it's undefined behavior and likely to mangle random memory and segfault.

Wait, what? I've never actually used const_cast because I'm not a drat crazy person but I was under the impression that this is the sort of thing it was designed for. Does it really just constify things that are currently not const, and if so why not just access the thing with a const pointer or reference?

# ? Jan 19, 2018 15:57

eth0.n: Jun 1, 2012

quiggy posted:

Wait, what? I've never actually used const_cast because I'm not a drat crazy person but I was under the impression that this is the sort of thing it was designed for. Does it really just constify things that are currently not const, and if so why not just access the thing with a const pointer or reference?

You can't use const_cast to take the const off of a const object. Once you declare a const object, it's const forever, and any attempt to change it is UB. You can only take the const qualifier off of pointers and references. If the object itself is non-const and you simply had a const pointer, then using the un-consted pointer to change the object is fine.

But the main point of const_cast is to allow use of libraries that are too old (or poorly written) to use const properly, and don't tag pointers/references/methods with const that logically should be. If the library does in fact not modify the object via the pointer you pass, then const_cast is perfectly safe. If it does, it's only safe if the object isn't actually const.

# ? Jan 19, 2018 17:00

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

Linear Zoetrope posted:

Oh my god, I thought I just had too many applications open and it was lagging Word or something.

Another annoying thing that can be disabled is slightly less obscure but causes a lot of problems is hardware acceleration. Disabling this can resolve several issues.

e: oh I didn't notice it mentions this same thing in disabling the animations, nice

Evil_Greven fucked around with this message at 21:14 on Jan 19, 2018

# ? Jan 19, 2018 17:11

quiggy: Aug 7, 2010; [in Russian] Oof.

eth0.n posted:

But the main point of const_cast is to allow use of libraries that are too old (or poorly written) to use const properly, and don't tag pointers/references/methods with const that logically should be. If the library does in fact not modify the object via the pointer you pass, then const_cast is perfectly safe. If it does, it's only safe if the object isn't actually const.

Huh, weird but at least I see the point now. Also explains why I've never once felt the need to use it I guess.

# ? Jan 19, 2018 19:41

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Absurd Alhazred posted:

You want a coding horror? C++ has a const modifier suffix for methods, which tells all and sundry that nothing in the method body is going to change anything about the object...

Except that you can change members if you declare them with a mutable modifier prefix!
C++ code:
class Test
{
public:
	void canDoNothing() const
	{
		ActuallyModifiableSucker++;
	}
private:
	mutable int ActuallyModifiableSucker;
}

mutable is infrequently needed but it is good, because it means you can have cached data on the object that's only (re)calculated when it's asked for, but still have the method that does the asking be const (because semantically, it is).

# ? Jan 19, 2018 21:32

The Phlegmatist: Nov 24, 2003

quiggy posted:

Huh, weird but at least I see the point now. Also explains why I've never once felt the need to use it I guess.

It's surprisingly common for older libraries to have messed-up interfaces, where the parameter is not const but the function doesn't mutate the argument passed to it and you are sure of this fact.

If you're designing an interface these days you should be using mutable and not const_cast (but please make sure you know what you are doing.)

feedmegin posted:

Um, well, I doubt that. It'll probably either just work (with something allocated on the stack/via new()) or not mangle anything and just segfault (with a global that the linker ended up putting in .rodata, thus in memory that's set to read only).

Depends on if the compiler optimized it out via constant propagation. Then you're well into undefined behavior territory.

# ? Jan 19, 2018 21:51

Pixelboy: Sep 13, 2005; Now, I know what you're thinking...

Absurd Alhazred posted:

You want a coding horror? C++ has a const modifier suffix for methods, which tells all and sundry that nothing in the method body is going to change anything about the object...

Except that you can change members if you declare them with a mutable modifier prefix!

Refcounts? Other debug meta data?

# ? Jan 19, 2018 22:29

quiggy: Aug 7, 2010; [in Russian] Oof.

The Phlegmatist posted:

It's surprisingly common for older libraries to have messed-up interfaces, where the parameter is not const but the function doesn't mutate the argument passed to it and you are sure of this fact.

If you're designing an interface these days you should be using mutable and not const_cast (but please make sure you know what you are doing.)

Yeah I guess I've just never dealt with a library with problems like that. I have used mutable before but always for actual legitimate reasons like caching and not just because oh gently caress me I need to change this member in a const function.

# ? Jan 19, 2018 22:58

Coffee Mugshot: Jun 26, 2010; by Lowtax

Uses of const_cast and all flavors of dynamic/reinterpret_cast need approval from some team at my company, last I checked

# ? Jan 19, 2018 23:14

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Coffee Mugshot posted:

Uses of const_cast and all flavors of dynamic/reinterpret_cast need approval from some team at my company, last I checked

Are they called "central casting?"

# ? Jan 19, 2018 23:40

eth0.n: Jun 1, 2012

quiggy posted:

Yeah I guess I've just never dealt with a library with problems like that. I have used mutable before but always for actual legitimate reasons like caching and not just because oh gently caress me I need to change this member in a const function.

The latter is a very bad reason to do it, and sets a high risk UB trap. Removing const is only reasonable when you're still going to treat it as const.

Also, if you're writing a member function, clearly you can just fix your class instead of using a workaround.

# ? Jan 20, 2018 01:01

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Coffee Mugshot posted:

Uses of const_cast and all flavors of dynamic/reinterpret_cast need approval from some team at my company, last I checked

In some contexts this is reasonable and in others it really wouldn't be. For example if you have an MFC application that fires up a worker thread and you want the two threads to communicate (I created a small application like this for work last year) then the natural way to do it is by reinterpret_casting the win32 message parameters as pointers to an appropriate struct type. It would be stupid to require oversight for each such usage, though I guess you could give blanket permission for that specific use case.

# ? Jan 20, 2018 14:24

eth0.n: Jun 1, 2012

Hammerite posted:

In some contexts this is reasonable and in others it really wouldn't be. For example if you have an MFC application that fires up a worker thread and you want the two threads to communicate (I created a small application like this for work last year) then the natural way to do it is by reinterpret_casting the win32 message parameters as pointers to an appropriate struct type. It would be stupid to require oversight for each such usage, though I guess you could give blanket permission for that specific use case.

Just use C casts!

# ? Jan 20, 2018 14:30

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Hammerite posted:

In some contexts this is reasonable and in others it really wouldn't be. For example if you have an MFC application that fires up a worker thread and you want the two threads to communicate (I created a small application like this for work last year) then the natural way to do it is by reinterpret_casting the win32 message parameters as pointers to an appropriate struct type. It would be stupid to require oversight for each such usage, though I guess you could give blanket permission for that specific use case.

LPARAM and WPARAM are aliases for intptr_t and uintptr_t respectively so it's a perfectly legal use of reinterpret_cast, too

# ? Jan 21, 2018 18:45

feedmegin: Jul 30, 2008

People still use MFC for new stuff in TYOOL 2018?

# ? Jan 21, 2018 18:49

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

feedmegin posted:

People still use MFC for new stuff in TYOOL 2018?

Well in my case I think you'll find I told you I did it in TYOOL 2017

(most new stuff we do is .NET, this was a new application being added to an old system that is MFC and reusing a lot of already-written C++ library stuff)

# ? Jan 21, 2018 21:05

Xik: Mar 10, 2011; Dinosaur Gum

code:


namespace Redacted.Redacted.Redacted.WebApi.Security

{
    class ApiSecurity

    {
        public static bool VaidateUser(string username, string password)

        {
            if (true)

            {
                return true;
            }

            else

            {
                return false;
            }
        }
    }
}

Phone posting so might not come out good but you get the idea.

Xik fucked around with this message at 01:45 on Jan 23, 2018

# ? Jan 22, 2018 23:22

The Fool: Oct 16, 2003

Phone posting is not an excuse to ignore code tags

# ? Jan 22, 2018 23:42

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

The Fool posted:

Phone posting is not an excuse to ignore code tags

Where's the code? All I see are Russian bots taking over my computer.

# ? Jan 22, 2018 23:52

PhantomOfTheCopier: Aug 13, 2008; Pikabooze!

Use the app that has code block in der bb drop-down? :effort:

Turn phone screen off to reveal horror.

vvv Yay code review worked!

PhantomOfTheCopier fucked around with this message at 04:51 on Jan 23, 2018

# ? Jan 23, 2018 01:15

The Fool: Oct 16, 2003

If this guy can build full websites and java apps on this phone you sure as gently caress can type out [code] every once and a while on your lovely smartphone.

# ? Jan 23, 2018 01:20

Happy Thread: Jul 10, 2005; by Fluffdaddy; Plaster Town Cop

The Fool posted:

If this guy can build full websites and java apps on this phone you sure as gently caress can type out [code] every once and a while on your lovely smartphone.

loving badass article

# ? Jan 23, 2018 01:47

Xik: Mar 10, 2011; Dinosaur Gum

Jesus, it's fixed, enjoy your plain text horror.

E: Guess I spent more effort on that post then the original guy did on the code.

Xik fucked around with this message at 01:49 on Jan 23, 2018

# ? Jan 23, 2018 01:47

CPColin: Sep 9, 2003; Big ol' smile.

That code could use a unit test, though.

code:


[TestCase(true)]
[TestCase(false)]
public void TestValidateUser(bool value)
{
   if (value) assertTrue(value);
   else assertTrue(!value);
}

That's better!

# ? Jan 23, 2018 07:18

canis minor: May 4, 2011

From https://jb-rubinovitz.ghost.io/dark-ux-and-health-insurance/

https://twitter.com/rubinovitz/status/947516118565916672

# ? Jan 23, 2018 15:18

Volguus: Mar 3, 2009

CPColin posted:

That code could use a unit test, though.

code:

[TestCase(true)]
[TestCase(false)]
public void TestValidateUser(bool value)
{
   if (value == true) assertTrue(value == true);
   else assertTrue(value == false);
}

That's better!

Fixed that for you.

# ? Jan 23, 2018 18:40

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

canis minor posted:

From https://jb-rubinovitz.ghost.io/dark-ux-and-health-insurance/

https://twitter.com/rubinovitz/status/947516118565916672

It looks like that button was 'hidden' because something on the server decided it shouldn't be rendered? Without full access to the server code, that doesn't seem to be differentiable between, say, a bug in some rats nest of validation logic that thinks the form isn't complete and intentionally loving with customers trying to submit claims, the latter I'm *sigh* hoping is illegal, but lol.

Also an interesting blog post to me, a doctor-avoiding-american.

# ? Jan 23, 2018 19:02

canis minor: May 4, 2011

Munkeymon posted:

It looks like that button was 'hidden' because something on the server decided it shouldn't be rendered? Without full access to the server code, that doesn't seem to be differentiable between, say, a bug in some rats nest of validation logic that thinks the form isn't complete and intentionally loving with customers trying to submit claims, the latter I'm *sigh* hoping is illegal, but lol.

Also an interesting blog post to me, a doctor-avoiding-american.

For me, making JS decide what is rendered/not rendered is a no (this should be done on the server side) - client side JS should be used to augment UX, not to generate it. You might be correct that it's done on the server side, and JS might be used to construct a query to retrieve additional resource based on JSON, idk, but this doesn't prevent the inquisitive user from altering the JSON whichever way they like and rerunning the function, so what is that accomplishing. (and in this case they could proceed because of the know-how)

Second thing is the way it's done - if the way to accomplish given thing is to pass a large JSON (or whatever really), I'd think twice on ways to accomplish given thing.

But, what I wanted to share is this, that might interest you as well: https://medium.com/backchannel/how-technology-led-a-hospital-to-give-a-patient-38-times-his-dosage-ded7b3688558, a great article about health care that I'm in the middle of reading (and although I'm in UK, I'm worried that these sort of things are not limited to US at all)

edit: also, touching on the original post (although I'd not call these "dark UX", it's just crappy UX) - recently my retirement scheme contacted me, saying that they're switching everybody to paperless and that to get a password I should register using a PIN they've provided and the data that I know of. The problem though is that I cannot register because I'm outside my birth country and the phone number I'm providing doesn't match the validation they've got, because it has too many numbers. So, I'm locked out of having access to my retirement scheme until I get home.

canis minor fucked around with this message at 21:20 on Jan 23, 2018

# ? Jan 23, 2018 20:47

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 01:55

Rubellavator: Aug 16, 2007

I hide buttons like that all the time. Our backend doesn't make any rendering decisions, it just serves and consumes data. If you modify the client to send a bad request, our api won't service it. I don't really see the problem.

# ? Jan 23, 2018 20:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1501 »