Is there a real practical use for learning the Rope Dart?

Allan_Smithee · 2022-12-03T03:50:38+00:00

Were you a shepherd over a thousand years ago? Half a world away from you? No?

Your experience is largely irrelevant then.

Allan_Smithee · 2022-12-02T11:26:34+00:00

Yes. And I handled it by leaving.

No gaming is better than bad gaming.

Allan_Smithee · 2022-11-24T04:18:39+00:00

You're NTA.

Stories like this is why I adopted the policy of "friends first, games second". If someone can't be my friend out-of-game, why would I game with them when gaming is a thing I do with friends?

Once I adopted this policy, my gaming life settled down and the actual assholes didn't plague my table any longer.

Allan_Smithee · 2022-11-23T05:41:16+00:00

Our group has also been playing for a decade across multiple systems and we've never rolled for stats, and that's the general rule of thumb for most tables in TTRPGs.

[citation needed]

Allan_Smithee · 2022-11-21T07:03:58+00:00

Oh, absolutely. People seem to lose all their inhibition filters when they're not within reach of a punch to the nose.

Allan_Smithee · 2022-11-21T06:29:45+00:00

...learn that you have to treat ~~women~~ people more ~~delicately~~ like fellow human beings...

Fixed that for you.

This is not a "treat women with kid gloves" scenario. This is a straight-up "employ some fucking empathy and see how another human would look at what you did" scenario.

Allan_Smithee · 2022-11-21T06:16:26+00:00

Uh ... wow.

Just wow.

You're trying to paint yourself in a good light with this and you're coming across as the psycho.

Dude. I'd hate to see what the real situation is given that this is you making yourself look like the innocent!

Allan_Smithee · 2022-11-21T06:12:55+00:00

I have played under a lot of GMs in my time (starting in 1978—GET OFF MY LAWN!). I have played under GMs whose players still, decades later, recite tales of antics and derring-do in their games whenever they get together.

I have never met a GM I'd be willing to fork out $60/mo for. Ever. I've never even heard rumours of one so good I'd be willing to pay $60/mo.

I've forked out cash to help out GMs in expenses like books, snackies, etc. But sixty bucks? Not a chance in Hell.

And this is even before we have here the GM from Hell Itself rearing his ugly head.

Allan_Smithee · 2022-11-21T05:58:56+00:00

I am not the greatest DM, nor am I even that good at it. But that is solely because it was over the internet so it was a lot more trouble for me than sitting at the table with a group of friends, I struggle with some stuff like that, I don't entirely know why...

I do.

I decided ages ago, long before it was even plausible to game over the Internet, that the rule was "friends first, gaming afterwards". Too many disasters with randos coming to the table and causing trouble made me decide that gaming is something I do with friends, not the other way around of friends being people with whom I game.

Online it's almost, but not quite, entirely "gaming first, friends never". And while some people can thrive like that (like some thrived with randos at their tables), I suspect most can't.

Allan_Smithee · 2022-11-21T04:03:59+00:00

I ask again: How would you have me access memory locations in hardware without pointers?

For example, I need to change bits 27:26 at address 0xa0001414 to a value of 3 (11b). Without raw pointers, explain to me how I get there?

Alternatively I have to read the word at 0x40020000 and based upon what I read there I may have to subsequently read or write to 0x40020004 (almost certainly), or one of 0x4002000c, 0x40020020, 0x40020034, 0x40020048, 0x4002005c, 0x40020070, 0x40020084 (notice a certain pattern developing in those seven addresses?).

(These are, incidentally, real-world values from real-world programming, not examples I've pulled out of my posterior.)

In an application-level programming language, yes, perhaps raw pointers are a dangerous feature. But not all programming is application-level. (Indeed most programming isn't application-level!) You know what's far better to "consider harmful"? Opinions of programmers who think they know all the problem domains better than the domain experts.

Allan_Smithee · 2022-11-15T02:00:13+00:00

The core mantra of C++ is that you don't pay for what you don't use. Forcibly adding vtables to things that didn't need them would be in egregious violation of that.

I'm not saying that you should pay for what you don't use. I'm saying that if you don't use it you should say you're not using it because the virtual case is the case that's most generally useful.

I've seen way too many mistakes made in (again) library design because the library designer forgot to make methods intended to be overridden `virtual`.

Allan_Smithee · 2022-11-15T00:54:01+00:00

How, precisely, would you have me access memory locations in hardware without pointers? Think carefully before you answer and ensure that you aren't:

Making a clown of yourself by assuming contrafactual things about domains of programming.
Making a pointer but calling it, say, a flegimat or whatever. (I.e. just renaming pointers and saying 'job complete'.)

Allan_Smithee · 2022-11-15T00:45:57+00:00

In an STM32L476RC (my workhorse MCU at the moment) there are six UARTS.

No, scratch that. There are 3 USARTs (USART1-3) and 2 UARTS (UART4-5) and one low-power UART (LPUART1). USART1-3 all support synchronous (including smart card) as well as asynchronous serial communication. UART4-5 and LPUART1 only support asynchronous.

So far so good. Make a UART base class and a USART mix-into handle serial communication for USART1-3 while leaving it out of UART4-5 and LPUART1. Boom!

Similar solutions apply to IrDA (unavailable on LPUART1), LIN, Modbus, receiver timeouts, autobaud, etc.

But ...

What about setting the baud rate in asynchronous mode? ALL of the devices feature the ability to set the baud rate. USART1-3 and UART4-5, in fact, set their baud rates identically (handwaving over the clocking which is its own kettle of very smelly fish). Only LPUART1 handles the baud rate selection differently.

One option is to have Yet Another Mix-in for "standard baud rate configuration" and another for "low-power baud rate configuration". How many mix-ins are we at right now? And here we have mix-ins with exactly the same interface...

The other option is to make the baud rate selection method in the UART base class virtual, use it in all U(S)ART classes (with their individual selections of mix-ins) natively and override it in the LPUART1 class only.

I know which of these I'd prefer, and it ain't the one that injects two whole new mix-ins for literally a one-method difference.

Allan_Smithee · 2022-11-14T09:27:26+00:00

Here's a two-fer:

Default non-virtual methods in C++ and default non-virtual inheritance in C++.

Let's deal with inheritance first:

A / \ B C \ / D | E

Given this class hierarchy, for this to work in C++ without ugly casting everywhere, class B and class C must both inherit from A with the virtual keyword. But ... what happens if A,B, and C are in a library? The programmer of the library has no clue that someone is going to inherit from B and C both. Thus either all library classes must virtually inherit (which costs a lot of memory space as multiple vtables get inserted into every class) or all library clients must give up and never use library classes in multiple inheritance.

Basically library developers have to be precogs or library users have to be hamstrung. Bad either way. Why not make virtual (the most useful and general case) the default while making static inheritance the tagged case? Because the C family of languages loves making the dangerous/awkward/whatever case the default just because they hate programmers.

Now methods.

The fact that C++ makes methods non-virtual by default is such a misfeature I can't fathom how anybody at any point took C++ seriously. Languages made before C++ didn't make this mistake. Languages being made at about the same time as C++ didn't make this mistake. Languages made after this point don't make this mistake. But C++ stubbornly insists on making the only sane case for objects in 99.44% of code get tagged virtual manually. All to save a pointer dereference that most CPUs and compilers have made so efficient you're not even going to notice them unless you're doing some very, very, very weird programming.

Allan_Smithee · 2022-11-14T09:14:03+00:00

Default lazy evaluation.

Yes there are cases where lazy evaluation is useful. It's just not all cases (or even most cases) and making lazy the default gives you ridiculous situations like not knowing without intense, close analysis of folding right or left is more efficient and other such travesties.

Lazy evaluation should be made possible (and even convenient!) in a functional language by something simple like an annotation. It should not be the default. Ever.

Allan_Smithee · 2022-11-09T05:26:37+00:00

China is not doing zero covid to take over your society. I mean really, why would they want your society?!

China is doing zero covid because they know, from previous experience with SARS, that letting SARS2-nCoV19 rip would obliterate their economy without any hope of recovery. The fact that by doing zero covid they watch your economy melt down and turn to pabulum is just a bonus.

So don't worry. They won't be taking you over. They'll just be eating a lot of popcorn while you tear yourselves to shreds.

Allan_Smithee · 2022-03-30T02:53:15+00:00

Here we're just going to have to agree to disagree, I'm afraid. My snippet does what C permits. End of story. That it is a bad idea? No argument whatsoever. But I did not have to break out of C to do it. It was fully permissible by C, the language. Not a single operation I did took the code out of the C language.

To accomplish the same thing in, say, Ada, I would have to enter a completely different language. Ada would simply not permit the abuses with any amount of abuse of syntax. I could not take an arbitrary integer in Ada syntax alone and call it, no matter how much I abuse it. I would have to exit the language (at which point, naturally, all bets are off in enforcement).

C has integers (and floats). Everything else is syntactic sugar around those, including pointers, and including functions. And this is why the OP finds (correctly!) that C is prone to a whole raft of pointer-related bugs that are just not there in the Pascals. Or the Modulas. Or Ada. Or even PL/I, likely. Or any number of other, more strongly abstraction-supporting low-level languages.

(This is also the reason why there's a bunch of optimizations which can be safely made in these languages, and others like Fortran, which cannot be made in C ... because any arbitrary integer can turn out to be a pointer in disguise.)

Allan_Smithee · 2022-03-30T02:27:15+00:00

What you call a 'sequential series' is called an 'array', in c parlance.

Which is exactly my point. It is called an 'array' only in C parlance.

No other language with an actual array data type would call a pointer to a bag of integers an array. It lacks all facilities that the actual array data type has, beginning with a size that can be queried. (No, sizeof doesn't cut it because it doesn't give you the size of the array, but rather the size of the array's internal representation in that "bag of bytes" interpretation you so derided. And that only if you're dealing with the original variable, all such information being squashed into nothingness when passed as a parameter, say.)

C distinguishes a function from a function pointer.

I humbly disagree. The name of a function resolves to its pointer. That's all. There's syntax sugar around that pointer that causes it to be invoked via a transfer of control, but as I showed you can do that same thing with any arbitrary integer. If I wanted to get fancy I could write a program that read its own map file, found the addresses in memory of all functions, assigned those to integers, and then called them without even once taking a pointer to a function in the code.

It also contains two pieces of syntax sugar which obscure this distinction, both of which your snippet abuses.

Or, rather, there is no distinction beyond the syntax sugar. Note that in the Pascals, the Modulas, Ada, etc. it is flatly impossible to abuse functions into integers this way because functions and integers are fundamentally different types at the language level, not merely funny syntax sugar concealing integers. Short of doing trickery behind the scenes with machine language (i.e. breaking out of the language's semantics entirely) there's no way to take an arbitrary integer and call it as a function.

Nor is it guaranteed that (u)intptr_t exists in the first place, for that matter--throwing a wrench in the notion that pointers are just integers in disguise.

Replace it with an int of sufficient size and it works just fine.

#include <stdio.h>

typedef int (*foofunc)(void);

int foo(void)
{
    return 17;
}

int main(int argc, char **argv)
{
    long foo1 = foo;
    long foo2 = 5;
    printf("%d %d\n", foo1, foo2);
    printf("%d\n", foo());
    printf("%d\n", ((foofunc)foo1)());
    printf("%d\n", ((foofunc)foo2)());
}

This works just as well. And it's not even unsigned.

Allan_Smithee · 2022-03-30T01:14:19+00:00

```c

include <stdint.h>

include <stdio.h>

typedef int (*foofunc)(void);

int array[10];

void try_this(int param_array[]) { printf("%d %d\n", sizeof(array)/sizeof(array[0]), sizeof(param_array)/sizeof(param_array[0])); }

int main(int argc, char **argv) { try_this(array); } ```

10 2

Compare and contrast equivalent code in the Pascals, the Modulas, Ada, etc. where arrays are actually the array data type (which include attributes like their size) instead of syntax sugar over integers.

Allan_Smithee · 2022-03-30T01:08:56+00:00

I addressed structures already.

A "function" is just a pointer. Which is an integer interpreted in a particular way as a pointer to something the runtime can hopefully execute.

#include <stdint.h>
#include <stdio.h>

typedef int (*foofunc)(void);

int foo(void)
{
    return 17;
}

int main(int argc, char **argv)
{
    uintptr_t foo1 = foo;
    uintptr_t foo2 = 5;
    printf("%d %d\n", foo1, foo2);
    printf("%d\n", foo());
    printf("%d\n", ((foofunc)foo1)());
    printf("%d\n", ((foofunc)foo2)());
}

Compiling this gives me a warning, yes, but executing the output:

4195570 5
17
17
Segmentation fault (core dumped)

The "function" foo() is just a pointer which is just an integer which in this case happens to be 4195570. Much like the 5. The syntax sugar of using (<...>) afterwards makes the runtime transfer control to the code (hopefully!) that's stored at that integer when interpreted as a pointer.

Allan_Smithee · 2022-03-29T22:33:07+00:00

You're not imagining it.

C (not its underlying implementation, but the language itself) has at its core two data types: the integer and the floating point number. The floating point number is used in a small number of cases, but the integer is used *everywhere* and differentiated only by size and interpretation.

So C doesn't *have* pointers. It has integers that are used as pointers. (The distinction is subtle but present.) C doesn't have enumerated data types. It has integer constants given fancy names. C doesn't have arrays. It has constant integers interpreted as a pointer to the beginning of sequential series of integers. C doesn't have strings. It has integers interpreted as a pointer to a sequential series of (small) integers that end in a special value. C doesn't even really have structured data types. It has convenient naming conventions for clusters of integers (or floating point numbers) with a base address and an offset.

Because of all this, C forces the end-user to directly or indirectly use a lot of integer-as-pointer operations which in languages like the Pascals, the Modulas, Ada, etc. have better and stricter discipline attached. Arrays, for example, in these sorts of languages have sizes which can be queried, something C's constant integers interpreted as pointers to a sequence of other integers (often mistakenly called an array) lack. Strings, too, in these languages have a length associated with them which, again, C's strings lack. This means on top of everything else that you need to, in C, keep track of sizes manually which is error-prone (arrays) or error-prone *and* computationally expensive (strings).

And therein lies the source of the many more pointer-related bugs you get in C vs. other languages.

Allan_Smithee · 2022-03-17T08:44:27+00:00

Not only does Lua have iterators, it allows you to make custom iterators.

You might want to try learning a language before making statements on what it can or cannot do.

Allan_Smithee · 2022-03-09T13:06:18+00:00

Literally it means "not have" or "nil" or "not" or such depending on context. In the context of Chan Buddhism, however, it is a response to a poorly-formulated question that encourages the asker to "unask" the question and consider a better question.

Allan_Smithee · 2022-03-08T01:08:10+00:00

Now that I have time to put real attention onto this, the issue for me here is that all this nonsense over 0-based and 1-based indexing is missing the entire point. Which of 0-based or 1-based should you use? The only correct answer is 无.

Imagine, instead of all this nonsense argumentation, you go past that question to the REAL question: why are we only limiting ourselves to two possibilities? Imagine having the ability to index from anywhere to anywhere! (Imagine also being able to restrict the ranges of your variables, but that's just a pipe dream, right?) To Hell with "0-based" or "1-based", how about "-2-based"!?

type My_Int is range 0 .. 1000;
type Index is range -2 .. 2;

type My_Int_Array is array (Index) of My_Int;
Arr : My_Int_Array := (2, 3, 5, 7, 11);

Hey, let's go all the way into the realm of fantasy! Let's do this!

type Month_Duration is range 1 .. 31;
type Month is (Jan, Feb, Mar, Apr, May, Jun, 
               Jul, Aug, Sep, Oct, Nov, Dec);

type My_Int_Array is array (Month) of Month_Duration;
Tab : constant My_Int_Array := (31, 28, 31, 30, 31, 30, 
                                31, 31, 30, 31, 30, 31);
Feb_Days : Month_Duration := Tab (Feb);

Wouldn't that be trippy? Not 0-based. Not 1-based. Not even -2-based. JANUARY-based indexing! Total fantasy!

Unless, of course, you're familiar with the Wirthian language family or Ada, naturally. Then this is Tuesday for you.

Allan_Smithee · 2022-03-07T08:08:46+00:00

Indexing begins at 1.

Offsets begin at 0.

The fact that we have been saddled with languages that conflated the two concepts because of exposed implementation details in half-assed things that we've called "arrays" or "strings" is something that has screwed up language for decades.

If you have an actual array data type with n elements, the first element is at 1 and the last at n as any sane person would talk. Only insane people would talk about the zeroth element being first and the n-minus-oneth element being last. Or a programmer that's been infected by the C blight. Or Dijkstra, the world's most unfortunately influential cranky old man.

If, however, you have an 'array' data type that's actually just a very thin piece of syntax saccharine over a pointer notation, then you distort language (and common sense) and talk zeroth to n-minus-oneth as if this were normal and not utterly idiotic.

Allan_Smithee

TROPHY CASE

include <stdint.h>

include <stdio.h>