|
I like C++ and think RAII and templates are beautiful animals and creatures of God. I mostly use C# for work and I'm often annoyed that what could be like 5 lines of clear C++ either has to be 100 copy-pasted lines, or something that will generate loads of garbage. And all this "syntactic sugar" that expands to a multi-kb class that'll be instantiated every time a function is called. Ugh. There's a complex language. I wouldn't call the project my horror is from C++ though. It's basically made out of macros and WTFs. It has a scripting engine where the script data is just a big pile of bytes that gets cast to function pointers and whatnot. There's a bunch of ifdefs and macros to fix up some stuff in case a platform doesn't support unaligned access because lol that obviously bit them in the rear end when they tried to run it on something that wasn't x86  Xerophyte posted:This probably compounds the horror, but that particular Terrible No Good Very Bad Idea seems to have come from Bjarne himself. At least Bjarne's thing seems to be some sort of allocator. Placement new on an allocator looks weird but might be possible to figure out, but on a list it just looked like an obvious bug. Also yes, the constructor would be called in this case... Just remember that Add() does not actually add anything, it just moves the end pointer or whatever one step, and you'll have to construct your thing yourself. They've cut a vector in half to expose its gross guts  I can think of like 50 ways to do this in a better way, even before C++11. We worked on a 3DS project many years ago, and the compiler (which always stopped working because its license ran out every week) did not support that, but I managed to add rudimentary move semantics anyway (basically a member function called "move" that'd be called instead of the copy constructor when possible. Groundbreaking stuff really). My lovely custom vector even had a proper emplace function 
|
#
?
Jun 10, 2018 13:26
|
|
|
|
| # ? May 30, 2024 23:04 |
|
|
Need to get the rest of the Knights of C++ in here, like slurps mad rips and rjmccall and hackbunny. C++ is a great language though I will admit the ratio of doing something useful : doing something masturbatory can be... off.
|
|
#
?
Jun 10, 2018 14:23
|
|
|
Linear Zoetrope posted:No, you mathematically can't fully specify any turing-complete language in BNF because BNF is context free which is a strict subset of Turing Completeness (since BNF has a bijection with pushdown automata). What? Just because a language is turning complete doesn't mean it's syntax is, or would need to be.
|
|
#
?
Jun 10, 2018 15:30
|
|
|
The past year, for the first time in my life, I could finally use C++ to its fullest extent for real software (vs personal experimentation) and I have to say I greatly enjoyed it and have had remarkably few issues. Biggest issues were:
Best part overall was I got to pick my favorite degree of compromise between generic and polymorphic on a case-by-case basis, which no other language that I know of allows. Worst part? The different degrees of support and/or quirks between the various compilers, that you can often not be sure whether they're bugs or not I also can't imagine any other language that could form the core of a multi-platform (iOS, Android, Windows) application and interoperate with languages as diverse as Swift, Java and C# and not be a hell of manual resource management like C C++ is good and I like it
|
|
#
?
Jun 10, 2018 15:37
|
|
|
It seems like the people who really like C++ are the ones who are real experts at C++. That's not the case with proponents of every language. I'm not sure if that means its good or bad.
|
|
#
?
Jun 10, 2018 15:39
|
|
|
hackbunny posted:I really enjoyed some of the "controversial" additions to the standard library, like the std::chrono stuff, that spared me a ton of headaches (I really wish there was a better way to format a date-time than strftime, though) and seemed tailor made for my scenario, where I juggle up to four different timestamp types at the same time Have you taken a look at date.h? We've used it at work to great effect. Thermopyle posted:It seems like the people who really like C++ are the ones who are real experts at C++. That's not the case with proponents of every language. I like C++ and I am by absolutely no means an expert.
|
|
#
?
Jun 10, 2018 16:47
|
|
|
QuarkJets posted:You could describe pretty much every popular programming language in that way Not at all, some of them have decent build systems.
|
|
#
?
Jun 10, 2018 16:58
|
|
|
Absurd Alhazred posted:I like C++ and I am by absolutely no means an expert. Well my hypothesis has been utterly destroyed.
|
|
#
?
Jun 10, 2018 17:50
|
|
|
Thermopyle posted:Well my hypothesis has been utterly destroyed.  To be fair, I have also been repeatedly told that I am a glutton for punishment.
|
|
#
?
Jun 10, 2018 17:51
|
|
|
ratbert90 posted:Lol c++ isn’t complicated. What in the gently caress are you talking about? one of my first hurdles with commercial c++ came when I realized that microsoft alone used over sixteen different string types in the windows api ( char*, wchar_t*, LPSTR, LPTSTR, LPWSTR, LPCSTR, LPCTSTR, LPCWSTR, BSTR, OLESTR, UNICODE_STRING, String, string, wstring, _bstr_t, CString)
|
|
#
?
Jun 10, 2018 18:09
|
|
|
There are no bad programming languages, there are only
|
|
#
?
Jun 10, 2018 18:55
|
|
|
Bruegels Fuckbooks posted:one of my first hurdles with commercial c++ came when I realized that microsoft alone used over sixteen different string types in the windows api ( char*, wchar_t*, LPSTR, LPTSTR, LPWSTR, LPCSTR, LPCTSTR, LPCWSTR, BSTR, OLESTR, UNICODE_STRING, String, string, wstring, _bstr_t, CString) TBH this doesn't really sound like a problem with C++
|
|
#
?
Jun 10, 2018 19:02
|
|
|
https://twitter.com/johnregehr/status/1005877520208498688
|
|
#
?
Jun 10, 2018 19:24
|
|
|
Bruegels Fuckbooks posted:one of my first hurdles with commercial c++ came when I realized that microsoft alone used over sixteen different string types in the windows api ( char*, wchar_t*, LPSTR, LPTSTR, LPWSTR, LPCSTR, LPCTSTR, LPCWSTR, BSTR, OLESTR, UNICODE_STRING, String, string, wstring, _bstr_t, CString) You're forgetting _TCHAR *  There are reasons for each of them, though. Good reasons? I don't know
|
|
#
?
Jun 10, 2018 19:40
|
|
|
VikingofRock posted:TBH this doesn't really sound like a problem with C++ im pretty sure everyone wouldn't make their own string type if strings in C++ didn't suck nuts.
|
|
#
?
Jun 10, 2018 20:06
|
|
|
It's cool.
|
|
#
?
Jun 10, 2018 20:19
|
|
|
hackbunny posted:You're forgetting _TCHAR * Unix is even older than Windows, so how come the POSIX API is (relatively speaking) so much simpler? It's at least not nearly as typedef-polluted. Also the type names are not in SCREAMING CAPS, but that's probably a pretty subjective preference.
|
|
#
?
Jun 10, 2018 21:23
|
|
|
Bruegels Fuckbooks posted:im pretty sure everyone wouldn't make their own string type if strings in C++ didn't suck nuts. strings in C++ aren't great but they aren't terrible either the problem here is really 1 org creating a new string type over and over and over
|
|
#
?
Jun 10, 2018 21:30
|
|
|
Bruegels Fuckbooks posted:im pretty sure everyone wouldn't make their own string type if strings in C++ didn't suck nuts. maybe i don't have enough experience, but i never had many complaints about std::string. especially compared to the special snowflakes involved every time you needed to manipulate strings in c
|
|
#
?
Jun 10, 2018 21:35
|
|
|
Formally, every programming language has a hierarchy of well-formedness conditions, and you can imagine each of these as inducing its own language, with each step creating a subset-language of the previous. The lexical language is usually regular, although languages with nestable multi-line comments are a notable exception. The grammatical language is usually context-free, and in some sense this is true even for languages with lookup-sensitive parsers like C++, where there might just be more than one valid parse of a given input if you ignore contextual information. As for the actual language, well, it’s common for languages to have at least some well-formedness conditions that aren’t context-free, e.g. lexical lookup of unqualified names so that obvious typos in variable references can be reported immediately. That alone is well beyond the capabilities of a PDA, much less any sort of type system, even if deciding it isn’t actually Turing-complete.
|
|
#
?
Jun 10, 2018 21:47
|
|
|
Athas posted:Unix is even older than Windows, so how come the POSIX API is (relatively speaking) so much simpler? It's at least not nearly as typedef-polluted. Also the type names are not in SCREAMING CAPS, but that's probably a pretty subjective preference.
|
|
#
?
Jun 10, 2018 23:12
|
|
|
Athas posted:Unix is even older than Windows, so how come the POSIX API is (relatively speaking) so much simpler? It's at least not nearly as typedef-polluted. Also the type names are not in SCREAMING CAPS, but that's probably a pretty subjective preference. Oh it's easy, they just ignored Unicode for a long time. They never upgraded the API to wchar_t and just toughed it out, requiring conversion of all strings to/from the current encoding until someone came up with a magic universal encoding (UTF-8), and even then it took a long time before it was adoped Then you have to consider that Windows had to run on 16 bit machines with more than 64 KB of RAM, requiring segmentation: so you not only had char * and wchar_t *, but also char __near *, char __far *, wchar_t __near * and wchar_t __far *. Since all pointers in the Windows API were far pointers (32 bit "fat" pointers - 16 bits for the segment identifier, 16 bits for the actual pointer, i.e. offset from the start of the segment), you had to write char __far * every time (because, based on compiler settings, the implied default might be __near), which makes "LPSTR" start to look reasonable (LP = long-sized pointer, i.e. 32 bit far pointer). But, considering how the C syntax works, you can't easily declare a pointer to a constant string - const LPSTR makes the pointer constant, not the string. So you get LPCSTR. Why have both LP[C]CHAR and LP[C]STR, though? because the former is a pointer to a character, the latter is a pointer a nul-terminated string. For a long time, the compiler couldn't actually tell the difference between the two, but once the compiler started supporting the appropriate annotations, they could be added to the typedef in a perfectly backwards-compatible way Multiply by two for WCHAR strings (why "WCHAR"? because the compiler might not support wchar_t, and WCHAR in that case would be an alias for unsigned short). How to convince people to upgrade their codebases to wide strings, though? Enter TCHAR and related typedefs, which map to CHAR by default, and WCHAR if UNICODE is #defined, so you can mechanically convert your codebase to TCHAR, then define UNICODE, then fix the issues, then switch to Unicode-only. This multiplies the typedefs by three Then, remember that on Windows, the C runtime library is just a regular library, not the official platform API, so the whole thing was done a second time for the C runtime. All C string APIs got a wcs counterpart that dealt with wchar_t strings, whether the ANSI standard specified it or not (the non-standard ones were prefixed with an underscore). They also added a _TCHAR typedef, that worked much like the Windows SDK counterpart, except that its definition depended on the _UNICODE #define (as a compiler vendor, Microsoft was allowed to extend the C standard as long as the extensions were prefixed with an underscore), and _tcs macros for all string functions that expanded to either the str or wcs variant based on the presence of _UNICODE (Borland went one step further, and _tcs macros could also expand to _mbcs-prefixed functions, that could deal with char strings in variable-width encodings; the #define was _MULTIBYTE IIRC). The C runtime was spared from the __near vs __far mess, because vendors provided separate C runtime binaries for each memory model, so all pointers in the C runtime could simply be undecorated and use the default width. Windows couldn't have separate binaries for its runtime libraries at the time, and they wouldn't have done it anyway as it would have been considered an extravagant waste of memory. The fact that Windows always used long pointers while the C runtime might not is the reason functions like _lstrlen are part of the Windows API: you couldn't reliably pass a Windows string to strlen/wcslen, because you might have been using a memory model with near pointers, so Windows gave you a small subset of the C string API that always took long pointers as arguments BSTR and OLESTR are OLE stuff. OLE and the Windows API evolved in parallel (OLE is positively ancient, predating both Win32 and COM), so there's a lot of duplication. OLE 2 in particular always supported Unicode, so OLECHAR always maps to wchar_t (or unsigned char)... on Windows, at least. The Mac and UNIX ports of OLE (used for porting, respectively, Office and Internet Explorer) typedef it to char. OLESTR is a string of OLECHAR and BSTR would appear to be the same thing, but BSTR strings are not just strings of OLECHARs, they are Pascal strings of OLECHARs, with a hidden length field before the first character, and can have embedded null characters. If an API takes a BSTR, you really want to pass a real BSTR, properly allocated and initialized with BSTR functions, and not just a random pointer to an OLECHAR string and wstring (specializations of template class basic_string) are standard C++ implementations of a dynamically allocated C string, so I wouldn't really count them as separate things. In fact, they work well with Windows character/string types, and a basic_string<TCHAR> can be quite handy (just don't pass a basic_string<OLECHAR> to a BSTR argument!) _bstr_t is a C++ wrapper for BSTR provided as an extension by the Microsoft C++ runtime. It's automatically pulled in by the Microsoft C++ compiler's COM/OLE support, but it can also be used stand-alone. It's really handy as the BSTR API is a natural fit for this kind of wrapper, and you'd end up writing your own anyway CString comes from the MFC and/or ATL frameworks, only relevant if you use those frameworks. If you do, they can do a lot to reduce the confusion between all the string types, as they provide handy functions to convert between all of them, regardless of what combination of UNICODE and _UNICODE you're using
|
|
#
?
Jun 10, 2018 23:16
|
|
|
boo_radley posted:A voice whispers in your ear, "MUMPS". MUMPS has its uses. Next time I need to write a hospital billing system in the 1970s I'll definitely use MUMPS.
|
|
#
?
Jun 10, 2018 23:16
|
|
|
I heard MUMPS is coming back because of anti-vaxxers.
|
|
#
?
Jun 10, 2018 23:22
|
|
|
anti-VAXers
|
|
#
?
Jun 10, 2018 23:31
|
|
|
hackbunny posted:Oh it's easy, they just ignored Unicode for a long time. They never upgraded the API to wchar_t and just toughed it out, requiring conversion of all strings to/from the current encoding until someone came up with a magic universal encoding (UTF-8), and even then it took a long time before it was adoped Hey thanks for that great explanation, Bill. Hope you're having a good Sunday. How's Melinda? Tell her the thread says hi, have a good day
|
|
#
?
Jun 11, 2018 01:18
|
|
|
hackbunny posted:Oh it's easy, they just ignored Unicode for a long time. They never upgraded the API to wchar_t and just toughed it out, requiring conversion of all strings to/from the current encoding until someone came up with a magic universal encoding (UTF-8), and even then it took a long time before it was adoped whycppisadisaster.txt
|
|
#
?
Jun 11, 2018 01:55
|
|
|
Taffer posted:whycppisadisaster.txt None of this really has to do with C++, though. It's Windows API, you can live blissfully unaware of this nonsense until you have to make a direct Win32 call, and even then you won't run into most of these, or they're hidden behind convenience macros.
|
|
#
?
Jun 11, 2018 02:13
|
|
|
Taffer posted:whycppisadisaster.txt Did you not read the post, or?
|
|
#
?
Jun 11, 2018 02:17
|
|
|
Absurd Alhazred posted:you can live blissfully unaware Pretty good summary of how I code to be honest.
|
|
#
?
Jun 11, 2018 02:17
|
|
|
hackbunny posted:Windows couldn't have separate binaries for its runtime libraries at the time, and they wouldn't have done it anyway as it would have been considered an extravagant waste of memory. OK I think this part may not make much sense, actually, in that I doubt you could make a DLL that takes near pointer arguments for its functions. On the other hand, UNIX did let you statically link to the system libraries, and Windows could have done the same. But it didn't because of, I suspect, inter-process fuckery requirements, which probably were only part of the design because the extremely low memory footprint demanded DLLs loaded in shared memory, which in turn enabled inter-process fuckery, the two horrible things circularly justifying each other (and causing endless grief for the people who had to port Windows to the Windows NT kernel, and a long tail of security vulnerabilities that still isn't over) hackbunny fucked around with this message at 02:31 on Jun 11, 2018 |
|
#
?
Jun 11, 2018 02:22
|
|
|
Athas posted:Unix is even older than Windows, so how come the POSIX API is (relatively speaking) so much simpler? It's not. Popular UNIXen of the day (IRIX / Tru64 / HP/UX / IBM AIX) had wacky Unicode support that mirrors what you see in the Windows API. When the POSIX effort started in the late 90s, they were basically tossed out the window in favor of just not using Unicode. Even in POSIX, the locale system (LANG, LC_ALL, etc.) is probably one of the gnarliest and worst parts. The infamous C.utf8 locale is not a standard of any sort, it's a Linux-ism. All of this still causes headaches today.
|
|
#
?
Jun 11, 2018 04:04
|
|
|
Hi everyone! It's Monday so I guess there must be a new node vulnera.... yep The source code of node-macaddress posted:exec("cat /sys/class/net/" + iface + "/address", function (err, out) { Ofcourse the people looking at these security disclosures can't reach the original maintainer since he probably went on to program in golang, but good news: Hackerone posted:Doesn't look epic to me, also last publish was 3 years ago. Thankfully it doesn't look epic, it only has 1,325,674 weekly downloads so I guess nobody's using it.
|
|
#
?
Jun 11, 2018 16:36
|
|
|
And naturally a HN poster sees nothing wrong with a function for getting the MAC address for a network interface allowing arbitrary code execution:quote:I hate to be an apologist for this kind of thing, but this vulnerability is in the same time zone to me as saying mysql2 has a critical vulnerability if attackers get access to connection.query's first argument.
|
|
#
?
Jun 11, 2018 21:40
|
|
|
Taffer posted:whycppisadisaster.txt Yeah you're not wrong. C++ does have a standard string type and a standard memory allocator, but everyone, rightly or wrongly, seems to find reasons to make their own special snowflake ones. Other languages simply don't give you a choice and are better (for a certain measure of "better") for it
|
|
#
?
Jun 11, 2018 22:08
|
|
|
feedmegin posted:Invent ur own plang imo. Mine is a cross of statically typed and compiled Python quote:and Pascal
|
|
#
?
Jun 11, 2018 22:09
|
|
|
I miss Pascal. 
|
|
#
?
Jun 12, 2018 02:54
|
|
|
hackbunny posted:Yeah you're not wrong. C++ does have a standard string type and a standard memory allocator, but everyone, rightly or wrongly, seems to find reasons to make their own special snowflake ones. Other languages simply don't give you a choice and are better (for a certain measure of "better") for it All that WinAPI stuff is C though, written long before there even was a C++ standard, and any new stuff has to be backwards compatible with that. If they could rewrite it all from scratch using actual C++ hopefully they would use the standard library and UTF-8 (or at least one consistent encoding for everything). They would have to come up with a canonical C++ ABI though, so it would at least work across DLL boundaries, which is currently pretty difficult and requires everything to be compiled with exactly the same settings on exactly the same compiler.
|
|
#
?
Jun 12, 2018 10:46
|
|
|
Mooey Cow posted:All that WinAPI stuff is C though, written long before there even was a C++ standard, and any new stuff has to be backwards compatible with that. If they could rewrite it all from scratch using actual C++ hopefully they would use the standard library and UTF-8 (or at least one consistent encoding for everything). They would have to come up with a canonical C++ ABI though, so it would at least work across DLL boundaries, which is currently pretty difficult and requires everything to be compiled with exactly the same settings on exactly the same compiler. Other languages do this just fine  They're just like "this is your string type, this is your allocator type, now gently caress off". But C or C++? It's all "my business case absolutely requires custom everything"
|
|
#
?
Jun 12, 2018 11:03
|
|
|
|
| # ? May 30, 2024 23:04 |
|
|
Mooey Cow posted:All that WinAPI stuff is C though, written long before there even was a C++ standard, and any new stuff has to be backwards compatible with that. If they could rewrite it all from scratch using actual C++ hopefully they would use the standard library and UTF-8 (or at least one consistent encoding for everything). They would have to come up with a canonical C++ ABI though, so it would at least work across DLL boundaries, which is currently pretty difficult and requires everything to be compiled with exactly the same settings on exactly the same compiler. If you use the managed-code based (C# and such) API, it's much more modern. But that has its own overhead.
|
|
#
?
Jun 12, 2018 13:13
|
|