@Benjamin-Hall oh, then definately
Posts made by Gąska
-
RE: An amusing rant about C
@Benjamin-Hall said in An amusing rant about C:
battle-tested
Financial or scientific number-crunching? I want to know whether is appropriate here.
-
RE: Right to repair sold to the highest bidder
@Zerosquare only if it causes cancer.
-
RE: Right to repair sold to the highest bidder
@acrow said in Right to repair sold to the highest bidder:
I'm surprised the same doesn't apply in the U.S.
Protip: if a law protects an employee or an individual customer, it most likely doesn't exist in the US.
-
RE: An amusing rant about C
@cvi SHOULD, not MUST. Someone so familiar with C macros should know the difference
-
RE: An amusing rant about C
@cvi said in An amusing rant about C:
@dcon said in An amusing rant about C:
That's part of our .clang-format file spec. sigh.
What does that do to a constant like
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_FEATURES_KHR
(83 characters by itself)?Like .. do you have to go all
#define JOIN(a,b) a##b //... foo = JOIN(VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_, SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_FEATURES_KHR);
on it?
My macro-induced paranoia tells me it should actually be
#define JOIN2(a,b) (a##b) #define JOIN(a,b) (JOIN2(a,b))
But I can't tell you the reason why.
-
RE: TIL (about the Dark Arts of HTML)
TIL the Bugs Bunny gag about taking a wrong turn at Albuquerque is derived from a particularly stupid intersection in downtown Albuquerque where Route 66 crossed itself, which made great many people take a wrong turn over the years.
-
RE: The Official Funny Stuff Thread™
@Benjamin-Hall I hope the BRRRRRRT is a full on replica with seven rotating barrels.
-
RE: An amusing rant about C
@djls45 does it speak well of JavaScript's design that programmers managed to build an entire world of SPA, SAAS and cloud applications using it, to the point there's barely any frontend work left on the job market that isn't JavaScript?
-
RE: An amusing rant about C
@djls45 if even 33 years ago people already were writing C very differently than originally designed, isn't that a good indication that the original design was shit?
-
RE: Undefined edited-post definition
@Atazhaia this bug is at least 2 years old. There should be a thread for it already.
-
RE: The Official Status Thread
@Tsaukpaetra other commenters on YT are just as surprised.
-
RE: An amusing rant about C
Although I will say this much because I love throwing quotes from standards in people's faces.
@djls45 said in An amusing rant about C:
A
char
type represents a character, regardless of the actual number of bits used to represent it.Actually no. The C standard defines
char
to be exactly one byte, and a byte to be at least 8 bits and correspond to the smallest addressable unit of the machine.It does now, because an 8-bit byte has become the most common size of byte, but that was originally a POSIX standard. A
char
was defined to be of a size large enough to represent any of the "execution character set."ANSI X3. 159-1989 Programming Language - C, section 2.2.4.2.1 defines CHAR_BIT, "number of bits for smallest object that is not a bit-field (byte)", to be at least 8.
Unless you mean how things were before 1989, when there was no standard at all how C language should work.
Addressable unit of memory is likewise not a perfect descriptor.
Section 1.6 literally says "it shall be possible to express the address of each individual byte of an object uniquely." Again, this is from the original 1989 standard, not any newer revision (although they say the same thing - I checked.)
Edit: and if you really want, I can also find the part where it says consecutive bytes must have consecutive addresses.
-
RE: An amusing rant about C
@djls45 said in An amusing rant about C:
All the complaints so far have been about programmers and how they want to write code, not about C itself.
Have you missed the part about C headers being virtually unparseable?
(Won't reply to the rest of your post because it's like talking to a wall. If you can't understand "I must ensure I can safely store object ID 745884 in memory" is a mission-critical and extremely common requirement, there's no helping you.)
-
RE: Just Souls Things
@Groaner said in Just Souls Things:
@Gąska said in Just Souls Things:
@Groaner said in Just Souls Things:
But there aren't in TFE and TSE, which are quite possibly the best games in the series.
I picked up TSE a few times and every time I get bored after one level and don't come back for months because of how boring it is. You're saying the later games are even worse?
Naturally, that depends on what "boring" means
The gameplay and the level design was just so uninspired that after finishing one level I didn't have a desire to play more. I think I last played the level where you spawn in a pond. It's a fun little game and probably felt much better 25 years ago when it was released, but for me today I just can't play it for more than 15 minutes at a time.
-
RE: TIL (about the Dark Arts of HTML)
@djls45 said in TIL (about the Dark Arts of HTML):
@Gąska said in TIL (about the Dark Arts of HTML):
@Bulb or, you know. You can three-finger-tap.
You also have to know that you can use three-finger gestures.
Same argument for both-mouse-buttons click. And at least on non-Linuxes, three-finger-click seems to be the standard. I don't think you even can enable middle click emulation on Windows and Mac (assuming Mac even has the concept of middle click; they're already poor on right click support).
-
RE: Just Souls Things
@Groaner said in Just Souls Things:
But there aren't in TFE and TSE, which are quite possibly the best games in the series.
I picked up TSE a few times and every time I get bored after one level and don't come back for months because of how boring it is. You're saying the later games are even worse?
-
RE: An amusing rant about C
@dcon said in An amusing rant about C:
@cvi said in An amusing rant about C:
@Carnage It's definitively not for people who like to stick to max 80 characters line width.
That's part of our .clang-format file spec, which is just patently stupid. sigh.
Make use of those characters!
-
RE: WTF Bites
Free internet points to whoever identifies the relatively-well-known publicly available snippet I got this from.
Free internet points to whoever remembers who's always bitching about a suboptimal choice of a constant whenever this snippet is posted.
-
RE: An amusing rant about C
@cvi said in An amusing rant about C:
@HardwareGeek said in An amusing rant about C:
guaranteed power-of-2 dimensions.
Heh. Until recently, I thought that the days of requiring POT dimension had been long over. Then I learned from a colleague that Unity apparently still requires POT dimensions when rendering to textures. Wonder what pre-2003-level hardware they still want to support.
My guess would be newest Radeon. They've still been super picky about what they're willing to work with way into 2010s, and I doubt it has changed since.
A classic tale of workaround standardization: some hardware doesn't support something so developers avoid it like fire, so the hardware developers feel no incentive to ever add support for it.
-
RE: An amusing rant about C
@Groaner said in An amusing rant about C:
@cvi said in An amusing rant about C:
@Groaner said in An amusing rant about C:
This is often a very reasonable assumption, though. Picklists of states/provinces and countries will never have billions of items, and most warehouses, for example, will have trouble picking and shipping more than a billion orders in the service lifetime of the facility.
What about using just 16 bits then? What about 24 bits?
There is this (VkAccelerationStructureInstanceKHR) structure in the Vulkan spec that uses 24-bit integer fields, and that people occasionally trip over and whine about.
24-bit integers aren't an uncommon use case. They're called RGB colors
It's been literally decades since the last time I've seen actual 24-bit RGB. In my experience it's always been either R5G6B5, R8G8B8A8 or R10G10B10A2.
-
RE: D&D thread
@boomzilla said in D&D thread:
I read that headline right after reading the C thread... Invalid alignments, brrrrr
-
RE: An amusing rant about C
@Benjamin-Hall said in An amusing rant about C:
@cvi said in An amusing rant about C:
(VkAccelerationStructureInstanceKHR)
was that named by a diehard Java framework architect?
Design by committee. Literally.
Edit: also, no namespaces. Another thing that makes C naturally painful to use anywhere for anything.
-
RE: An amusing rant about C
@topspin 1841 to be exact.
In my defense, I didn't realize it's going to onebox EVERYTHING.
-
RE: An amusing rant about C
@Groaner said in An amusing rant about C:
Now on to the article...
This Aria person seems to be quite upset about being put in a position where one is expected to solve thorny legacy architectural problems and muddle through difficult decisions while still having to live within suffocating parameters.
That's why we get paid.
As if you never complained on this forum about having to work with legacy code as part of your job. That you get paid for.
The only reason we are able to look back and call out crappy flawed designs (which were good enough back in the day) is that we have the benefit of 40+ years of hindsight.
Absolutely. Doesn't make any less crap. That's how progress works. We know better now therefore we're able to identify bad decisions in old software.
-
RE: An amusing rant about C
@Groaner said in An amusing rant about C:
@cvi said in An amusing rant about C:
That's an optimization, and you should make a conscious decision to perform this optimization as a programmer, knowing that by doing so you declare that the value is never going to exceed 2G or 4G.
This is often a very reasonable assumption, though. Picklists of states/provinces and countries will never have billions of items, and most warehouses, for example, will have trouble picking and shipping more than a billion orders in the service lifetime of the facility.
On one hand, yes, these in particular will never be in billions. On the other, that was the original motivation behind 16-bit Unicode encoding.
-
RE: An amusing rant about C
@topspin said in An amusing rant about C:
@Gąska said in An amusing rant about C:
@Watson with dedication to everyone whose browser cannot handle 200 pages of PDF inside onebox.
Did I complain about this before?
I’m old (not really, but really) and my memory sucks.Remember when I linked C++ spec?
-
RE: An amusing rant about C
@Watson with dedication to everyone whose browser cannot handle 200 pages of PDF inside onebox.
-
RE: An amusing rant about C
@djls45 said in An amusing rant about C:
Integer types aren't well-defined in C? That's because integer types aren't well-defined across all processor architectures.
Didn't stop Rust There's u8, u16, u32, u64, u128, usize, i8, i16, i32, i64, i128, isize, and that's it. No shorts, no longs. Just fixed size integers + one pointer-sized type.
the problem is moreso with programmers who wrote their code assuming that int would be the same across all architectures and platforms, and then didn't want to fix their code's portability problem when int on a different architecture turns out to be a different size. In actuality, those programmers were writing Assembly-in-C code, not C code.
Look - when I make a program, I want it to behave in a certain way. Ideally, I want the behavior to stay the same, regardless of where, when, or how I compile it. The more things are left up for the compiler to decide, the less trust I have in my own code and the more effort I have to spend making sure identical code actually works identically on all platforms. The more my tools get in the way of getting the actual work done, the shittier they are. And C is at the extreme end of getting in the way of cross-platform coding.
Is this shittiness justifiable? Yeah, for the most part it is. But justifiable shittiness is still shittiness. C is the worst language for cross-platform development specifically because of all those features you mentioned that were intended with cross-platform development. Unfortunately, the designers of C missed the mark completely and in nearly every case did the exact opposite of what would be actually helpful for cross-platform development. "I want my file format's version indicator to take twice as many bytes on 64-bit architectures" said no one ever.
Sure, I can move everything to uint32_t and friends. In my code. I can't do the same with the standard library. And almost nothing in the standard library uses fixed-size types. So I have to deal with variable-sized integers whether I want it or not. (Edit: also, a recommendation to use uint32_t wherever possible is itself an admission variable-sized integers were a mistake.)
All of this goes back to the issue of writing Assembly-in-{other language}. High-level, cross-compatible code ideally should not have anything in it that relies on the specific underlying hardware. Using specific integer sizes is one of those architecture-specific things that breaks cross-compatibility, so C doesn't tell you how big each one of its integral types are "supposed" to be.
You're correct about the first half, but sorely mistaken about the second. It's when you don't use specific integer sizes that you are relying on specific underlying hardware. C forces you to be aware of architectural differences.
A
char
type represents a character, regardless of the actual number of bits used to represent it.Actually no. The C standard defines
char
to be exactly one byte, and a byte to be at least 8 bits and correspond to the smallest addressable unit of the machine.A
short
indicates small numbers,long
for large numbers,long long
for extra-large numbers, andint
for whichever of those sizes is most efficient for the processor to handle.Which is an utterly useless feature unless you can guarantee a certain integer can fit in a certain type, which you cannot because the whole point is to not know the specific value range.
When you're messing with memory in some way, then yes,
(u)intptr_t
is a useful abstraction for e.g. number of elements in an array, when the array can potentially span the whole address space. But in all other use cases, the value range you must be able to handle is independent of architecture you're running on.Whenever interacting with outside world - through files, network packets etc. - you MUST use precise sizes or you'll be unable to de/serialize objects properly. You use
int32_t
and friends. When you're on some retarded platform where they're not available, you useint_least32_t
, which is mandatory per standard, to at least ensure it can contain all possible values. And if you really really care about performance so much you're willing to inconvenience yourself, but not enough to actually learn the target architecture, you useint_fast32_t
instead.These cover literally every use case you might possibly think of. There's no place for raw
short
,int
,long
orlong long
in C code at all. Hasn't been for the last 23 years.You want to write a language as portable as C? Well, then either you have to write all the different possible compilation targets that C supports or you have to write your "transpiler" to output C code and pass it to a C compiler. One of these involves a whole lot more work than the other, so guess which one nearly everyone picks?
Out of popular commercially-viable compilers, every single one went with the former. I wonder why that is.
And how many of those compilers are themselves written in C
Only GCC, Clang and Intel's C/C++ compiler, as far as I can tell. MSVC is made in C++ AFAIK. Every other native compiler is written in the language it's compiling. There may be some exceptions depending on how obscure you wish to go.
or can be traced back to a version that was originally written in C?
That's cheating. Every new language must, by necessity, start with a compiler written in another language.
Just to be absolutely clear: these are not C's problems!
No, strictly speaking it isn't. But they are problems of every interface that relies on C API. Every single one of them. And there are a lot of very important C APIs in use. So they became everybody's problems instead.
No, these are architecture compatibility problems that everybody has to deal with anyways, and that would exist regardless of C.
No. Not architecture compatibility. Just library compatibility. Even if you only target one compiler on one system on one architecture, you still have to deal with that.
And anyway. If C was meant to abstract away architectural differences, but you must be acutely aware of architectural differences when writing portable C... Don't you think C failed at abstracting those away?
-
RE: The Official Status Thread
@MrL said in The Official Status Thread:
Ripping apart tests nothing, long duration stress resistance is where it's at.
Unless you're carrying 20 kilograms of assorted electronics and non-electronics, take it on and off all the time, and you're not particularly gentle about it. I don't use a backpack often, but when I do...
I once scared the shit out of a bus driver because I turned around too fast when exiting and my backpack hit his plastic window.
-
RE: The Official Status Thread
@MrL but can you tow a car with a Wolfskin? I have no doubt there are other, more affordable bags that are as functional and fairly durable from reputable brands. But here's a thing. They're in a bag-selling business. LMG isn't. LMG doesn't care if people stop buying backpacks after a while. The usual "we cannot make things too timeless or we go out of business" doesn't apply. It's a gag item as much as a utility tool. Personally, I trust him he actually tried ripping that backpack apart - definitely more than I trust designer bag salesmen. Also, I owe him for all the YT ads I blocked.
-
RE: The Official Status Thread
It actually looks like a very decent product. And I'm in need of a new laptop carrying implement anyway. I've had several bags and backpacks rip up over the years in various ways, so paying one day's worth of salary for something that will last a decade or more, and is also very functional, sounds like a good deal. And supporting one of my favorite content creators is a cherry on top.
-
RE: The Official Status Thread
@izzion said in The Official Status Thread:
@Gąska said in The Official Status Thread:
Status: A youtuber added a $250 backpack to their merch store and I'm so hooked I will actually buy it.
Does it come with an initial helping of bath water?
No, but there's a matching $70 screwdriver (sold separately).
-
RE: An amusing rant about C
@LaoC said in An amusing rant about C:
I don't think anyone disagrees that using variable-sized integers nowadays, particularly in functions called by other people, is almost always a stupid idea.
Um... @djls45 in this very thread?
Does anyone disagree though that they were absolutely essential for at least the first two decades of C's existence?
I do.
-
RE: The Official Status Thread
Status: A youtuber added a $250 backpack to their merch store and I'm so hooked I will actually buy it.
-
RE: The Official Status Thread
@Tsaukpaetra said in The Official Status Thread:
Status: The backend is massaged enough that I feel comfortable
-
RE: [B][O][G][G]le
Wordle 273 6/6
🟩⬜⬜⬜⬜
🟩⬜⬜🟩⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩⬜
🟩🟩🟩🟩⬜
🟩🟩🟩🟩🟩Yes I actually managed to get to 6/6 with no yellows.