terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

BattleMaster: Aug 14, 2000

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

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 02:54

MrMoo: Sep 14, 2000

Notorious QIG posted:

in c++ at least, the following code behaves very differently if you substitute 0 for NULL:
code:
uint8_t* x = NULL;
x++;
std::cout << *x;
if x is NULL, this segfaults because you can't increment past NULL. if x is 0, this will print the contents of the memory located at 0x8, which under certain compilers is a-ok

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Notorious QIG posted:

in c++ at least, the following code behaves very differently if you substitute 0 for NULL:
code:
uint8_t* x = NULL;
x++;
std::cout << *x;
if x is NULL, this segfaults because you can't increment past NULL. if x is 0, this will print the contents of the memory located at 0x8, which under certain compilers is a-ok

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

Progressive JPEG: Feb 19, 2003

GrumpyDoctor posted:

lol what was the bug

#include <unistd.h>

for (;

{
fork();
}

# ? Mar 25, 2016 03:11

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Progressive JPEG posted:

#include <unistd.h>

for (; {
fork();
}

# ? Mar 25, 2016 04:27

quiggy: Aug 7, 2010; [in Russian] Oof.

Plorkyeran posted:

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

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

Progressive JPEG: Feb 19, 2003

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

JewKiller 3000: Nov 28, 2006; by Lowtax

Plorkyeran posted:

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

i don't know c++ but this post is correct wrt c

# ? Mar 25, 2016 05:15

fritz: Jul 26, 2003

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

fritz: Jul 26, 2003

Progressive JPEG posted:

std::null_ptr is the most obtuse and pedantic poo poo

everybody still using c++ knows wtf NULL means and it aint gonna change

we use nullptr all thru our code base and I like it

# ? Mar 25, 2016 05:23

fritz: Jul 26, 2003

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

yippee cahier: Mar 28, 2005

one sentence answer please why do people think NULL is a travesty?

# ? Mar 25, 2016 05:56

AWWNAW: Dec 30, 2008

it's bad

# ? Mar 25, 2016 06:00

Arcsech: Aug 5, 2008

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

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

Notorious QIG posted:

in c++ at least, the following code behaves very differently if you substitute 0 for NULL:
code:
uint8_t* x = NULL;
x++;
std::cout << *x;
if x is NULL, this segfaults because you can't increment past NULL. if x is 0, this will print the contents of the memory located at 0x8, which under certain compilers is a-ok

thats not true at all.

null is 0.

# ? Mar 25, 2016 07:03

fart simpson: Jul 2, 2005; DEATH TO AMERICA

its ok, just prefix literally every statement with if x is not null

# ? Mar 25, 2016 07:05

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

Progressive JPEG posted:

std::null_ptr is the most obtuse and pedantic poo poo

everybody still using c++ knows wtf NULL means and it aint gonna change

its useful in case you have something like this:

code:

int foo(int x) {
  // do a dumb thing
}

int foo(int *x) {
  // do another dumb thing
}

foo(0); // what gets called?

# ? Mar 25, 2016 07:06

BattleMaster: Aug 14, 2000

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

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

BattleMaster posted:

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

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

BattleMaster: Aug 14, 2000

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

Soricidus: Oct 21, 2010; freedom-hating statist shill

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

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

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

BattleMaster: Aug 14, 2000

Soricidus posted:

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.

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

gonadic io: Feb 16, 2011; >>=

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

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)

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

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

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

BattleMaster: Aug 14, 2000

Wheany 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*"

# ? Mar 25, 2016 12:56

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

BattleMaster posted:

maybe i just use C too much because i don't see what's wrong with null being 0

like maybe think about checking your pointers before you use them instead of using them and then checking the results, or not even checking and just hoping/praying it works

edit: like I don't even know what you're doing adding an integer to something that can be null anyway in a higher level language

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:


// find an integer in a list and return it
// the function signature does not indicate that
// there may not be a valid result!
// also, please note that Integer is the reference 
// type version of int
def find(list: List[Integer], value: Integer): Integer = {
  return null
}

def findOp(list: List[Integer], value: Integer ): Option[Integer] = {
  return None // none is a subtype of Option that indicates the lack of data
}

val l = List(1,2,3)

val resNull = find(l, 1)
val resOp =findOp(l,1)

resNull.byteValue() // this causes a runtime error

resOp.byteValue() // this causes a compile time error

//normal usage with null
if(resNull == null)
  println("null")
else
  println(resNull.byteValue())

//normal usage with option
// (i: Integer)=> doStuff(i) is a lambda, a function with no name 
// map is a function that takes a function that modifies the contents of the option

val transformedOp: Option[String] = resOp.map((i: Integer) => i.byteValue().toString())
println(transformedOp.getOrElse("null")) // if transformedOp is None, and it is since resOp is,  getOrElse() returns the input string "null", otherwise it returns the value inside the Option.

# ? Mar 25, 2016 12:58

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

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

BattleMaster: Aug 14, 2000

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

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

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

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

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

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

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

BattleMaster: Aug 14, 2000

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

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

compilers won't even warn you if you forget to check though

# ? Mar 25, 2016 14:09

suffix: Jul 27, 2013; Wheeee!

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

BattleMaster: Aug 14, 2000

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

oh no blimp issue: Feb 23, 2011

never return anything and just make everything happen through side effects

# ? Mar 25, 2016 14:19

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

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

BattleMaster: Aug 14, 2000

okay that's fair

# ? Mar 25, 2016 14:30

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

BattleMaster posted:

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

are you saying that your code has never had a nullpointerexception?

# ? Mar 25, 2016 14:30

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 02:54

BattleMaster: Aug 14, 2000

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »