|
Private Speech posted:is git now written in c++ apropos of nothing, microsoft rewrote their C runtime in C++ years ago
|
#
?
Feb 22, 2019 23:44
|
|
|
|
| # ? May 31, 2024 16:15 |
|
|
Zlodo posted:he wrote this thing using c++ and qt: https://subsurface-divelog.org/ dont tell ol musky about this 
|
|
#
?
Feb 22, 2019 23:45
|
|
|
Krankenstyle posted:dont tell ol musky about this Private Speech posted:humm ahh no it didn't, it used to use GTK+ lmao it was ported over by the guy who took over after him
|
|
#
?
Feb 22, 2019 23:45
|
|
|
hackbunny posted:clang keeps track of the active member in a union, in c++, and can do it with pretty deeply nested unions and method calls. a stack of nested unions is much better as the internal storage of std::variant than the "obvious" choice of a memory-aligned char array, in no small part thanks to the much better compiler diagnostics you get with unions (and that's with libc++, an implementation of the std c++ library made for clang) i use std::variant a lot in my current hobby project and while i like having tagged unions the implementation is clunky
|
|
#
?
Feb 22, 2019 23:50
|
|
|
Zlodo posted:and yet, the compiler diagnostics that clang barfs when misusing std::variant are atrocious, not to mention the gazillions of intermediate steps on the stack when using std::visit or the mess you end up with when looking at their content in lldb I wrote a hobby reimplementation of std::variant once (the diagnostics I talked about? they're useful for implementors, not users) and behind the deceptively simple API it's insanely complex so I'm not surprised - especially not surprised about visit, because it has to perform the equivalent of indexing through a heterogeneous collection, which in c++ can only be done through a recursion-based loop unfortunately I don't think you can make a general purpose sum type simpler than std::variant without massive updates to the language (like herb sutter's metaclass proposal) hackbunny fucked around with this message at 00:01 on Feb 23, 2019 |
|
#
?
Feb 22, 2019 23:59
|
|
|
hackbunny posted:I wrote a hobby reimplementation of std::variant once (the diagnostics I talked about? they're useful for implementors, not users) and behind the deceptively simple API it's insanely complex so I'm not surprised - especially not surprised about visit, because it has to perform the equivalent of indexing through a heterogeneous collection, which in c++ can only be done through a recursion-based loop you can make a simple variant very easily, but the c++ variant is very complex and handles a ton of crazy stuff (I hope I never see code which passes multiple variants to visit). fairly typical of the stl though
|
|
#
?
Feb 23, 2019 00:12
|
|
|
Zlodo posted:endianness I uh may have to go retract some PRs  quote:If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be a trap representation. 
|
|
#
?
Feb 23, 2019 01:37
|
|
|
pro tip: put bjarne in the garbage, just throw him in there.
|
|
#
?
Feb 23, 2019 01:50
|
|
|
Krankenstyle posted:why not filter them through approriate interfaces that enforce conversion? Krankenstyle posted:please just make a type that can handle the conversion properly what the gently caress? now the burden is on some idiot (me) who has to work with your code instead of the compiler that can tell me to stop trying to use the int as a uint or whatever idk what you think HW *should* look like but loudly denigrating everything that touches it is a pretty bad look
|
|
#
?
Feb 23, 2019 02:02
|
|
|
hardware should be fast like it is now, but without the garbage interfaces it has now, how hard is that to understand 
|
|
#
?
Feb 23, 2019 02:03
|
|
|
JawnV6 posted:do y'all ever wonder where the 10MB+ runtimes that underpin your entire universes... come from? the compiler can work it out with proper a type system prove me wrong
|
|
#
?
Feb 23, 2019 02:37
|
|
|
Krankenstyle posted:the compiler can work it out with proper a type system prove me wrong if your argument is that embedded dev should be using rust, you’ll get no argument from me but like, that doesn’t mean it’s gonna happen
|
|
#
?
Feb 23, 2019 02:49
|
|
|
Krankenstyle posted:the compiler can work it out with proper a type system prove me wrong i dont think these issues have anything to do with the class of memory access issues that rust is particular about
|
|
#
?
Feb 23, 2019 03:06
|
|
|
hackbunny posted:problem is that this will only happen in optimized builds, making unoptimized builds much much slower, which is a really common issue in c++ where small and/or pure functions are considered "overhead-free" but they only are if you compile with optimizations. see quasi-operators like std::move and std::forward wait i thought move and forward were literally just casts to the same type but with references, how would they ever be anything other than nops
|
|
#
?
Feb 23, 2019 04:22
|
|
|
Lime posted:wait i thought move and forward were literally just casts to the same type but with references, how would they ever be anything other than nops they're actual functions that the compiler actually calls unless the inliner runs. they probably ought to be marked always_inline or the local equivalent but i wouldn't be surprised if they aren't there was a lot of talk in here about c semantics and compilers but as usual you should all just refer to hackbunny's posts unless you have any further questions
|
|
#
?
Feb 23, 2019 05:01
|
|
|
JawnV6 posted:you don't appear to be standing on a solid understanding of the layer we're discussing and seem content to haughtily piss down from your tower of abstraction, an exercise in frustration for me i get the impression they don't quite understand how typical it is to pack a bunch of non byte sized, non byte aligned fields in a single hw register, where the register access path often does not even support byte-at-a-time access semantics, much less bit-at-a-time (which the cpu doesn't support anyways) i do this kind of layout when designing registers all the time. i also often end up writing the software that manipulates them. it's fine. i don't want to chew up enormous amounts of address space and bloat out the read muxes to give every 1 bit field its own 32 bit word. fite me haters also like someone mentioned above, if you're in any place where there's minimal competence you have some kind of simple source code - csv file, json, custom minilang, whatever - that the hardware engineers write to describe registers, and there's scripts to 'compile' that source to C headers and Verilog source code for use on both sides of the hardware/software divide. maybe documentation files too, or documentation embedded in the C headers the output of these 'compilers' looks ugly to humans when you dig underneath the surface API, but it's a problem no HLL i'm aware of has ever attempted to address in a clean way, so you sweep all the ugliness into machine generated code and it's all fine
|
|
#
?
Feb 23, 2019 05:34
|
|
|
rjmccall posted:they're actual functions that the compiler actually calls unless the inliner runs. they probably ought to be marked always_inline or the local equivalent but i wouldn't be surprised if they aren't ok wow, tried some stuff in compiler explorer. i had no idea std::move(fart) and static_cast<Fart&&>(fart) (like if you didn't want to include any of the standard library headers, for example) would compile differently, i assumed they were basically language features
|
|
#
?
Feb 23, 2019 08:01
|
|
|
Krankenstyle posted:the compiler can work it out with proper a type system prove me wrong Maybe you meant to be posting there? https://forums.somethingawful.com/showthread.php?threadid=3863535
|
|
#
?
Feb 23, 2019 08:15
|
|
|
Arcsech posted:if your argument is that embedded dev should be using rust, you’ll get no argument from me One of my lovely projects is embedded in rust! It's okay, certainly not the practical choice right now. Also only works on systems that llvm can gen for. Does support packing fields into a single register just fine though JawnV6 posted:
Rust isn't only about the lifetimes, it does have a HM functionalish type system with standard enums, adts, pattern matching, first class functions, generics, type classes etc etc gonadic io fucked around with this message at 10:21 on Feb 23, 2019 |
|
#
?
Feb 23, 2019 10:15
|
|
|
gonadic io posted:Rust isn't only about the lifetimes, it does have a HM functionalish type system with standard enums, adts, pattern matching, first class functions, generics, type classes etc etc To me, it's Rust's type system which is most appealing, and the lifetimes are just a nice touch for performance reasons. But I understand I'm in the minority
|
|
#
?
Feb 23, 2019 18:50
|
|
|
Beamed posted:To me, it's Rust's type system which is most appealing, and the lifetimes are just a nice touch for performance reasons. But I understand I'm in the minority fwiw i completely agree with you. i've considered making my own string type that's a wrapper around Rc<String> that implements Copy as Rc's Clone just because they get in the way when i dgaf
|
|
#
?
Feb 23, 2019 18:55
|
|
|
Beamed posted:To me, it's Rust's type system which is most appealing, and the lifetimes are just a nice touch for performance reasons. But I understand I'm in the minority i dont think youre in the minority tbh. unfortunately the type system would probably suffer if you removed lifetimes
|
|
#
?
Feb 23, 2019 19:27
|
|
|
Beamed posted:To me, it's Rust's type system which is most appealing, and the lifetimes are just a nice touch for performance reasons. But I understand I'm in the minority Yeah if you could somehow remove the ownership system rust would just be a very well designed pragmatic low level language. It doesn't really have any interesting features beyond the borrow checker. gonadic io posted:fwiw i completely agree with you. i've considered making my own string type that's a wrapper around Rc<String> that implements Copy as Rc's Clone just because they get in the way when i dgaf I've fooled around with the idea of an 'idgaf' library for rust, something that makes it easier to write rust when performance isn't absolutely critical. Honestly thought it would boil down to either just using RC or implementing a GC. Being able to use GC when you don't care would be great, i'd never use any language but rust ever again.
|
|
#
?
Feb 23, 2019 19:55
|
|
|
DONT THREAD ON ME posted:I've fooled around with the idea of an 'idgaf' library for rust, something that makes it easier to write rust when performance isn't absolutely critical. Honestly thought it would boil down to either just using RC or implementing a GC. i'd use it. my discord bot has always been really verbose and i've been looking for ways to make the code less poo poo for ages now
|
|
#
?
Feb 23, 2019 21:09
|
|
|
gonadic io posted:One of my lovely projects is embedded in rust! It's okay, certainly not the practical choice right now. Also only works on systems that llvm can gen for. oh yeah I know you can do toy projects in embedded rust just fine but like, microcontroller vendors ain’t gonna make it a supported toolchain any time soon, and even if they did, it would take another decade (minimum) after that for industry to adopt it at any kind of scale
|
|
#
?
Feb 23, 2019 21:17
|
|
|
honestly if c++ couldn't gain traction, i doubt rust will. it'll just be C now and forever.
|
|
#
?
Feb 23, 2019 21:23
|
|
|
c++ 20 officially has modules 
|
|
#
?
Feb 24, 2019 00:03
|
|
|
The_Franz posted:c++ 20 officially has modules glad to see c++ finally catching up to javascript 
|
|
#
?
Feb 24, 2019 00:05
|
|
|
hope they botch the rollout less than java did
|
|
#
?
Feb 24, 2019 00:06
|
|
|
gonadic io posted:honestly if c++ couldn't gain traction, i doubt rust will. it'll just be C now and forever. everywhere I look, people are starting to roll back C and go to asm
|
|
#
?
Feb 24, 2019 00:23
|
|
|
embedophiles still weren’t enthusiastic about moving from c to c++ last time I checked (late 2017), attitude from the manufacturer was “yes we ship tools for it, but who would use them?”
|
|
#
?
Feb 24, 2019 00:26
|
|
|
gonadic io posted:i'd use it. my discord bot has always been really verbose and i've been looking for ways to make the code less poo poo for ages now i like your style. there seem to be a handful of like-minded yospos rust programmers we should all make something. let's build the rust gc. DONT THREAD ON ME fucked around with this message at 00:52 on Feb 24, 2019 |
|
#
?
Feb 24, 2019 00:49
|
|
|
rust gc idea: dereferencing a GCd pointer type returns a future since a collection pause could cause a dereference operation to block.
|
|
#
?
Feb 24, 2019 01:02
|
|
|
there is already a bunch of existing gc work in rust, seems like hard work imo. instead i'm more at the "what if I made a library so I didn't have to type Rc:: every time" level
|
|
#
?
Feb 24, 2019 01:10
|
|
|
plus just in terms of laziness of programming, gc has very little advantage over rc. sure rc might leak memory if you have cycles, and has a possible bigger runtime cost (although it's more predictable).
|
|
#
?
Feb 24, 2019 01:13
|
|
|
hackbunny posted:I worked in grails for years and I profoundly hate it. nobody should use it I hope you got paid $400k/year my first real intro to grails a million years ago was at a NFJS conference where some well-known grails dude who did it full time and had written a book or two on grails failed to get a hello world example app working for half of his talk/demo. in a sense that was successful cuz I never fell into the trap of trying to use it (I have fixed minor bugs in existing grails poo poo)
|
|
#
?
Feb 24, 2019 01:16
|
|
|
gonadic io posted:plus just in terms of laziness of programming, gc has very little advantage over rc. sure rc might leak memory if you have cycles, and has a possible bigger runtime cost (although it's more predictable). good point. it's hard to imagine making RC any easier, but you could definitely make dealing with interior mutability and synchronization within an RC a lot easier. essentially thinking monad transformers. you could maybe implement an enum that could opaquely be one of an (A)Rc<(Mutex|RefCell|etc)<T>> but expose essentially the same semantics as an owned T. DONT THREAD ON ME fucked around with this message at 01:22 on Feb 24, 2019 |
|
#
?
Feb 24, 2019 01:18
|
|
|
DONT THREAD ON ME posted:i like your style. there seem to be a handful of like-minded yospos rust programmers we should all make something. https://github.com/withoutboats/shifgrethor quote:In brief, a precise tracing garbage collector like shifgrethor is designed for works like this: luchadornado fucked around with this message at 01:21 on Feb 24, 2019 |
|
#
?
Feb 24, 2019 01:18
|
|
|
also https://github.com/Manishearth/rust-gc
|
|
#
?
Feb 24, 2019 01:21
|
|
|
|
| # ? May 31, 2024 16:15 |
|
|
shifgrethor is really cool
|
|
#
?
Feb 24, 2019 01:25
|
|