11–20 of 67 posts
I know it's mentioned specially in the article but the C programmer in me immediately wants to use structs. They don't need to be complex or long lived or even initialized. And as a bonus there's no heap involved anywhere. Either that or just bail out of c++ and use go.
std::tuple is essentially an "anonymous" struct -- there's no allocation involved
I know it's mentioned specially in the article but the C programmer in me immediately wants to use structs. They don't need to be complex or long lived or even initialized. And as a bonus there's no heap involved anywhere. Either that or just bail out of c++ and use go.
std::tuple is essentially an "anonymous" struct -- there's no allocation involved
I know it's mentioned specially in the article but the C programmer in me immediately wants to use structs. They don't need to be complex or long lived or even initialized. And as a bonus there's no heap involved anywhere. Either that or just bail out of c++ and use go.
std::tuple is essentially an "anonymous" struct -- there's no allocation involved
I am a bit surprised exceptions were not mentioned in the context of returning an error value.
Author mentions Common Lisp's multiple values, and one of the main feature of multiple values is that they are optional: the caller does not need to use secondary values. Even though floor returns 2 values, the following is a valid expression:
(+ (floor x) 2)
The getline case (boolean and possible value) really wants a type like Haskell's "Maybe" or Rust's Option: a type that either contains nothing or a value.
Unfortunately the currently available solution (boost::optional) performs enough worse that the difference can be measured in a simple implementation of "wc -l". Consider the following code: #include #include #include using namespace std; using namespace boost; optional getline_(istream &st) { std::string line; if(getline(st, line)) return line; return none; } int main() { int lines = 0; while(getline_(cin)) lines++;…
The getline case (boolean and possible value) really wants a type like Haskell's "Maybe" or Rust's Option: a type that either contains nothing or a value.
The std::unordered_map::insert example in the article is an excellent example of an interface with multiple return values: it returns a pair (iterator, bool) of an iterator to the given key and a bool indicating if the iterator is to a newly inserted key-value pair or if it was the key-value pair already stored in the map. Neither the iterator nor the bool owns a buffer like in the std::getline example, so the std::getline out parameter design is not needed here.
Instead of markers, I like to use typedefs instead. Here's an example how this would look like in a HPC related program. Basically, if you know Fortran, you know where this is coming from. typedef const double * const __restrict__ IN; typedef double * const __restrict__ OUT; typedef const int INT_VALUE; typedef const double FP_VALUE; void diffuse_c( OUT runtime_total_s, OUT runtime_boundary_s, OUT thermal_energy_upda…
I know it's mentioned specially in the article but the C programmer in me immediately wants to use structs. They don't need to be complex or long lived or even initialized. And as a bonus there's no heap involved anywhere. Either that or just bail out of c++ and use go.
Instead of markers, I like to use typedefs instead. Here's an example how this would look like in a HPC related program. Basically, if you know Fortran, you know where this is coming from. typedef const double * const __restrict__ IN; typedef double * const __restrict__ OUT; typedef const int INT_VALUE; typedef const double FP_VALUE; void diffuse_c( OUT runtime_total_s, OUT runtime_boundary_s, OUT thermal_energy_upda…
I can't be the only one who finds "INT_VALUE" both superfluous and unnecessarily ugly?
Edit: Thinking about it some more, "INT_VALUE" still makes sense - it makes it clear that this specific symbol should be accessed as a value, not as a pointer. Doing this reminds me that I'm (probably) imposing more register pressure by passing by value. In general I'd probably pass a const int * const pointer here, but in this specific case I needed values because of some CUDA specific limitation.