Hacker News Reader

I don’t think you’re too far off with ‘leaving the space of normal C’, but I think it may help to see the context from which the author was coming when writing Cello [1] and evaluating it in that context.

It’s been a while since I watched the talk but I believe his intention was to do just that, to push the bounds of what could be done in a header file purely for the fun of it. The second half of the talk specifically addresses the “why are you doing this?” in quite a charming way.

1: https://youtu.be/bVxfwsgO00o

huh. Interestingly, for "and", "or" and "not", iso646.h already defines C alternative tokens: https://en.wikipedia.org/wiki/C_alternative_tokens

I know :) ... but have you seen anyone actually use those? I'd be curious to get a pointer or two.

I have seen people coming to C++ from Python use "and", "or", and "not" in their if-statements :)

Hah - I kid you not, I have the reverse problem! I work a lot with both C and Python (embedded interpreter & CPython extensions) and whenever I switch from a stretch of C coding to doing some Python, I catch myself typing "&&" and "||" instead of "and" and "or" :D

(C is my "native" language, so it doesn't really happen the other way around, but that's just me)

But honestly, I'm pretty sure we can call iso646.h "fringe" ;)

In programming languages, does we have something akin to a mother-tongue?

There’s a fair bit of debate about the impact of learning specific programming styles as your first language. Quite a few people would argue that learning functional programming first is a benefit to understanding the concept of state and how to write clean code, even if you end up using something less pure.

Certainly, speaking as someone brought up on imperative and later OO code, it took a fair bit of unlearning to understand functional programming, and I still have no clue about type theory.

Curiously, & and | are occasionally useful in Python. They do work properly with booleans, so the difference compared to "and" and "or" is that you don't get short circuiting, which in some very rare cases you might not want. ^ is less useful because it's almost the same as != (except stricter about types) - but it documents the intent more clearly.

what's the problem ? it's legal C++ (https://en.cppreference.com/w/cpp/language/operator_alternat...) and imho more readable than && / ||

We're talking about C here, not C++. The keywords don't exist in C unless you #include "iso646.h"

let me quote you the comment I was replying to :

> I have seen people coming to C++ from Python use "and", "or", and "not" in their if-statements :)

Yet curiously absent from that quoted comment is anything about it being a problem, which you nonetheless ask about. I wonder if more context or a more well-intentioned reading is the solution? ;)

I read and reread it and I honestly don't understand how it is possible to come up with an interpretation where that is not seen as an issue by the author

So what? Unless you include std...h you also need to use _Bool, _Complex and so forth, hardly much different.

But the repo doesn't include them - it defines them itself.

Technically, I believe this is actually UB, just like any other #define for a keyword or an identifier from the standard library.

I don't follow.

When I do #include <stdbool.h> it also brings the #define bool _Bool, a keyword from the standard library.

How is it UB?

It's not UB to #include standard headers that do such things. It is UB to #undef or redefine them yourself, though. And it looks like <stdbool.h> gets an explicit exemption, at least in C11:

"Notwithstanding the provisions of 7.1.3, a program may undefine and perhaps then redeﬁne the macros bool, true, and false"

I guess it's because defining these was so common even before C99. But there's no similar verbiage for <iso646.h>, so...

Twice: once for a CTF challenge that stripped out certain symbols, and one other time when I set up an emulator with a sketchy key map and didn’t want to bother figuring out what those symbols were mapped to.

I've only seen wrong use: CS students working on a project in C++, using "and" and "or" as identifiers (which their local MSVC compiler apparently was cool with) and then being surprised that the course's testing environment (using gcc) found some errors.

I'll admit I've never written more than small programs in C, but the criticism that this "isn't C" isn't a fair criticism to me. He's not doing anything more than any other library can do, were he to write a compiler that mapped directly to really boring C, would it be more or less C than this? I don't feel like those questions are useful. We need experiments like this, and for me personally, cello was a revelation when it was posted here years ago. There are no rules that say you can't do it.

I know he's doing a little hackiness by placing the size before the start of the object, but they also take that approach here (https://www.piumarta.com/software/cola/objmodel2.pdf) so maybe it's not that uncommon. How would you do the dual pointer setup? Is there any overhead from that, or is it small enough to not worry about?

The "isn't C" argument is more about the library as a whole, not specifically about the fat pointer suggestions. (Please look at the github repo, IMHO it's obvious.)

Placing a length "before" a pointer is perfectly fine on a _technical_ level. It's also how glibc's malloc works, it has its own data before any allocation it returns. However, hackiness is not the question here - it's whether it's the "best" approach. I simply believe, based on my own experiences, that twin pointers cover/win out in a much larger subset of applicable scenarios.

As for how to implement it - declare a struct with 2 pointers in it. Or just pass 2 pointers around.

Do you, by chance, know where else object model of Piumarta is used? I think the Per6 VM "Potion" used it too as a base, but I am unsure

Unfortunately, no, your info about Perl 6 is news to me. Only ran into it a few months ago, tried it in Python and Nim, but haven't seen it in the wild. It's very cool though.

http://perl11.org/potion/

> In my personal experience, "a bit more than a pointer" works best as a pair of (start, end) pointers (where "end" points to just beyond the last element.)

There’s a PARC paper from the Cedar team benchmarking base-and bounds vs marker-terminated (e.g. null terminated) strings and base-and-bounds won hands down on a variety of use cases. Won on speed, not just the safety grounds. In those days some people actually worried about the space taken up by the extra bounds variable.

While people did worry about the space taken up by the bounds checking information, systems 10 years older than the PDP-11 had enough hardware resources to support high level systems programming languages with bounds checking data structures, let alone the beefy PDP-11 (by comparison with those older models).

As I know well as a KA-10 MACLISP programmer!

But most people these days have a hard time realizing what it was like to program a machine with only a few K of memory. PL/1 (the Multics implementation language) had bounded strings. C did not as it was believed the PDP-7 couldn't afford it. Of course by today's standards the GE 645 is an absurdly tiny machine.

Yeah, that was my point, this knowledge is getting lost, only to be re-discovered by those that love to dig into computer history.

Just to think that what is now on a ESP32 die took over a complete desk at the high school computer club and was still weaker than what ESP32 is capable of, yet that mentality also persists for what 80's hardware was already capable of.

This is how Go does slices, though they are 3 fields:

    type slice struct {
        zerothElement *type
        len int
        cap int
    }

Though I suspect under the hood the len and cap are ordered first.

If it's good enough for C greybeard Ken Thompson and unix hacker Rob Pike, its good enough for me.

In fact I've looked for a port of go-style slices to C and haven't found one. Maybe people think sds is good enough?

> Though I suspect under the hood the len and cap are ordered first.

A slice is stored in memory as a `reflect.SliceHeader` https://golang.org/pkg/reflect/#SliceHeader ; the pointer does come first.

I actually wrote a (sort of) Go-style slice library. It's a little heavier than Go slices because it allows for dynamic array resizing and tracking the parentage of slices:

https://github.com/jgbaldwinbrown/slice

It's just a proof-of-concept, though, and would need a lot of work to be used in anything serious.

Go has a rather idiosyncratic take on arrays and how they're used, which is reflected in its slices. I can't think of any other language or framework that did it this way.

Rust Vec has the same representation.

Start and end pointers is the approach used by the C++ STL, too.

> Also, this is a huge red flag to me:

Puke! Who would ever want to create that kind of macro abomination.

Bjarne Stroustrup! https://en.wikipedia.org/wiki/C_alternative_tokens

And I'm not even joking :)

Yeah, damn, just found out myself. I thought I knew C inside out, but I guess there are still bits and pieces you just don't encounter very often.

That said, my opinion about those macros is unchanged.

Man Bjarne Stroustrup is like the guy in college who flatly refused to conform in any way whatsoever no matter how good or bad it would have been for 'em. It's more of an oppositional personality disorder ;) That kid grew up and invented, because of course he did, C++.

It might have something to do with various symbols that C uses not being convenient to type in many non-US keyboard layouts. In the standard Danish one, ~|^ all require the use of AltGr.

C++ isn't exactly short on symbols haha

You can do worse: http://oldhome.schmorp.de/marc/bournegol.html

Pretty curious: someone seriously disagrees this header should not exist? I'd really love to hear the arguments!