Office Hours During exams:
Tue 17th 9-12 Wed 18th 1-3 Fri 20th 11-12:30 (330 final 1-4 bld 355 rm 108) Tue 24th 11-1 Wed 25th 11-12:30 (485 final 1-4 bld 355 rm 108) |
|
Assignment 4 notes and corrections:
(1) In expandOpApplier.cl and the combined script, the test variable (lam) is incorrectly
initialized with '(lambda-closure nil nil nil (L) L), and will cause script errors.
(2) Note that the macro, as specified, can only work on lists of operators that are statically passed to the macro - you can't put the list in a variable and run the macro on the variable. (Either the macro needs to know the list structure at load time, or it needs to expand to code that produces and evaluates the desired list, which isn't the format the specs requested.) Assume the lists will be statically provided. :-) I've got a macro to produce code for the general case, where the expanded code is what in turn produces (and then evaluates) the desired expression (op1 (op2 ... val)), but the actual expanded code is significantly more involved than just the (op1 (op2 ... val)). (I'll post it with the rest of the assign4 solution.) |
| Addenda to constexpr evaluation
It turns out the compiler can, in the interests of "optimization", actually choose to evaluate constexpr's at run time (live and learn)! In those case, it appears to be setting aside the storage for the "constant", calculating it at run time, but treating it as read only after the value is initially set. In that case it appears the only way to be certain whether it is performing the computation at compile time is to break out the compile-to-assembly option - which I won't require folks to do. Since C++14, things have changed further, allowing the use of non-constexpr variables within constexpr functions. It appears that going back to compiling with -std=c++11 gives stricter controls over this, but limits the body of a constexpr function to being strictly a return statement (though nested :? operators can still be embedded within that). |
Edit: The csci485 repository for WoFoo has been posted, but the controller is only partially complete. A list of the anticipated revisions is included at the top of the file (controller.cl). Hopefully most of those will be complete before the end of the study break.