The absolute state of web storage protocols

[Arantor]

@dkf I didn’t suggest they were related, merely that C is shit, C++ is trying to be better irrespective of what shit was caused by or inherited from C, and not necessarily succeeding at it.

I could have put PHP in there because it’s written in C, was envisaged to be a C-like for making simple websites and it wouldn’t change the point.

[dkf]

@topspin said in The absolute state of web storage protocols:

@dkf because C++ gives you at least some tools to avoid C's shitness, but not vice versa.

C++ mostly ignores the problems with C and instead bolts it's own problems on top.

[topspin]

@dkf sure, such as type safety, memory management, C strings, just to start at the very bottom.
C can't even get void* sound.

[dkf]

@topspin said in The absolute state of web storage protocols:

@dkf sure, such as type safety, memory management, C strings, just to start at the very bottom.
C can't even get void* sound.

C isn't too worried about soundness, and void* is all about telling the compiler to shut up and mutate the pointer type as necessary.

Real flaws in C are things like the complete lack of definition of which end of the word a bitfield number counts from; right now, they're basically useless in any interface that faces outside of a piece of code, either towards the user or towards the OS or hardware. Try talking to a C committee member to find out more bits of horror.

OTOH, #embed was done and there's a chance that defer might happen. That would be nice.

[topspin]

@dkf said in The absolute state of web storage protocols:

C isn't too worried about soundness

C++ mostly ignores the problems with C

"Except the obvious ones we don't care about"

@dkf said in The absolute state of web storage protocols:

there's a chance that defer might happen. That would be nice.

So basically a worse form of RAII, which C++ had before it was called C++ yet.

[Mason_Wheeler]

@topspin said in The absolute state of web storage protocols:

Not in the sense that the worst sins of C++ are those inherited from C.

Many of them, yes, but the absolute worst sin of all is the abomination that is Templates, and that didn't come from C!

[dkf]

@Mason_Wheeler said in The absolute state of web storage protocols:

@topspin said in The absolute state of web storage protocols:

Not in the sense that the worst sins of C++ are those inherited from C.

Many of them, yes, but the absolute worst sin of all is the abomination that is Templates, and that didn't come from C!

The biggest problem with templates is the fact they can have non-type parameters that you can do some computation with. That's just such a huge can of worms. A close second is the "try it and see what works" approach to template resolution. (The non-single-rooted type hierarchy doesn't help either, but that's a lesser sin.)

[Mason_Wheeler]

@dkf Yup. That and the fact that it makes the language's grammar formally undecidable.

[topspin]

@Mason_Wheeler and yet they’re better than macros or generics. Granted, the error messages suck.

[dkf]

@topspin said in The absolute state of web storage protocols:

@Mason_Wheeler and yet they’re better than macros or generics. Granted, the error messages suck.

better

[Mason_Wheeler]

@topspin said in The absolute state of web storage protocols:

@Mason_Wheeler and yet they’re better than macros

I know of three very distinct systems called "macros" from three different programming languages. Which one are you referring to?

or generics.

Categorically wrong. Generics are vastly superior to templates in many ways, particularly usability, aka

the error messages suck.

(That's a far bigger deal than you make it out to be here.)

Resolution is also a serious issue. As @dkf mentioned, SFINAE (the "try it and see what works" method used by C++) is a severe problem with templates. "SFINAE vs. constraints" is exactly equivalent to "duck typing vs. static typing," and SFINAE shows all of the problems that make duck typing terrible, made exponentially worse by templates being Turing-complete-by-accident.

[topspin]

@Mason_Wheeler said in The absolute state of web storage protocols:

@topspin said in The absolute state of web storage protocols:

@Mason_Wheeler and yet they’re better than macros

I know of three very distinct systems called "macros" from three different programming languages. Which one are you referring to?

Context matters. The macros which are just text substitution.

or generics.

Categorically wrong. Generics are vastly superior to templates in many ways, particularly usability, aka

You mean besides being less powerful.

the error messages suck.

(That's a far bigger deal than you make it out to be here.)

Resolution is also a serious issue. As @dkf mentioned, SFINAE (the "try it and see what works" method used by C++) is a severe problem with templates. "SFINAE vs. constraints" is exactly equivalent to "duck typing vs. static typing," and SFINAE shows all of the problems that make duck typing terrible, made exponentially worse by templates being Turing-complete-by-accident.

You’ll be pleased to learn about concepts.

[Mason_Wheeler]

@topspin said in The absolute state of web storage protocols:

@Mason_Wheeler said in The absolute state of web storage protocols:

@topspin said in The absolute state of web storage protocols:

@Mason_Wheeler and yet they’re better than macros

I know of three very distinct systems called "macros" from three different programming languages. Which one are you referring to?

Context matters. The macros which are just text substitution.

So C macros. OK, I'll give you that.

or generics.

Categorically wrong. Generics are vastly superior to templates in many ways, particularly usability, aka

You mean besides being less powerful.

the error messages suck.

(That's a far bigger deal than you make it out to be here.)

Resolution is also a serious issue. As @dkf mentioned, SFINAE (the "try it and see what works" method used by C++) is a severe problem with templates. "SFINAE vs. constraints" is exactly equivalent to "duck typing vs. static typing," and SFINAE shows all of the problems that make duck typing terrible, made exponentially worse by templates being Turing-complete-by-accident.

You’ll be pleased to learn about concepts.

Yes? What about them?

[cvi]

@dkf said in The absolute state of web storage protocols:

The biggest problem with templates is the fact they can have non-type parameters that you can do some computation with. That's just such a huge can of worms.

Being able to do computations and not just dumb substitutions with it is one of the major features with the system. Though, nowadays, you can do many of the computations in a constexpr function, which can make the code quite a bit nicer.

That said, even if C++ templates wouldn't accept non-types, you could just do it yourself (start with the basic axioms of numbers and go from there). Better not to have everybody invent that from the ground up.

[Applied Mediocrity]

So nice. It's been quite some time since we had a good about C++

[dkf]

@cvi said in The absolute state of web storage protocols:

That said, even if C++ templates wouldn't accept non-types, you could just do it yourself (start with the basic axioms of numbers and go from there). Better not to have everybody invent that from the ground up.

It's better to gave your compike-time type/template system be practically tractable instead of having identical power to a programming language. Types are supposed to make things easier, after all.

If you really want full programming power in your code generation, use a proper programming language. Then you can do things like making bindings for discovered network services without having to hide what you're doing inside what's become the world's slowest scripting language; I really don't want to think about how Boost would achieve that trick...

(Part of my coding time today was spent adding to the world oversupply in SFINAE template bullcrap. Possibly coming to a testing framework near you...)

[topspin]

@Mason_Wheeler said in The absolute state of web storage protocols:

@topspin said in The absolute state of web storage protocols:

You’ll be pleased to learn about concepts.

Yes? What about them?

They constrain the templates.

[Mason_Wheeler]

@dkf said in The absolute state of web storage protocols:

If you really want full programming power in your code generation, use a proper programming language. Then you can do things like making bindings for discovered network services without having to hide what you're doing inside what's become the world's slowest scripting language; I really don't want to think about how Boost would achieve that trick...

This, exactly this, ideally in the language itself. (No, C++ does not do this. Template is not C++; it is a sub-language contained within C++.)

Lisp macros do this badly. Boo macros do this well. C++ templates have no good way to do this at all.

[topspin]

@Mason_Wheeler said in The absolute state of web storage protocols:

No, C++ does not do this. Template is not C++; it is a sub-language contained within C++.

But "prefer composition over inheritance" is word salad. Ookay.

[Mason_Wheeler]

@topspin What do you mean by that? The template meta-language, which is a scripting language executed by the C++ compiler to help the compiler produce types, is not the same as the C++ language, which is a programming language that gets compiled to produce machine code.

[HardwareGeek]

@dkf said in The absolute state of web storage protocols:

the complete lack of definition of which end of the word a bitfield number counts from; right now, they're basically useless in any interface that faces outside of a piece of code, either towards the user or towards the OS or hardware.

Yes. As a person who has written a lot of C that interfaces with hardware, I have almost never used C bitfields. The bit fields are made with uint32_t and explicit ands, ors, and shifts, because the arrangement of the bitfields isn't well defined.

[dkf]

@HardwareGeek said in The absolute state of web storage protocols:

the arrangement of the bitfields isn't well defined.

I discovered that it is defined by the ARM ABI. Which helped a lot; I was dealing with some really gnarly custom hardware (as part of rewriting some of the firmware to be easier to comprehend). You still needed to be careful, but at least one bug (a wrong shift on a rare code path) was fixed in the process...

[LaoC]

@HardwareGeek said in The absolute state of web storage protocols:

@dkf said in The absolute state of web storage protocols:

the complete lack of definition of which end of the word a bitfield number counts from; right now, they're basically useless in any interface that faces outside of a piece of code, either towards the user or towards the OS or hardware.

Yes. As a person who has written a lot of C that interfaces with hardware, I have almost never used C bitfields. The bit fields are made with uint32_t and explicit ands, ors, and shifts, because the arrangement of the bitfields isn't well defined.

If you could at least make them arbitrary size, but nooo …

[Bulb]

@Gustav said in The absolute state of web storage protocols:

@Bulb said in The absolute state of web storage protocols:

Besides, std::function is based on inheritance. It could be based on interface implementation, but C++ does not distinguish the two.

If nothing ever inherits anything from anything, it's not inheritance. I'm reading the source code of <functional> right now and so far, despite inheritance syntax being used, I don't see a single inherited field or method. Not even interface implementation. It's all template magic. Even if it looks like subclassing, it's also just template magic because the base class is absolutely empty except for a few typedefs.

The function itself is a smart pointer, so that one does not need subclassing. It only exists to avoid giving you a pointer that you'd have to manage. But inside is a polymorphic adapter for the closure that implements a suitable interface.

I talked about things based on concepts, which means mainly the algorithms library, which has been there from the start.

AFAIK algorithms are the last part of STL that was implemented, and half of it was only added in C++11. But like with the whole STL, I might be wrong here.

A lot of the actual algorithms were added later, but that is completely irrelevant, because some were there from the beginning and were already based on concepts from the beginning. Even though they were not yet even called that, the concept name only stabilized later with the concepts proposal.

And note that even the streams do use concepts for a lot of their functionality, and that part is quite good. Even the approach to mix-ins in the streambuf—the one that is not possible in Java, because Java does not have virtual private methods—is relatively good.

It's really just the way the stream hierarchy forces it to just have one streambuf for both read and write that's weird, and that's a limitation of inheritance and the way it is thrown into the mix here.

[Gustav]

..