|
looks like older C++ uses 0 as NULL (since it's defined in C's stddef.h) but C++11 defines nullptr which has distinct behaviour similar to what was discussed earlier I feel like it's still a good idea to check it before you try to use it for anything though
|
# ? Mar 25, 2016 00:31 |
|
|
# ? May 25, 2024 01:45 |
|
Notorious QIG posted:in c++ at least, the following code behaves very differently if you substitute 0 for NULL: On what compiler? Once you have assigned any special characteristics of NULL would be lost. http://codepad.org/ZkzxiUOu Interesting that cout loves making GBS threads itself trying to print a unsigned char pointer. MrMoo fucked around with this message at 00:47 on Mar 25, 2016 |
# ? Mar 25, 2016 00:44 |
|
Notorious QIG posted:in c++ at least, the following code behaves very differently if you substitute 0 for NULL: this is completely wrong by both the standard and in practice in practice NULL is #define NULL 0 everywhere, so they're obviously the same thing. per the standard NULL isn't required to be an all-zero bit pattern, but nonetheless 0 is defined to be a null literal, which means that uint8_t* x = 0; will result in x not having the value 0 if your platform uses something else for null pointers
|
# ? Mar 25, 2016 01:02 |
|
GrumpyDoctor posted:lol what was the bug #include <unistd.h> for (; { fork(); }
|
# ? Mar 25, 2016 03:11 |
|
Progressive JPEG posted:#include <unistd.h>
|
# ? Mar 25, 2016 04:27 |
|
Plorkyeran posted:this is completely wrong by both the standard and in practice gently caress me apparently youre right its me im the terrible programmer (well in c++11 it can also be std::null_ptr but w/e)
|
# ? Mar 25, 2016 05:04 |
|
std::null_ptr is the most obtuse and pedantic poo poo everybody still using c++ knows wtf NULL means and it aint gonna change
|
# ? Mar 25, 2016 05:08 |
|
Plorkyeran posted:this is completely wrong by both the standard and in practice i don't know c++ but this post is correct wrt c
|
# ? Mar 25, 2016 05:15 |
|
Notorious QIG posted:well then it's a loving stupid standard it's "a" standard which is a lot better than being in the "just do whatever" universe
|
# ? Mar 25, 2016 05:19 |
|
Progressive JPEG posted:std::null_ptr is the most obtuse and pedantic poo poo we use nullptr all thru our code base and I like it
|
# ? Mar 25, 2016 05:23 |
|
fritz posted:we use nullptr all thru our code base and I like it we don't do any of the usual nonsense that would make it necessary like overloading functions to use both an int and a pointer but types are types and use em if you got em
|
# ? Mar 25, 2016 05:25 |
|
one sentence answer please why do people think NULL is a travesty?
|
# ? Mar 25, 2016 05:56 |
|
it's bad
|
# ? Mar 25, 2016 06:00 |
|
sund posted:one sentence answer please why do people think NULL is a travesty? allowing any pointer/reference to be set to null without representing it in your type system leads to many difficult to detect errors that are impossible to write in languages with more advanced type systems
|
# ? Mar 25, 2016 06:03 |
|
Notorious QIG posted:in c++ at least, the following code behaves very differently if you substitute 0 for NULL: thats not true at all. null is 0.
|
# ? Mar 25, 2016 07:03 |
|
its ok, just prefix literally every statement with if x is not null
|
# ? Mar 25, 2016 07:05 |
|
Progressive JPEG posted:std::null_ptr is the most obtuse and pedantic poo poo its useful in case you have something like this: code:
|
# ? Mar 25, 2016 07:06 |
|
fart simpson posted:its ok, just prefix literally every statement with if x is not null or like just once edit: like if whatever function is supposed to create the object to begin with returns null then maybe you want to error out gracefully instead of trying to ram it through BattleMaster fucked around with this message at 07:54 on Mar 25, 2016 |
# ? Mar 25, 2016 07:13 |
|
BattleMaster posted:or like just once which is trivial to do if your language doesn't even have the concept of a "null" object, or if it explicitly provides support for declaring a type as definitively not null. but is actually quite difficult in the real world if you don't have that sort of enforcement baked in to the language. saying "just remember to check it" stops working once you have more than one person working on a project, or work on it for long enough that you don't have knowledge of the entire codebase in your head all at once. the way c# does it with non-nullable value types being the default, but you can easily declare a foo-or-null (i.e. foo?) variable if you need it, is pretty great. it's a real shame they didn't do the same thing with reference types.
|
# ? Mar 25, 2016 12:16 |
|
i guess that's why we're having this conversation in the terrible programmers thread because you have to be pretty terrible to not check returns like i don't even know any language that doesn't throw an exception or segfault or otherwise stop and freak out the moment you try to dereference a null or treat a null object like a real object so either way you're going to get a reminder pretty quickly that you hosed up BattleMaster fucked around with this message at 12:35 on Mar 25, 2016 |
# ? Mar 25, 2016 12:30 |
|
BattleMaster posted:i guess that's why we're having this conversation in the terrible programmers thread because you have to be pretty terrible to not check returns yes, the issue is making sure that doesn't happen do you seriously explicitly check every return value for null? everything you pull out of a collection? even all those ones that you know, for sure, can "never" be null? I bet you don't.
|
# ? Mar 25, 2016 12:38 |
|
Soricidus posted:yes, the issue is making sure that doesn't happen well if the function doesn't ever return null then the problem being discussed wouldn't happen so there's no reason to check it in that case i think it's up to you to know if the function you're calling can return null if it fails and check in that case maybe you don't know every in and out of the code base but i think it's also up to you to quickly check the docs or even just use intellisense or whatever before you call a function if you're not sure realtalk what language even has a feature that prevents you from ever having to check return values for null and what is this feature? (edit: the program stopping the second you try to work with a null doesn't count because that's not functionally any different from a segfault in a lower level language) BattleMaster fucked around with this message at 12:45 on Mar 25, 2016 |
# ? Mar 25, 2016 12:42 |
|
BattleMaster posted:well if the function doesn't ever return null then the problem being discussed wouldn't happen so there's no reason to check it in that case any languages which marks references that can be null and references that cannot be null. the ones that can you still have to check but you know 100% which ones that you don't. compare to not having compiler assistance in figuring out which references can be null or not.
|
# ? Mar 25, 2016 12:48 |
|
BattleMaster posted:well if the function doesn't ever return null then the problem being discussed wouldn't happen so there's no reason to check it in that case
|
# ? Mar 25, 2016 12:53 |
|
it's up to you to know what a function is supposed to return before you call it, like i don't see how this is controversial, how do you even program if you just go "durr hurr i don't know what this function does *calls it anyway*"
|
# ? Mar 25, 2016 12:56 |
|
BattleMaster posted:maybe i just use C too much because i don't see what's wrong with null being 0 c's type system is much weaker than java's, and pointers are basically integer types so 0 kind of makes sense in c's context. though 0 being a good value for null is more a side-effect of operating system structure, and a better language would have a type explicitly indicating the lack of a valid pointer instead of using a potentially valid address for that in Java, null is an instance of NullType, a type that is a subtype of all non-primitive types in Java. so for one thing it has no actual relation to the number 0 in much the same way null couldn't be considered an empty string. however both c# and java have implicit conversions to 0 as an artifact from c/c++. in any case, you really shouldn't be using null in either c# or java, and if it weren't for backwards compatibility it would (and should) be removed. I said before that NullType is a subtype of all reference types in java. this fact makes it a pseudo (or near) bottom type. a true bottom type is a subtype of all types, and it is not instantiable unlike how null is an instance of NullType. languages with bottom types are able to define types that remove the need for null (called Option or Maybe) to indicate the possibility of a lack of data. using such techniques leverages the compiler to force the programmer to deal with the possible lack of data instead of relying on him remember to check. here's an example: code:
|
# ? Mar 25, 2016 12:58 |
|
Progressive JPEG posted:std::null_ptr is the most obtuse and pedantic poo poo yeah, if you are a scrub-tier C++ programmer. me, I welcome a null constant that isn't secretly an int. way too much poo poo in C++ can convert implicitly to and from int
|
# ? Mar 25, 2016 12:59 |
|
nullptr (or other explicit null values that aren't 0) and being able to mark things as potentially being null is cool and good but it's still up to you to know what your poo poo could return
|
# ? Mar 25, 2016 13:01 |
|
sund posted:one sentence answer please why do people think NULL is a travesty? because it's used to indicate the lack of information in a way the compiler can't force you to deal with
|
# ? Mar 25, 2016 13:04 |
|
C++ is not Java, you won't see any NULLs unless you write code that creates NULL pointers explicitly. especially in modern C++, you're likely to see no naked pointers, period
|
# ? Mar 25, 2016 13:07 |
|
BattleMaster posted:it's up to you to know what a function is supposed to return before you call it, like i don't see how this is controversial, how do you even program if you just go "durr hurr i don't know what this function does *calls it anyway*" well duh, it's so loving easy!
|
# ? Mar 25, 2016 13:14 |
|
Wheany posted:well duh, it's so loving easy! yep edit: unironically yep, in over a decade of this poo poo i haven't had any particular issues in figuring out if a function can return null and if so, making sure it's not null before proceeding like gently caress it i've written winapi poo poo which is notoriously poorly documented and they're pretty explicit about that, if your project's or api's docs are worse than that then my condolences BattleMaster fucked around with this message at 13:28 on Mar 25, 2016 |
# ? Mar 25, 2016 13:22 |
|
compilers won't even warn you if you forget to check though
|
# ? Mar 25, 2016 14:09 |
|
BattleMaster posted:nullptr (or other explicit null values that aren't 0) and being able to mark things as potentially being null is cool and good but it's still up to you to know what your poo poo could return yes why would you want information about what a function returns encoded in the type system
|
# ? Mar 25, 2016 14:14 |
|
suffix posted:yes why would you want information about what a function returns encoded in the type system i said those are great i just don't use languages that have them lol it's important to know what your function is going to return and that helps, but if you don't have that available then you'd better find out edit: like seriously: "knowing what functions return is good" -a controversial opinion BattleMaster fucked around with this message at 14:17 on Mar 25, 2016 |
# ? Mar 25, 2016 14:15 |
|
never return anything and just make everything happen through side effects
|
# ? Mar 25, 2016 14:19 |
|
BattleMaster posted:it's up to you to know what a function is supposed to return before you call it, like i don't see how this is controversial, how do you even program if you just go "durr hurr i don't know what this function does *calls it anyway*" The problem isn't determining what a function does today, it's what the intern does when he gets into the code next year, and decides this function should just return null in this particular circumstance because durrhurr i'm an intern. Just because you know what a function does today doesn't mean you know what it does tomorrow.
|
# ? Mar 25, 2016 14:29 |
|
okay that's fair
|
# ? Mar 25, 2016 14:30 |
|
BattleMaster posted:yep are you saying that your code has never had a nullpointerexception?
|
# ? Mar 25, 2016 14:30 |
|
|
# ? May 25, 2024 01:45 |
|
Wheany posted:are you saying that your code has never had a nullpointerexception? i've never programmed anything serious in a language with exceptions if you mean the general case of "have I ever accidentally dereferenced a null pointer" no one's perfect but i don't think it's a tall order to do your best to find out what a function will return lovely interns and lovely docs aside i don't think it's intrinsically a difficult task and yay if your language helps out BattleMaster fucked around with this message at 14:37 on Mar 25, 2016 |
# ? Mar 25, 2016 14:33 |