|
qsvui posted:lol how are you so wrong on every one of these points c++ is every language for every developer and every use case. you just write a different subset of c++ to them. neither of you are wrong, except that you're both using c++ in the first place
|
# ? Sep 2, 2018 01:30 |
|
|
# ? Dec 7, 2024 04:34 |
|
ratbert90 posted:What the gently caress is this horse poo poo? brb figuring out how to do numerical formatting using streams NOT
|
# ? Sep 2, 2018 05:22 |
|
Progressive JPEG posted:imo: Literally all of this is wrong. e: The one thing it gets right (avoid standard streams if possible), is still made wrong by recommending printf and its ilk. Xarn fucked around with this message at 06:39 on Sep 2, 2018 |
# ? Sep 2, 2018 06:36 |
|
DONT THREAD ON ME posted:how should I do exception handling? I'm most comfortable with Either's and saw someone recommend using them but no idea if that's a good idea or not. I'd rather learn to do what actual real programmers programming C++ do which I'm guessing is exceptions. you can do both! The best part is you can move between the two and your choice won't be wrong as long as you don't treat the non-exception error-handling like a C programmer who went into a coma in the 80s and woke up yesterday. One thing you'll run into is "How do I construct an object and make sure it never throws?" since you're coming from Rust you just do what Rust does. Static member function, returns an either (we call ours expected, but there's also outcome and that one is a bit better refined). Want to quickly wrap a function that *might* throw and have it turn into an expected? You get to use one of the least well known features of C++: using try blocks as function bodies C++ code:
tbqh he community is extremely split between people who say "no, exceptions are terrible for high performance code and here's a bunch of proof and examples", people like Herb Sutter who think there's something we can do to bridge the gap (but misunderstanding error handling approaches from other languages) and then people like Bjarne who say "software engineers should write software and leave language design to designers such as myself". (remember, the vasa sank because jet fuel can't melt wooden beams) if anything though, c++ has some decent capabilities for bridging schools of thought. private inheritance gets you mixins and composable interfaces. public inheritance gives you (in the case of a virtual destructor) class 90s OOP. protected inheritance gives you a bridge to go from public hierarchies to a private hierarchy while keeping both interfaces satisfied. (protected inheritance is "i know that myself is-a Base, but to everyone else I look like has-a Base interface")
|
# ? Sep 2, 2018 08:16 |
|
tried to get texture mapped polygons going in glide tonight by putting an image on a cube I got polygons that are filled with garbage so there’s something, at least I’m loading texture memory with... something and pointing the texture unit at it the voodoo2 contains two hardware texture mapping units capable of trilinear filtering and 16-bit textures up to 256x256 with 2MB of RAM per unit, plus a blitter for accelerating CPU <-> VRAM transfers Luigi Thirty fucked around with this message at 08:45 on Sep 2, 2018 |
# ? Sep 2, 2018 08:33 |
|
So yesterday I learnt enough Metal to port my live camera feed processing iPhone app over from the CPU to GPU. It was on CPU first because I don't know Metal at all and wanted to prove the idea works, and actually had a ton of fun getting the CPU version running as fast as I could (it does a twatty transform of a distortion into arrays of pointer increments and memcpy() parameters depending how many pixels can be copied at once) But holy crap it only took part of the afternoon, and with some help from Instruments got CPU time down to sod-all and time to generate frames down from 18ms down to 200µs. When it first ran I was grinning like an idiot. My best terrible programmer moment of the year hands down. As far as Metal goes it seems nice, but the docs aren't great for a noob, its like they were written for someone who already new what they were doing and just needed to brush up.
|
# ? Sep 2, 2018 10:09 |
|
Slurps Mad Rips posted:one of the least well known features of C++: using try blocks as function bodies holy god
|
# ? Sep 2, 2018 12:46 |
|
toiletbrush posted:So yesterday I learnt enough Metal to port my live camera feed processing iPhone app over from the CPU to GPU. It was on CPU first because I don't know Metal at all and wanted to prove the idea works, and actually had a ton of fun getting the CPU version running as fast as I could (it does a twatty transform of a distortion into arrays of pointer increments and memcpy() parameters depending how many pixels can be copied at once) nice! i love that feeling
|
# ? Sep 2, 2018 12:53 |
|
Phobeste posted:holy god
|
# ? Sep 2, 2018 13:21 |
|
matrices clicked for me this morning and it feels extremely good.
|
# ? Sep 2, 2018 13:21 |
|
Slurps Mad Rips posted:(im legit gonna try to remove the ability to throw a member pointer for c++20, but you can do this now if you hate life) what's specifically bad about this?
|
# ? Sep 2, 2018 14:07 |
|
jony neuemonic posted:matrices clicked for me this morning and it feels extremely good. matrices are rad i feel like every time i pick them up i learn some new weird property they have, and then immediately forget about it
|
# ? Sep 2, 2018 14:24 |
|
Slurps Mad Rips posted:you can do both! The best part is you can move between the two and your choice won't be wrong as long as you don't treat the non-exception error-handling like a C programmer who went into a coma in the 80s and woke up yesterday. One thing you'll run into is "How do I construct an object and make sure it never throws?" since you're coming from Rust you just do what Rust does. Static member function, returns an either (we call ours expected, but there's also outcome and that one is a bit better refined). Want to quickly wrap a function that *might* throw and have it turn into an expected? You get to use one of the least well known features of C++: using try blocks as function bodies interesting. I'm curious about the public/private/protected forms of inheritance, that's new to me. cheers! Xarn posted:Literally all of this is wrong. what's wrong with smart pointers? I'm not really using them yet because I want to get experience with raw pointers but I figured modern C++ was all about the smart pointers.
|
# ? Sep 2, 2018 14:38 |
|
DONT THREAD ON ME posted:what's wrong with smart pointers? I'm not really using them yet because I want to get experience with raw pointers but I figured modern C++ was all about the smart pointers.
|
# ? Sep 2, 2018 16:08 |
|
DONT THREAD ON ME posted:interesting. I'm curious about the public/private/protected forms of inheritance, that's new to me. cheers! It is pretty much the same as the public/private/protected specifiers, but applied to the fact that the class is inheriting form a base. https://godbolt.org/z/lMdYJt DONT THREAD ON ME posted:what's wrong with smart pointers? I'm not really using them yet because I want to get experience with raw pointers but I figured modern C++ was all about the smart pointers. They are perfectly OK, when you use them correctly (e.g. shared_ptr tends to be overused as gently caress), but it is a lovely advice, because it leads to code like this code:
code:
|
# ? Sep 2, 2018 16:49 |
|
Also, raw pointers are fine if they are non-owning which means you shouldn't have functions that look like this:code:
code:
|
# ? Sep 2, 2018 19:58 |
|
Phobeste posted:holy god
|
# ? Sep 2, 2018 20:43 |
|
Xarn posted:
yeah i think when most people say "always use smart pointers" i think they mean "for owning references that are dynamically allocated rather than using raw pointers", not instead of reference types or stack allocations
|
# ? Sep 2, 2018 20:54 |
|
Phobeste posted:yeah i think when most people say "always use smart pointers" i think they mean "for owning references that are dynamically allocated rather than using raw pointers", not instead of reference types or stack allocations ya
|
# ? Sep 2, 2018 21:56 |
|
if you ever use shared_ptr, you've hosed up somehow it's possible that shared_ptr is the best way to resolve your immediate problem, but that just means the root fuckup was so long ago that it's now a pain to fix
|
# ? Sep 3, 2018 01:11 |
|
Jabor posted:if you ever use shared_ptr, you've hosed up somehow i was about to disagree but then i realised just how long since i last used Box::new in rust. strings and vecs get put on the heap all the time but that's only because of their variable size - none of my structs ever need to go on the heap
|
# ? Sep 3, 2018 01:19 |
|
maybe i should start using cow/smallvec more
|
# ? Sep 3, 2018 01:19 |
|
i've been triyng to learn more rust and i feel like the error messages are kind of opaque. like in this guy's example of making a linked list stack:code:
code:
code:
|
# ? Sep 3, 2018 02:17 |
|
the reason the borrowchecker is failing is because it is illegal to move out of borrowed content in rust. it's one of the rules of the language. it's not aware of why it's bad. so yeah, it's absolutely opaque. i agree.gonadic io posted:i was about to disagree but then i realised just how long since i last used Box::new in rust. strings and vecs get put on the heap all the time but that's only because of their variable size - none of my structs ever need to go on the heap hey this is confusing me. what's the relationship between shared_ptr and Box in rust? DONT THREAD ON ME fucked around with this message at 03:13 on Sep 3, 2018 |
# ? Sep 3, 2018 03:07 |
|
why did Rust go with its memory model instead of something like ARC where the semantics are a bit less opaque?
|
# ? Sep 3, 2018 03:50 |
|
eschaton posted:why did Rust go with its memory model instead of something like ARC where the semantics are a bit less opaque? you can still do RC (reference counted) and ARC (atomic reference counted) in rust a language implicitly doing some garbage collection or reference counting strategy for you incurs memory and cpu overhead that is not appropriate for the type of programming niche rust wants to fill comedyblissoption fucked around with this message at 04:11 on Sep 3, 2018 |
# ? Sep 3, 2018 04:02 |
|
rust's borrow rules also improve program correctness beyond what garbage collection and reference counting schemes offer the rules statically prevent you from incorrectly read or writing to data that you should not in certain scopes. some prominent examples:
in c++/java, violation of these rules can cause undefined behavior that you don't know about or a program exception rust's rules also encourages a design with less shared mutable and less global state. this probably improves programmer productivity some articles about this: https://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/ https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
|
# ? Sep 3, 2018 04:28 |
|
DONT THREAD ON ME posted:the reason the borrowchecker is failing is because it is illegal to move out of borrowed content in rust. it's one of the rules of the language. it's not aware of why it's bad. so yeah, it's absolutely opaque. i agree. the same relationship between Arc and Box in rust. except we don’t have an Rc, though my retain_ptr paper might pave the way for one eventually. eschaton posted:why did Rust go with its memory model instead of something like ARC where the semantics are a bit less opaque? with retain_ptr I can do whatever I want with ObjC's ARC bullshit and I can just let implicit copies happen whenever. i bow before no mortal Slurps Mad Rips fucked around with this message at 05:09 on Sep 3, 2018 |
# ? Sep 3, 2018 05:00 |
|
smart pointers? lambdas? sorry can’t hear you VC6 barely has the ++ part down
|
# ? Sep 3, 2018 07:18 |
|
Luigi Thirty posted:smart pointers? lambdas? sorry can’t hear you VC6 barely has the ++ part down tbqh it’s more or less on par with gcc 2.95 which was its main competition when they were released i need to go find that patch someone did to the half life 1 sdk so you could make mods with gcc 2.95
|
# ? Sep 3, 2018 07:23 |
|
iirc GCC 2.95 is the latest one you can get working on basically every platform that can semi-emulate POSIX so there’s something
|
# ? Sep 3, 2018 07:25 |
|
Every time I hear horror stories about old gcc or old VS, I am so glad I started doing C++ with VS2010...
|
# ? Sep 3, 2018 07:28 |
|
oh yeah I love VS2017. Microsoft tools own shaggar was right etc etc
|
# ? Sep 3, 2018 07:32 |
|
DONT THREAD ON ME posted:
Unless I completely misunderstood, there was some previous chat about how you should only use unique_pointer when referring to a newly created heap value and then it has similar semantics as a borrow-checked Box. reptilians posted:i've been triyng to learn more rust and i feel like the error messages are kind of opaque. like in this guy's example of making a linked list stack: Self.head does not implement copy here so when you put it inside the box (instead of a reference/pointer) you'd completely invalidate the old memory but you only have a mutable ref to it which is not allowed. If you could freely copy self.head, or if the function took self.head by value (you'd be free to destroy the old value) there'd be no issue. If it was cloneable then instead of calling replace you'd call clone. Instead since self.head is uncopyable you need to move it out and leave some value in its place. Note that the question is now why do uncopy/cloneable values exist and I'm not 100% on that. Copy is a bitwise copy so you're not allowed to do it with pointers that are supposed to be unique (vec, box, etc). Those need to be deep copied (ie cloned) or references used. Very few things aren't cloneable - mutable references are one because then you'd be bypassing the borrow checker. Idk what else. Final note: even if the value was cloneable, since you're overwriting the old value anyway it'd be a waste to deep copy it so it might be worth using replace anyway. A common trick is replacing with uninitialized mem to avoid the cost of constructing a default instance of the type but then you're in unsafe land and you better be really sure you need those cycles and will never tweak that code into ub.
|
# ? Sep 3, 2018 07:34 |
|
the cto of the place i'm at was high up at microsoft dragged like 9 of his microsoft buddies to shore up a previously-10-peep engineering team. they do honestly better work than the old peeps cuz it turns out tech majors (former tech majors, i guess?) have hiring standards. i was another student of the prof whose spinoff this is so i got in by nepotism (lol no) we use postgres and goog cloud, lol. by cto's choice (but we use c# and vs2017)
|
# ? Sep 3, 2018 07:36 |
|
- ballmer-era microsoft high-up - makes bad decisions yes this all checks out
|
# ? Sep 3, 2018 07:49 |
|
Note that it's entirely possible to turn the borrow-checked from statically checked to runtime checks using the *rc and *cell types. You can further bypass those runtime checks by using the unchecked methods in those types, poo poo or even just casting to mut* and doing whatever the gently caress (the last two require unsafe blocks) you want but those practices are strongly discouraged. There's plugin's tracking the use of unsafe in libraries and fuzzing them and people who go around making pull requests to remove them if at all possible because you really do lose all of rust's guarantees if you do that poo poo. IMO the way to do unsafe programming in rust is to be aware of which invariants you're promising to maintain. Going into unsafe to use mem::uninitialized because you really can't pay the cost of constructing a valid instance of the type? Better be loving sure you write to it (note that dropping uninitialized memory is not allowed because you don't know what Drops will run on it. Dereferencing a static memory address for a peripheral? Better be loving sureit's valid. Converting that pointer into a ref? Now you've just promised "the aliasing and mutability laws of references" are true for that pointer. gonadic io fucked around with this message at 08:05 on Sep 3, 2018 |
# ? Sep 3, 2018 07:55 |
|
Jabor posted:if you ever use shared_ptr, you've hosed up somehow returning a large heap allocated object?
|
# ? Sep 3, 2018 08:04 |
|
Progressive JPEG posted:returning a large heap allocated object? if the caller is going to be taking ownership, return a unique_ptr. if not then return a raw pointer or a reference. if you don't know who's supposed to have ownership, and one might be cleaned up before the other one is finished with the large object you've returned, then Jabor posted:that just means the root fuckup was so long ago that it's now a pain to fix
|
# ? Sep 3, 2018 08:11 |
|
|
# ? Dec 7, 2024 04:34 |
|
comedyblissoption posted:performance ARC = Automatic Reference Counting, which generally means implementing the Cocoa/ObjC reference counting and ownership model (Swift’s ARC is slightly different in that the general case of a returned value is +1 (retained, caller-release) rather than +0 (retained, callee-autoreleased), but is extremely similar overall)
|
# ? Sep 3, 2018 09:01 |