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!

«‹›2 »

Victor: Jun 18, 2004

How do I parameterize on the table from which I am selecting, using this wonderful parameterized functionality like every other language/framework out there?

# ¿ Jan 8, 2009 09:27

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 07:10

Victor: Jun 18, 2004

You must have missed that post of passion of mine above. It's ok, it's shorter than what I used to post long ago, so maybe you missed it. Maybe longs posts were good...

# ¿ Jan 8, 2009 10:43

Victor: Jun 18, 2004

Mustach posted:

Explicitly nulling references is worthless 98% of the time, yet it seems to be a pretty popular M.O.

Probably closer to 99.99% of the time. The CLR/C# compiler/whatever can figure out the last time that a variable is referenced. I cannot think of a situation where setting a method-local variable to null will help anything. It is cruft.

# ¿ Jan 18, 2009 22:59

Victor: Jun 18, 2004

That Turkey Story posted:

And examples of where, in practice, && and || are overloaded perfectly fine are lambda EDSLs like Boost.Phoenix. I think I'm aware of your stance on expression templates, though, so I assume I'm talking to a wall at this point.

Perhaps this is ok explicitly because the Boost folks reconstruct the short-circuiting behavior? Search for 'short-circuit' in operators.hpp.

# ¿ May 7, 2013 22:37

Victor: Jun 18, 2004

That Turkey Story posted:

It's only doing short-circuiting of the deferred operation, as you would except. The actual operands aren't short-circuited, nor would the term "short-circuiting" on the top-level really make any sense in this context, as is often the case when overloading these operators.

Wait a second, so if I take a bunch of code and switch it to the deferred execution model, it silently switches from short-circuiting to not short-circuiting? How is this anything but bad? How many people are going to realize, "oh, since this is a lazy evaluation library, && and || are no longer short-circuited"?

# ¿ May 7, 2013 23:41

Victor: Jun 18, 2004

That Turkey Story posted:

No. The deferred operation is still short-circuited, just like you would expect. It's the top-level operation that's not short-circuited. Again, "short-circuiting" doesn't even make sense in this domain other than with respect to the deferred operation.

Edit: An example:
code:
int main()
{
  auto function = ( arg1 != 0 ) && ( 1 / arg1 != 1 );
  function( 0 ); // This will not cause a divide by 0
}

I admit that I don't know how they accomplish this and I'm not sure I'm sufficiently interested to find out how. I admit your example has become motivating, but for a single reason: it preserves short-circuiting. There is no surprise with the example code above. I'm not sure anyone here would be unhappy with that instance of overloading || and &&.

# ¿ May 8, 2013 04:14

Victor: Jun 18, 2004

shrughes posted:

Note that (arg1 != 0) && (1 / 0 != 1) would crash. And (arg1 != 0) && my_retarded_expression_builder() would exhibit all the side effects of my_retarded_expression_builder().

Ahh. Then there isn't as much C++ wizardry as I thought�I was kinda wondering how one could deal with the case you brought up. Thanks for misleading me, TTS! I have concluded that overloading || and && is dumb, if you care about maintainability and/or readability. Some people admittedly don't.

# ¿ May 8, 2013 05:42

Victor: Jun 18, 2004

That Turkey Story posted:

??? What? How is that misleading? It's exactly what he and I have both been saying repeatedly. We weren't even in disagreement.

That said, if for some reason you did want this [nonsensical] code to work, you could -- just make the offending part dependent on an actor.

It was misleading to show me an example where the short-circuiting behavior looks like it works as expected, because it has a variable in it that I'm guessing gets lifted to a lambda and therefore execution is both deferred and short-circuited. It's misleading because if you don't have a variable there that gets lifted (or whatever the term is), you lose the short-circuitedness. Whether or not the code is short-circuited depends on whether or not you have a variable in there. Who will automatically know this? Non-overloaded-&& C++ doesn't do this. It seems like the makings for a bug that could take days to track down. Operator overloading is suppose to decrease cognitive load and make code easier to read, not the opposite.

# ¿ May 8, 2013 17:31

Victor: Jun 18, 2004

That Turkey Story posted:

It's not "good taste," it's the only way to do it. Be thankful that Paul Mensonides did that, otherwise you wouldn't have a lot of the high-level libraries that exist in C++.

Would you mind posting a few links that explain how this was the only way to do it? I'm just starting to get into template metaprogramming, mostly by examining code my boss is writing. I do have a bit of experience with Haskell and Scheme.

# ¿ May 8, 2013 18:29

Victor: Jun 18, 2004

That Turkey Story posted:

It's mostly due to the fact that prior to C++11 there was no way to create "variadic templates" (templates that can take any number of parameters).
[...]
The issue is that the C and C++ preprocessor is extremely limited. You can't loop, you can't recurse, you can only do basic mathematical operations in certain contexts, etc. Basically, all that you can really do is concatenate tokens and use those concatenated tokens to result in the names of other macros that you can then expand. Remarkably, with this tiny bit of functionality, you can actually create containers and high-order algorithms, lambda functions, etc. but it requires the preprocessor code that's written to have redundancy. So in the end there is redundancy somewhere, but now the redundant code is generic and able to be used by any number of libraries that require variadic templates. It also, perhaps most importantly, is a library that is maintained by someone other than the person creating the library that needs variadic templates. It "just works." Now in C++11 we have direct support for variadic templates so you don't need to do the preprocessor stuff for them, although there are still other places where the preprocessor library is useful.

The point is, in the early 2000s the community was faced with a problem: either you just don't have things like tuple types and wait until the next standard (which came a decade later) or you manually maintain monstrous libraries that have considerable redundancy. The existence of the preprocessor library provided a third option -- have concise, maintainable libraries the remove the top-level redundancy by using the preprocessor.

Of course, this leaves you with people like myself, who would gladly use libraries like the tuple library back in the early 2000s because it's a tool that fits our needs, and people like Suspicious Dish (not meant as an insult) that do not want to use these libraries because of all of the hackiness going on behind the scenes -- What happens if something goes wrong? Do I want to have to trudge through preprocessor code? Is using the tool worth the other potential headaches?

Ahh, this makes more sense. Oddly enough, I was wondering about whether variadic templates were possible last night. Pre-C++11, I'd probably have made the decision based on how likely my dependence on them would result in horrible error messages. My experience with dealing with the CPP is that it's a PITA; are there ways of doing it that aren't obtuse? Even using C++ templates to do metaprogramming is obtuse; it's pretty hilarious to see my boss' ML code that explains what the templates are doing. Quite a bit more concise!

# ¿ May 8, 2013 20:51

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 07:10

Victor: Jun 18, 2004

That Turkey Story posted:

Unless the language completely changes, compile-time metaprogramming will always be a mess. Even features like constexpr do very little for anything but trivial metaprograming tasks.

That's really unfortunate. One of the things my startup is trying to do is a C++ embedded library that compiles down to the same thing C would, but with the additional type safety and nicer syntax that C++ can give you.

# ¿ May 8, 2013 23:32

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!

«‹›2 »