C Meeting adjourned.
Uncategorized
12
Posts
9
Posters
1
Views
-
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd ooof, that sounds super rough /∆\ sorry yo, hopefully there's some avenue for improvement? (or escape)
-
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd Well this is all kinds of rough...
-
@thephd Well this is all kinds of rough...
@thephd On some level, i sympathize with demands for implementation & use experience; c++ definitely suffered during the aughts because a bunch of features got adopted without *any* implementations (and that is generally a bad idea).
Back then, when the time came for a vote on adopting a new feature, Clark Nelson was the only person who consistently asked, "has it been implemented?", and voted against if the answer was "no".
[...] -
@thephd On some level, i sympathize with demands for implementation & use experience; c++ definitely suffered during the aughts because a bunch of features got adopted without *any* implementations (and that is generally a bad idea).
Back then, when the time came for a vote on adopting a new feature, Clark Nelson was the only person who consistently asked, "has it been implemented?", and voted against if the answer was "no".
[...]@thephd
These days, i would want someone asking, "has it been taught, and did someone observe coders using it?", which seems much more doable in the age of twitch & other live streaming services.(That is definitely a much bigger ask for proposal authors, but it should yield more polished designs.)
-
@thephd
These days, i would want someone asking, "has it been taught, and did someone observe coders using it?", which seems much more doable in the age of twitch & other live streaming services.(That is definitely a much bigger ask for proposal authors, but it should yield more polished designs.)
@thephd That said, the idea that vendors want to block all new features *regardless* of implementation experience is... very strange. In the long run, it seems counter to their interests...?
I don't know what to make of it.
-
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd frustrating experience to go through, sorry it all ended up going that way 🫂
-
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd A friend of mine recently showed a proposal about variadic macros, that you had invited her to a C standard meeting over. Was that thing shelved again too ?
-
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd closures seem like a pretty obvious feature and I'm surprised C still doesn't have them natively after all these years
We got compile-time type inference before we got closures, somehow -
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd thank you for fighting for people who want to write C like it's no longer the 90s
-
C Meeting adjourned. Pretty much nothing I was happy about made it through, including things I did and did not work on. For the things I was responsible for...
-- https://thephd.dev/_vendor/future_cxx/papers/C%20-%20printf%20string%20size%20specifiers.html
Sized strings are not important to the Committee for C, and printf will remain printing with (int) casts. There was no direction to continue, but some said they'd change their vote if I implemented it and came back to show it was a low-cost, simple implementation.
Closures had some direction to continue but faces extreme opposition because (most) implementers want to either (a) ignore captures altogether and do something with no local state; (b) standardize no-captures and promise to do something maybe, later. Tough.
All the other papers I was happy about on the agenda didn't get anywhere, and some of the issue resolutions went the way I didn't like, but it's not really worth mentioning because I'm not a Big Implementation (and apparently, not a Real C Person). Not much I say can matter.
I think vendors want to close C down basically, as a sort of thermostatic backlash to the various changes being proposed and from so much being one in C23. I can't really stop that and it's unfortunately bad because there's various "simple" proposals that have long-term consequences.
But we're not really illuminating those consequences in discussion or papers right now. I have a lot of papers right now that'd just be "there are betters ways to do this, please let's think about this" and I'm kind of tired just from thinking about it.
Maybe I'll be a more effective advocate next meeting. Who knows.
I also realize everyone is going to continue to clown on me as being a C++ person no matter how much expertise I have/gain in C, so I think I have to implement a compiler or do a complex renounciation-of-C++ post of something before people evaluate my work on its technical merits purely. It also doesn't help that most changes I am working on tackle significantly large areas that I always get "eww, C++" as a default reaction, even for things like
defer, which is -- generally -- pretty annoying.Knee-jerk Anti-C++ hatred is wearing on me. Worst part is, nobody properly communicates what's C++-centric about anything we standardized, other than the spellings. They don't even read the history of their own features. E.g.,
__auto_typeandautocoming from C first, because it was implemented for macro shenanigans while C++ was still goo-goo-gaa-gaa and usingtypedef typename foo::typename bar:: typename baz;-style crap and didn't realize the goodness of type deduction until 10 years after__auto_typewas making for clean C macros. But no, no, it's a "C++ invention", and you can't convince them otherwise.Brutal to have to live with it and deal with.
I'll figure something out, eventually.
@thephd urgh, rough, sorry ypu have to deal with that
-
undefined oblomov@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@Steve12L pour mois avec saucisse au piment. Merci.
-
@lgsp ha fatto notare che la cabinovia per accedere alle piste non è stata completata e che ci sono parecchi posti vuoti nelle tribune.
-
La pâte à pizza est prête.
Recette ici : ⤵️
-
@ilarioq cosa sta dicendo?
-
@kaia the big question: is it related to agoraphobia or just a matter of habit?
(BTW, several sci-fi novels present the case of planes with hyperdense population density where everyone lives inside and is uncomfortable with getting to the surface.)
-
@lefteristrip23 thanks for the reminder - have been dealing with a lot and haven’t had time to update my PeerTube installation.
Will do so next week when I have help from my parents 😅
-
-
@_elena hey!
Trying to add your peertube instance on the peertube app, gives me a "platform's version is too old" message.:( :))
