freenode/#clasp - IRC Chatlog
Search
2:32:28
Bike
makecontext might be a good thing to do except all those functions were removed from posix how super
2:48:37
drmeister
I read that there were several functions removed a few years ago that emacs needed. I thought it might have been at that point.
7:34:46
frgo
Bike: The Cray T90 seems to natively support FPEs as traps ;-) https://users.757.org/~ethan/comp_cray/MANPAGES/2080_10.0/04_pgs_174-409.pdf
7:41:11
frgo
Bike: Not exactly knowing what you now want to achieve, but I also found this: https://linuxgazette.net/issue40/trap.txt
8:00:43
beach
I have a C++ question related to a discussion about different strategies for passing arguments. If you have the syntax type fun (type &argument) {argument++;}, does that mean that if you do fun(x), then x will have its value incremented? And, with that syntax, are there any restrictions on the kind of arguments you can have, i.e., can you have fun(x + 2)?
8:04:19
heisig
beach: If I recall correctly, C++ references are just syntactic sugar for pointers. So argument++ translates to (*argument)++.
8:05:30
heisig
So x in your example will have its value incremented, and there are no restrictions on using references as arguments or return values.
8:07:08
d4ryus
it would not compile: invalid initialization of non-const reference of type ‘int&’ from an rvalue of type ‘int’
8:17:34
beach
So call-by-value and call-by-reference are not opposite strategies, but they also can't coexist. Call-by-value must accept any r-value so it is mandatory that the resulting value be passed by sticking it in a location belonging to the callee. And no side effects on that location can be visible in the caller. Call-by-reference passes a reference to a location, which restricts the possible arguments to being l-values.
8:22:09
beach
Interestingly, early versions of Fortran (which used call-by-reference uniformly) allowed a call such as fun(10), and if fun were defined to increment its parameter, then 10 would be 11 after the call.