|
Janitor Prime posted:ISO8601 which one?
|
|
|
|
|
| # ¿ Dec 13, 2025 07:58 |
|
between go and rust, I recommend swift
|
|
|
|
my stepdads beer posted:hm we use confluence for this. it's like perl where it's write only and no one reads it at old job we used confluence for everything: specifications, brainstorming, meeting minutes, internal procedures, and all documentation for customers (product manuals, faqs, quick start guides, etc.). it was invaluable. I hate to think what clownshoe operation you run hackbunny fucked around with this message at 21:34 on Nov 18, 2018 |
|
|
|
Finster Dexter posted:Is this why game engines are written in c++? because they're literally programs that are generating specific game programs? that, and the zero/predictable overhead. if c++ didn't have templates, game engines would be written in c Asleep Style posted:This is a really interesting post. Gonna have to think hard about if these are the type of problems I would like to have at my job. if you ask me, c++ the language is perfect for any job. development is front-loaded with type system trickery and it tends to be pretty bottom up as a result, so you won't see your program come together for a long time, but letting the type system do most of the correctness work, I've written literally bug-free code under crazy time constraints and without the benefit of automated testing. I used to love c++ as a sort of intellectual game, but I've used it professionally for years now, and I've come to appreciate it as a unique and (currently) irreplaceable language its weakest point is actually third party libraries: there isn't a standard anything. no standard build system, no standard library format, no standard repository, not even consistent coding conventions, and setting it all up is so hard and outside of most programmers' skills that a lot of libraries will have misguided "simplified" build systems or binary distributions. it's a lot of work setting up a project with several external dependencies hackbunny fucked around with this message at 22:05 on Dec 1, 2018 |
|
|
|
redleader posted:what about c++'s type system do you find so powerful? i personally haven't heard anything special about it, but that may just be because it's not new + cool. what makes c++ different to any other compiled, statically-typed language in this respect? why couldn't you do the same thing in e.g. java? I can encode state in a variable's type. thanks to zero overhead, I can do it without actually adding any state. thanks to move semantics, I can enforce state transitions. you can encode state as statically checked type in java too, but you'll have overhead and no real equivalent of move semantics. heck I can't even enforce non-null pointers in java (except with nonstandard annotations I guess). you can add a c++ wrapper in front of a c library/api, and express lots of constraints that are left implicit in c, and make them explicit and enforced at compile time, again with zero overhead compared to handwritten code the irreplaceability of c++ comes from its ubiquity and the fact that it's largely binary-compatible with c. I think I already mentioned that my last big c++ job was a cross-platform application core that ran on three different operating systems (ios, android, windows) and implemented three different bridges to higher level languages (objective c++, jni, c++/cli), which no other language outside of c can realistically achieve biggest issue in c++ is the extremely poor support for pattern matching: compile-time only, and even then mostly a hack. I'm not hopeful for the future either
|
|
|
|
Symbolic Butt posted:this sounds like a neat idea but I never encountered something like this, most of the time I see is just a shallow wrapper to make everything more OOP or something think unix, where file handles are simple ints, except there's nothing simple about them. not all files support all operations, some are special files that only work with a very specific set of functions (eg. ipc objects), and they represent resources that need to be managed somehow. not to mention how easily it is to pass an int around by mistake. on windows the situation is just as bad, as HANDLE is almost as vague as int (it's a typedef for void *), but it can represent dozens of different resources that have absolutely nothing to do with each other. with c++ you can wrap them in more agreeable types that can't be assigned by mistake, passed to the wrong functions by mistake, leaked by mistake etc. I tend to skip "official" c++ wrappers to popular libraries as they often are pretty misguided, eg. solving this issue with class hierarchies and virtual methods (pointless! it's not like the underlying c library lets you override the implementation so why bother with virtual?) c++ is not unique in this (some of it, with significantly more effort, can be done even in C), but it's the most comprehensive I know of
|
|
|
|
TheFluff posted:
I'm hosed I guess because that's very readable to me. hell it's pretty restrained and I could do much worse, like why isn't that get_u8<2>(val) and why doesn't it throw on non-zero upper 16 bits or something Kevin Mitnick P.E. posted:"template metaprogramming is worth it to avoid a 16-byte overheard wrapping an int into an EpollFd" now that you mention it, another cool thing about c++ is that you don't need to design the class to be, eg. "epollable" from the start, you can always add it later (eg. see the Swappable requirement). the syntax isn't great but but yes it's worth it. it's not just the overhead - more memory, an extra level of indirection to access the data, possibly an extra level of indirection to access the code (see virtual methods) - but also the side effects (the serialization implicit in allocation, the extra stack and cache usage for noninlinable calls etc.) and the plain awkwardness - java lacks an equivalent of move semantics or even destructors (maybe it recently grew an IDisposable-alike I'm not sure) Kevin Mitnick P.E. posted:POD doesn't apply to classes I think. that's the other difference between structs and classes there is no* difference in c++ between struct and class. the requirements for POD are pretty loose and you can do anything with them as long as you don't conflict with C semantics (default value must be "uninitialized"; no destructor because C won't call it; can't customize copy or assignment because C code must retain the ability to copy your object with memcpy; can't contain hidden fields like vtable pointers so no virtual members; etc.)
|
|
|
|
Kevin Mitnick P.E. posted:c++ programmers really believe that indirecting through a pointer every so often to fetch their 1-per-core epoll fd will kill perf? cause that's what I meant--in some areas value types and static binding are absolutely critical to get get decent perf and decent expressiveness. HashMap<Long, Long> is insanity and the hoops library authors have to jump through to get good primitive collections arent a lot better. other times, eh. doesn't matter. moot point. I write in c++ not for performance but portability and interoperability, and the template-heavy-zero-overhead-RAII-ADL-SFINAE-move-semantics-perfect-forwarding style is simply the best way to use c++. other styles are poor imitations of other languages imo, without any of the benefits those other languages enjoy (eg. gc)
|
|
|
|
Kevin Mitnick P.E. posted:what got me started though, is when you were pearl clutching about an fd wrapper having a vtable and how it was so much better to write and maintain code to avoid that well, it is. and it was just the easiest example that came to mind. what I was really thinking of was JNI, where an object reference can either be a local or global reference (extremely important difference) depending on where it comes from, and nothing about the type reflects this. with lightweight wrappers, you can make this "soft" property "hard" and eg avoid implicitly converting a global reference into a local reference. not to mention all the raii wrappers you can write, to dispose of references you no longer need (jvm is terribly miserly), or to represent the raw data of a java array or string. this is probably meaningless to you but you had to dickwave Kevin Mitnick P.E. posted:i really like the fd example because no matter how skinny you make it in userspace the kernel still has a struct file, which, aside from being vomit-inducingly bloated by c++ standards, includes a vtable pointer this argument is so poorly thought out I could believe you were negging me. kernel code and state is, by definition, 100% overhead, that kernel writers try to keep as low as possible. look at it, so bloated that the whole thing fits on my lovely little screen, and almost all fields are perfectly self-explanatory that said, enjoy your paid hobby of overriding virtual methods with one-liners that throw "unsupported operation" Kevin Mitnick P.E. posted:yeah it doesn't really matter how fast your code is. do something simple and correct in a decent language like java and your code will never be the bottleneck in a "query db, make http requests, repeat" loop. I wonder what the db, http client, tls client, cryptographic framework, tcp stack and network driver are written in probably nodejs idkKevin Mitnick P.E. posted:"but my code is very important and does things with bytes and it really really matters how fast i shuffle records from disk to ram and back. a factor of 2x is competitive advantage". nope, you're just ignoring the opportunity cost of using c++, or maybe, I'm writing a cryptographic protocol in a real-time code path. or a filesystem activity monitor for rolling back ransomware damage. not everyone works the night shift at the turd shunting yard, you know
|
|
|
|
carry on then posted:love to read constant back one forth volleys consisting solely of “my kind of programming is the only real kind of programming” I do many kinds of programming and I believe I make generally good choices of the technologies to use and how to use them Kevin Mitnick P.E. posted:yeah my point was that 16 userspace bytes per open file aint gonna be what kills you. writing a bunch of code so it's 0 bytes instead of 16 isn't gonna make a big dent in the total you have to write a bunch of code either way. one bunch of code sucks in every conceivable way, the other is literally the way the language was designed to be used Soricidus posted:c++ chat: i opened some c++ today for the first time in a while, and the first thing i saw was it calling std::string::data() and then using const_cast so it could modify the result. what could possibly go wrong? it's legal starting in c++17. calling data() on a non-const basic_string now returns a non-const pointer. and thank god, took them long enough
|
|
|
|
carry on then posted:you called all java programmers hobbyists what? who? when? I'm a java programmer too so I have no idea what you're talking about
|
|
|
|
if anyone thinks I've been insulting them, their work or their tools, they should stop being insecure little fucklets and maybe try to learn something from my posts, starting from the idea that if your job requires programming you should get better at programming
|
|
|
|
akadajet posted:you must be a joy to work with irl yeah coworkers hate the gently caress out of my attention to detail and my unconditional availability for mentoring carry on then posted:funny how "better at programming" always really means "more like the kind of programmer i am" stop being a burden on your coworkers Kevin Mitnick P.E. posted:i kinda felt insulted but also had it coming so 🤷 I have NEVER insulted a single programming tool or programmer in my entire stay here in yospos, ever (I checked). I'm a javascript apologist. I owe a personal debt to visual basic. I used to be a pascal fan. I criticize gcc but I know it inside and out. I recognize python's huge shortcomings and it's still my go to language for experimentation. I've never used haskell, the haskell fanboyism a couple years ago was very offputting but I never said a bad word about it. and java programmers of all people feel attacked and outright make up accusations I've made. I like java without reservations, I've used it personally and professionally, I've recommended and lauded it here in yospos, if I don't post much about it, it's because it's a really simple and straightforward language with very little trickery possible or necessary (which is one of its strongest points). I don't have the faintest goddamn idea what you and carry on then are on about. stop being insecure about what I can do in "my" language that you can't in "yours" - do you know what java can't do and c++ can, actually? running on android, ios and windows, built with standard dev tools, interacting with native C/C++ libraries on one side and java, swift and C# on the other. NOT poo poo like zero overhead and compile-time code generation (which I still use because it's the way C++ was designed to be used - do you often write java code that's a single class with hundreds of static methods? no because that's not how you use java even if you can). let me love the gently caress out of programming in peace, please the other side of the coin is that I can't stand poo poo like regular expressions etc etc two problems and I won't stay silent about it. have some pride in your work and learn to use the "hard" tools (regexes are not that hard. nor are autotools, to name another popular bugaboo) hackbunny fucked around with this message at 22:39 on Dec 11, 2018 |
|
|
|
eh it comes up all the time. really, they're flawed, they're idiosyncratic, they're second-class code in almost every implementation, but "hard" they're not. I can't really effortpost because I've never looked at them in depth, but if you need help with a regex, just raise your hand
|
|
|
|
in cjs news, I'm back to win32 internals and kernel mode windows after a decade+ hiatus and it's like riding a bike apparently, you never forget. some parts are new and unfamiliar (eg. still not fully getting the hang of api sets) but most of it is still the good old win32 I knew by heart. nothing interesting to post about atm, just the usual win32 inter-process fuckery. unless win32 inter-process fuckery is not "usual" to you, in which case I have a lot to say
|
|
|
|
see how much repetition there is? and how even in languages with variables and functions and recursion, you can't use those extremely basic facilities in regular expressions? that's what I meant when I said they're flawed and part of what I meant when I called them second-class. other parts of their second class status are that they're strictly serial - all input comes in, then all output comes out - and opaque to debuggers. not true limitations, "just" implementation issues, sure, but nobody seems interested in solving them
|
|
|
|
Jabor posted:Implying someone works at the turd-shunting yard is a zero-cost insult, so it's not surprising that it just got optimized away in hackbunny's mental model oh, that. well, live by the diss, die by the diss. no regrets
|
|
|
|
Ciaphas posted:realizing c++ added auto like 7 years ago, instead of map<string, vector<byte>>::const_iterator or whatever, made me realize just how bad $current_job has been for me you can't typedef a lambda (the type of a lambda is unique and unnamed) so they were forced to add auto. similarly, ranges (ie pairs of iterators as a single object) were the original driver of concepts and are still a major application of concepts
|
|
|
|
Ciaphas posted:oh yeah lambdas came in at the same time didn't they, don't have those at $current_job either before c++11 we made do with Boost.Lambda. Boost also had some hack to work around the lack of auto or decltype (Boost.Lambdas had named types but lol at actually typing them out), and it mostly worked on msvc too Captain Foo posted:you should learn c++ from hackbunny, ciaphas, and quiggy I'm not a good teacher I'm afraid because I'm extremely self taught and couldn't tell you the difference between lvalues, glvalues, xvalues etc. and other conceptual stuff that often turns out to be important otoh I like to think that I misunderstand the language in a useful way
|
|
|
|
Ciaphas posted:do you still have to do dumb workarounds with template impls and header files to make compiling and linking work properly, or has that been fixed since C++11/as build systems have improved, too completely separating template interfaces and implementations has been tried (the "export" keyword) and unanimously rejected by all compiler writers for being extremely hard to implement and making C++ incompatible with conventional linkers. exactly one vendor implemented it and even they advocated for the removal of the feature from the standard that said, some separation is still possible, and the right way depends on what's the reason for the separation binary compatibility/ABI stability? "flatten" the ABI as a set of virtual classes and plain functions, possibly even extern "C" functions. lots of C++ libraries do this including all C++ runtime libraries. as a bonus, it can minimize code size explosion, for example in STLPort (an old compiler-independent implementation of the standard c++ library) all specializations of set and map were funneled through a single common R/B tree implementation written in C reducing (although not minimizing) build times and code duplication? explicitly instantiate your templates for the most common sets of parameters. the explicit instantiations can then even be exported and imported from dlls (as always, it helps to think of templates as compile-time functions that generate perfectly standard C++ classes/functions that you could write yourself manually) separation of interface and implementation? only the "flattening" idiom guarantees it. explicit instantiation can do it, at the cost of making not explicitly instantiated specializations unavailable - i.e. you have to know in advance all types your templates will be used with. it's not even that bad! turd.h: C++ code:C++ code:C++ code:turd.h: C++ code:C++ code:finally, if your goal is to completely hide the implementation of a template, forget about it. it's been rejected as a misuse of c++ and between that and the "export" tragedy, it's probably never going to be considered as a feature again e: including the cpp from the .h is kinda pointless and equivalent to just leaving the implementation in the .h file hackbunny fucked around with this message at 22:23 on Dec 17, 2018 |
|
|
|
|
|
|
|
eschaton posted:any idea why poll(2) would not actually return -1 with errno set to EINTR when a signal occurs? this is on NetBSD 8 the default on BSD is to automatically resume syscalls interrupted by signals. make sure to use sigaction (relevant flag: SA_RESTART) instead of signal to set the signal handler
|
|
|
|
eschaton posted:all the docs just say “signal mask,” they don’t say whether the mask is to indicate signals to block or signals to allow; turns out in this case it means signals to block oh yes the mask blocks, "everyone knows this". think of signals as an abstraction of interrupts: there's a "mask" of pending signals (not literally a mask because signals carry a little more data than a simple pending/clear bit - see siginfo_t) and a per-thread (originally per-process) mask of blocked signals. the fact that pending signals are a mask is very important: if a signal is already pending, sending it again will have no effect. unless the OS implements sigqueue (I believe they all do nowadays) and the source of signals uses that instead of kill
|
|
|
|
VikingofRock posted:I've been reading a discussion on modern C++ in the PL thread, and it's got me wondering: when is SFINAE actually needed over other template techniques? And when does it provide clearer code? It's something I've never really understood the motivation for. it's all about pattern matching: templates are wildcards, SFINAE lets you narrow them down to more precise criteria. think of SFINAE as a hook into the function overload resolution algorithm: it lets you write customized match/skip conditions. concepts should make it significantly less gross but I haven't really looked into them. I'll cross that bridge when I come to it
|
|
|
|
DONT THREAD ON ME posted:- I totally get why C++ programmers are skeptical about Rust; Rust really doesn't give you the same power C++ does unless you're using unsafe, and unsafe Rust is harder to get right than C++. personally, I find it a relief when I get to use simpler languages, so that sounds like a plus to me. I really should look into rust DONT THREAD ON ME posted:- I really don't like how C++ does OOP. I'm not going to say it's bad or wrong but it's definitely confusing and ugly. Stuff like not having explicit interfaces or abstract classes so instead you have to just design your class in a specific way to enable these behaviors (virutal/pure virtual member functions, etc). I think this approach ultimately gives you more power, but reading code is a lot nicer when I have ways of marking things as abstract. psst hey mate hey *opens trenchcoat*
|
|
|
|
ratbert90 posted:why? they're not great, they're one of the weakest parts of the c++'s design. massive overhead at compile time and runtime, extra overhead from rtti-based pattern matching, and absolutely impossible to exhaustively review code for correct exception handling. a relatively minor but important side effect is that they're completely unusable in some environments, like kernel mode code - "relatively" minor because c++ without exceptions is broken plain and simple (lots of operations - notably object construction - can only be failed by throwing an exception). only way they could have been worse would be if they actually implemented resumability as originally envisioned as usual, herb sutter to the rescue with a proposal to steal features from other languages (in this case, Swift). incidentally, it also explains the issues with c++ exceptions much better than I have
|
|
|
|
DONT THREAD ON ME posted:i could probably ask this in the C++ thread but I havent made my way in there yet. what's the best way to handle exceptions in c++? as a broke brained functional programmer i want to use the variant container and treat exceptions as values, but I'm sure there's a better approach. yeah I did this too, but I wrapped my variants because the api is unaesthetic af. with a wrapper I could give alternatives names instead of indices, and use enums to identify the active alternative instead of integers. variants work well enough in c++ but be warned that pattern matching is dire: your only realistic option is a plain old switch statement. you can use an overloaded/generic visitor function too but it only works for the most trivial cases but I can vouch for it. in my last project, all of my validators/parsers returned wrapped variants, and functions that operated on them extracted the values and repackaged the results (or propagated the errors) into other wrapped variants (do not nest variants although you probably already know that better than me). between this, wrapping all state changes in explicit state machines (variants are also good for encoding state variables - again, as you probably know better than me) and being extremely conservative about concurrency, most "obvious" bugs were stillborn (you'll still be affected by the silent killers - dangling pointers and dangling moved-from objects). sadly, there's no good way to enforce checking all possible values of a variant, but compiler-specific options (or structuring code in the right way, eg. by making sure that if you miss a case, the return value of the function is undefined) can help in simple code, let's say "C with RAII", where you don't have to maintain a consistent state but can handle errors by simply freeing resources, just use plain exceptions. it's where they shine. anywhere else, exceptions are hot potatoes you don't want to be holding for too long iirc c++20 is going to have a more explicit "either" container TheFluff posted:i learned the hard way that one does not simply catch a c++ exception, especially not if it's been thrown from a different library that was compiled with a different runtime. if you do manage to catch it, chances are you might also catch a very interesting memory leak I used to be terrified of that but in environments like mobile, where you compile all code and dependencies as a matching set and link everything together in a single binary, I could relax and expose exceptions through APIs without worrying too much e: binary distribution of C++ libraries is ridiculously risky - sneeze at the compiler and it'll create a unique dialect with an incompatible ABI - so I always bit the bullet and recompiled all external libraries, up to six times (arm, arm64, x86, in debug and release configurations). that's where you learn to appreciate autotools and be skeptical of cmake hackbunny fucked around with this message at 23:27 on Jan 15, 2019 |
|
|
|
Illusive gently caress Man posted:how can/should a programmer add this kind of detail in the exception world of that paper? A try-catch that just appends detail and re-throws sounds unwieldy to me, but that could be because I've been living in an exceptionless world for so long. sorry: Sutter-sensei posted:It is not a goal to enable distantly handled errors to contain arbitrary programmatically usable information. Distantly handled error details primarily need to be human usable (e.g., debugging and trace logging), and a .what() string is sufficient. with classic exceptions, you can easily wrap at the throw site, and keep the same catch sites, and gradually migrate the catch sites to extract the extra information. see how Boost.Exception does it: https://www.boost.org/doc/libs/1_69_0/libs/exception/doc/boost-exception.html with value exceptions as currently proposed, you can wrap just as easily, but unwrapping becomes mandatory, because they don't have multiple inheritance: every error has one piece of type-erased data and a category, no more no less. no such thing as multiple views into an object, like you can do with classes hackbunny fucked around with this message at 21:45 on Jan 16, 2019 |
|
|
|
honestly I'm surprised that the proposal doesn't provide for user-defined error types, and a little disappointed because I was never a huge fan of funneling all error handling through errc comparisons/conversions e: my bad, §4.6.5 says it may be possible in the future, but herb sounds skeptical of its usefulness. weird because I can think of a lot of things I'd like to have that his proposed std::error can't do hackbunny fucked around with this message at 22:48 on Jan 16, 2019 |
|
|
|
a good deal of voip calls are routed through a 30000+ line C source file
|
|
|
|
NihilCredo posted:
yeah chan_sip rules problem is that particular family of issues, ie. race conditions due to an incredibly complex protocol, are unavoidable in voip and especially sip. could surely be handled better but you have no idea how hard it is. case in point: the facetime security issue. when I read about it, I had a cold sweat about the voip client I wrote (could be conceivably affected by that issue or something similar. you'd think the call answered/not answered logic is easy but it's not) but then remembered I no longer work there lol voip is complex and if you try to make something secure out of it, you'll spend most of the effort simply disabling weird features no one in their right mind would ever want, but which are standard part of the protocol stack. google project zero has tackled an "easy" aspect of voip complexity so far (the [whatsapp] media streams, once stripped of encryption) but state machines is where the fun is if you ask me last voip client I wrote was a windows app with support for call conferencing. it's a wpf app with a native core. while I was working on porting the native core to windows, we outsourced the wpf part to a guy in a partner company. I described him in general terms the architecture that he needed to implement (that I was pretty familiar with, having previously written three other voip apps), mentioning the need for a central "call manager" class that could mediate between the ui and the core. couple weeks later he says "I don't know if we'll need a "call manager" class actually". couple months later I relieve him and take over the wpf side, and basically throw his work away and redo it. CallManager and related classes ended up taking several klocs of C# for the barest-bonest feature set that would barely fulfill the terms of the contract (in addition to the several klocs of C++ for the multiplatform core and the dozens of klocs of C for the third party sip stack plus codec). this is tiny for voip standards, even a simple application like Signal is about an order of magnitude bigger hackbunny fucked around with this message at 00:20 on Jan 31, 2019 |
|
|
|
this is a little too specific for me to comment on but, have you ever seen a good build tool? in my experience, properly used autoconf/automake has everything else beat (pity about windows support). emphasis on "properly used" because tons of projects do poo poo like hardcoding CFLAGS in their configures, that the autoconf manual explicitly tells you not to. I used cmake once or twice, when I was forced to (eg. google loves it. I mean it beats their old ndk build tool but...) and I had a really bad impression, especially using non-conventional toolchains and/or cross-compiling really I don't see any c/c++ build environment succeeding unless they let you do the autoconf/automake thing of enforcing a common set of compiler flags for all projects you build as part of a matching set. c/c++ compilers are like non-standard-mutually-incompatible-abi generation machines, and forcing your static libraries to compile with COMDATs, LTCG, etc. or your dynamic libraries to all link to the same runtime library etc. is a necessity I mentioned that I used to work on a cross-platform voip thing, that shared a common c/c++ core between three platforms. the core, in turn, depended on and statically linked to several third party libraries (sip stack, audio codec, crypto libraries, etc.). on android and ios, the third party dependencies were built, slowly and thoroughly, by a bash script that built each dependence six times (three architectures x two configurations), making full use of autoconf's unique features like --prefix, $CFLAGS, etc. which ensured uniform results, among which the correct ARM ABI, debugging symbols in a consistent format and true whole program optimization. the apps themselves were built in the official ides instead, and referred to the third party libraries as external dependencies that incidentally happened to be under a subdirectory of the project of course it all went to poo poo in the windows port, and not for lack of trying on my part (you have no idea how many combinations of cygwin, mingw and random wrapper scripts I tried. I even tried and failed to build a cygwin-win32 clang cross compiler), so I just bit the bullet and decided to use the dodgy visual studio project files that many projects, usually out of pity, bundle. I could kind of force all projects to build under a consistent set of toolchain/target/options, with only minimal changes to the project files (mostly to include a couple of per-solution property files that overrode the tragic defaults), a solution that I only resorted to after days of futilely reading msbuild documentation and unanswered stackoverflow questions. but I know how fragile compiling c/c++ code can be, and how consistent build options are a moral duty, and I endured it (hardest one to integrate was openssl, that must be built with a homegroan perl/make based build system. I wrapped the homegroan with a powershell script - specifically powershell and not batch so that I could serialize builds using a mutex named after the path of the source directory, because openssl doesn't support parallel builds until 1.1 - and the script with a visual studio project. worked like a charm. I pity whoever has to maintain that now) at new job, we get third party dependencies from NuGet repositories, both public and internal, and it sucks. there are no two libraries built with the same options. you can't upgrade or downgrade packages because only a narrow range of versions is built with the same version of visual studio or the same runtime library as your project. half of the libraries don't come bundled with debugging symbols at all. total clown show. basically only linux distributions and bsd ports trees get it right (at the cost of increased maintenance and/or compilation as part of installation), everyone else likes to pretend the problem of binary distribution is easy and maybe even attacks you for "making" it complicated basically, slurps, please swear to me that c++ modules will get it right
|
|
|
|
cinci zoo sniper posted:that’s normal, building things is run, maintaining them - not so much I'm a sick bastard who actually likes maintenance more than building
|
|
|
|
building gives me anxiety, I never know where to start. maintenance involves reverse engineering, which is my true calling
|
|
|
|
cinci zoo sniper posted:so that’s why you know so much about windows unironically 100% correct. I learned a lot about windows by trying to do new things with it while working within it
|
|
|
|
aardvaard posted:i have 800+ passwords in my password database. admitting you have a problem is the first step to recovery aardvaard posted:oh, it all makes sense now nice deflection
|
|
|
|
DaTroof posted:i used git for years before squash or rebase seemed like poo poo i might ever need. merge was plenty adequate I use interactive rebase a lot. I fork the project repository and force-push feature branches there until they're ready for prime time. I wish there was an easy way to split a commit into multiple commits without a ton of amends and squashes, though I've never learned a single command line option for git. SourceTree isn't great but it does almost everything I need, the only times I use the command line is for obscure things like recovering commits I unlinked by mistake (it turns out it really helps to think of a git repo as a graph - if you use a gui client and learn the weird names that were given to git concepts) Corla Plankun posted:add, commit, and merge are all you need unless you're one of those people who cares about git history being pleasant in any way commits are documentation, and writing documentation is half of your job as a software engineer. a good commit history is vital to continuous integration, regression testing and bisection, all tools as important to making software as editors and compilers
|
|
|
|
Krankenstyle posted:I usually just amend my most recent commit continually until I'm done with the feature I've been bitten by enough regressions hidden in giganto-commits that I split my commits up as much as possible. it's a little tedious because git doesn't make it easy, and also because I'm a pedant and I make sure every single commit at least compiles right (without a test suite, I can't make sure they don't introduce regressions, but by keeping commits small and buildable I'm making bisection possible), but I take it as a chance to re-read the code and often re-write it in a better way, or catch bugs. if I had tests I would feel a little more confident and would do much less grunt work, but I don't, and until I write some, I feel a responsibility to write code a little slower in exchange for more rigour
|
|
|
|
Soricidus posted:I find it helps to think of git as like a monad, but on the blockchain git commits are linked together, each commit has a pointer to its predecessors. they form an immutable data structure, so editing a commit necessarily involves recreating all successors - this is the meaning of "rebase", and the reason why a rebase changes the hashes of all commits downbranch. what are tags and branches? they're global variables, GC roots, nothing more and nothing less, and now you know how to recover a lost commit, or how not to lose a commit in the first place (just tag it) if you're a programmer in literally any language, you already have a good mental model of git
|
|
|
|
|
| # ¿ Dec 13, 2025 07:58 |
|
Corla Plankun posted:documentation is obsolete almost the second it is written and its a waste of time to try to fight technical debt with words nobody will ever read quit your job commit messages document intent and context, they're historical data and by definition can't ever get obsolete. it's vital irreplaceable information that degrades fast if not written down, and you'll be sorry six months from now when a complex uncommented line that's blatantly stupid but you can't tell if it's related to the bug you're working on was added in a commit with message "bugfixes" in closing, quit your job Sapozhnik posted:git reset HEAD^ huh for no reason at all I thought you couldn't continue an interactive rebase after that Powerful Two-Hander posted:I am almost certain nobody reads the docs I write. write documentation that will be useful for yourself
|
|
|




probably nodejs idk