3 ms·
happy to admit my c++ experience is very, very old. I totally understand that things have changed. But even back in the day, libraries could do stuff that hid '
by jfoutz 8y ago
happy to admit my c++ experience is very, very old. I totally understand that things have changed. But even back in the day, libraries could do stuff that hid 'new' from me. Heck, java libs will call 'new' all the time. the same goes for c/malloc
I can cope with accepting a library that does god knows what. but my code, i can see stack/heap split. perhaps it's a security blanket. perhaps it's pointless.
this insight is actually really helpful. in some cases i care, in some cases i turn a blind eye. maybe writing good go means i turn a blind eye all the time. unless i need to inspect the escapes - which go provides good tools for. _chin scratch_
Thanks.
- masklinn 8y ago> happy to admit my c++ experience is very, very old. I totally understand that things have changed. But even back in the day, libraries could do stuff that hid 'new' from me. Heck, java libs will call 'new' all the time. the same goes for c/malloc Yeah, Java necessarily `news` stuff, I believe it's the only way to instantiate classes (ignoring factories).
- jfoutz 8y agoEven factories. Java puts everything on the heap. There's no on the stack object. Java and go are both pass by value. Java makes it easy, because i know everything is a pointer to a thing. I (unreasonably?) freak out about go because i don't understand when an array backing a slice change. I'm just chalking it up to me being old and dumb. Seems hard to track, but tons of people do it, so the issue must be me.
- Skinney 8y agoJava does do escape analysis to allocate certain things on the stack.
- masklinn 8y ago> Even factories. I meant "ignoring factories" in the sense of "practically you don't new to get an instance out of a factory, but ultimately it does that internally so let's just ignore this as it's just nit-picking". > I (unreasonably?) freak out about go because i don't understand when an array backing a slice change. That seems like the simplest one ever: a slice is a super shitty version of an ArrayList[0], so the slice is modified on assignment (direct or via the slice), and can be replaced implicitly on reallocation. Same as the elementData member of an ArrayList. [0] because the backing buffer can trivially be shared between slices, which is not the case for ArrayList
- pjmlp 8y agoSure there is for primitive types, for objects the compiler gets to decide what lands on the stack given escape analysis, until Project Panama finally gets integrated. Additionally both IBM and Azul JVMs do have extensions for stack allocations.
- MrBuddyCasino 8y agoExactly. Also unlike C++, allocation is nearly free on the JVM, and garbage collection is cheap for short-lived ones.
- pjmlp 8y agoCalling new on C++ does not mean you allocate on the heap, rather that the heap might be used. Placement new, global new handler and allocators change that behavior. Additionally, following the footsteps of heap heavy languages, C++ optimizers also do escape analysis and even without overriding new's default behavior, the stack might be used instead if the types are proven not to escape scope.