Posted inExperience / Information Technology

The Danger of Tuples

seasoned_geek by seasoned_geek
Girl with Basket by Alice

No matter how much academics and the industry tries to shit on BASIC, C++ and every other newer language tries to move closer to it. Tuples are the re-introduction of a very bad thing. Well, not so much bad as highly abused. To understand my viewpoint you probably need to read page 4-100 (page 278 in the PDF) of this manual.

FIELD

The FIELD statement originated in BASIC/PLUS on the PDP-11. Might have started with original BASIC but honestly I cannot remember. These machines had their hay day in the 1970s. Every file had a channel number. You could have any number of FIELD statements mapping the channel record buffer to strings. One of the most common primary mappings was:

FIELD #7%, 512% AS R$[127%] = 4%
FIELD #7%, 512% AS D$[64] = 8%

We used % to indicate an integer value or variable. For those who don’t speak BASIC, this says to field the 512 byte record buffer for channel number 7 as an array of 4 byte fixed length strings named R$. BASIC had a zero element and 128*4 = 512. You had to use various CVT functions to convert binary data into the strings. The second FIELD statement views the record buffer as an array of fixed length 8 byte strings, in case you had to store a double.

Unnamed Structures and Unions

Gcc still supports unnamed structures and unions but the industry has railed against these for decades. You end up with stuff that is impossible to debug and has zero documentation. Think I’m kidding? Go into any shop that has unnamed structures and unions in their code base. Just try to find documentation for them. Better still, add Doxygen comments for those fields and see what the diagram looks like that gets generated.

One C’s big selling points back in the K&R days was that we were going to have a portable Assembly language that got rid of unnamed shit. Today, with templates and auto you kids are going right back into the septic tank! Tuples is just paddling faster towards it.

Tuples

For those of you who don’t know what Tuples are, here is a little program I put together in Eclipse as a CMake project.

#include <iostream>
#include <tuple>

#include "config.h"

using namespace std;

int main(int argc, char **argv) {
    // Declaring tuple
    tuple <char, int, float> myTuple;

    // Assigning values to tuple using make_tuple()
    myTuple = make_tuple('a', 10, 15.5F);

    // Printing initial tuple values using get()
    cout << "The initial values of tuple are : ";
    cout << get<0>(myTuple) << " " << get<1>(myTuple);
    cout << " " << get<2>(myTuple) << endl;

    // Use of get() to change values of tuple
    get<0>(myTuple) = 'b';
    get<2>(myTuple) =  20.5;

     // Printing modified tuple values
    cout << "The modified values of tuple are : ";
    cout << get<0>(myTuple) << " " << get<1>(myTuple);
    cout << " " << get<2>(myTuple) << endl;
 	return (0);
}

Real programmers who got actual degrees from good schools and know valid Software Engineering (which doesn’t include Agile) would never use this outside of a function. They most definitely would never pass it anywhere.

Why?

Because we lived through maintaining code of the 1970s using FIELD. You had to have a pile of paper documentation showing you just how every record was mapped and you had to guess which FIELD statement to use. If you want to get some idea what that was like read section 3.3 Magic Numbers in this book. God forbid someone changed one of those FIELD mappings without giving you a new pile of paper because you could CVT anything into a record buffer. If you were off a byte, nothing would tell you. We had such constrained resources (64K-Words) that we couldn’t even have defined constants. You had to know that R$[22%] was the order quantity.

C had to have unions because we had (and still do) low level hardware that needs bits flipped. Sometimes they need an unsigned long, other times 1-4 characters, and once in a while they need a float. All depends on what mode they are in.

What happens when you make one little change/mistake?

#include <iostream>
#include <tuple>

#include "config.h"

using namespace std;

int main(int argc, char **argv) {
    // Declaring tuple
    tuple <char, int, float> myTuple;

    // Assigning values to tuple using make_tuple()
    myTuple = make_tuple('a', 10, 15.5F);

    // Printing initial tuple values using get()
    cout << "The initial values of tuple are : ";
    cout << get<0>(myTuple) << " " << get<1>(myTuple);
    cout << " " << get<2>(myTuple) << endl;

    // Use of get() to change values of tuple
    get<0>(myTuple) = 'b';
    get<2>(myTuple) =  'F';

     // Printing modified tuple values
    cout << "The modified values of tuple are : ";
    cout << get<0>(myTuple) << " " << get<1>(myTuple);
    cout << " " << get<2>(myTuple) << endl;

 	return (0);
}

Yes, that compiled and ran. You kids are putting yourselves right back in the shit. This will easily slide through a code review. There is no good way to document that element 2 is “interest rate.” A tuple doesn’t have a hard limit. You can have “any number of elements.” Just how in God’s green earth are you going to keep that straight? We had official paper record layout forms we had to create so we could wade through the nightmare swamp.

One final nightmare

std::array<std::string, 255> a;
auto b = std::tuple_cat(a);

Good luck with that. Better still, relive the 1970s in modern C.

    union chunk
    {
    	long x;
    	char y[4];
    	float z;
    };

    std::array<chunk, 128> arr;
    auto b = std::tuple_cat(arr);

Yes, that compiled. You too can have a 512 byte buffer and no idea of what is in it two months after you wrote it.

Data without a relationship is a bad thing.

In the current decade of my career, I make medical devices. Yes, I’m an asshole when it comes to code quality. Even though I have helped create an infusion pump, I don’t have patient deaths tied to any of my projects. Baxter can’t say that.

Abstraction, just because you can or think it is cool, will get someone killed. Agile with or without abstraction most definitely will.

Career Tip

If you are interviewing for a project I (or anyone senior) is staffing and you tell us about all of the Leetcode (or other hacking site) problems you have solved, you will remain unemployed. Those sites teach lazy shortcut things like this and we only hire professionals because people’s lives are at stake.

Roland Hughes started his IT career in the early 1980s. He quickly became a consultant and president of Logikal Solutions, a software consulting firm specializing in OpenVMS application and C++/Qt touchscreen/embedded Linux development. Early in his career he became involved in what is now called cross platform development. Given the dearth of useful books on the subject he ventured into the world of professional author in 1995 writing the first of the "Zinc It!" book series for John Gordon Burke Publisher, Inc.

A decade later he released a massive (nearly 800 pages) tome "The Minimum You Need to Know to Be an OpenVMS Application Developer" which tried to encapsulate the essential skills gained over what was nearly a 20 year career at that point. From there "The Minimum You Need to Know" book series was born.

Three years later he wrote his first novel "Infinite Exposure" which got much notice from people involved in the banking and financial security worlds. Some of the attacks predicted in that book have since come to pass. While it was not originally intended to be a trilogy, it became the first book of "The Earth That Was" trilogy:
Infinite Exposure
Lesedi - The Greatest Lie Ever Told
John Smith - Last Known Survivor of the Microsoft Wars

When he is not consulting Roland Hughes posts about technology and sometimes politics on his blog. He also has regularly scheduled Sunday posts appearing on the Interesting Authors blog.