4 ms·
The proper solution would be taking parameters that can't be invalid; it pushes validity check to the call site.
by TheMonarchist 5y ago
The proper solution would be taking parameters that can't be invalid; it pushes validity check to the call site.
- Koshkin 5y agoIn general, an invalid parameter value is not the only possible problem.
- nesarkvechnep 5y agoI agree. I know how it can be done in languages with sound type system but have no idea about C++.
- pjmlp 5y agoYou can do it in C++ as well [0][1], but type driven development doesn't go well with the C subculture of micro-optimizations. So if you do it on a C++ project, you will get strange looks from the team, so one just shrugs and codes the same way as always. [0] - https://www.youtube.com/watch?v=IaHirnQrL14 https://www.youtube.com/watch?v=IaHirnQrL14 [1] - https://dannypsnl.github.io/blog/2017/12/23/cs/type-driven-development-in-cpp/ https://dannypsnl.github.io/blog/2017/12/23/cs/type-driven-d...
- tsimionescu 5y agoGiven how long and convoluted C++ template programs are, and how horrible the error messages are, I would be very curious if writing your validations in them would actually produce any additional correctness in a realistic code base (I am afraid it would add more bugs in the template logic than it would prevent). Maybe the situation has gotten better since constexpr was introduced, though. Not to mention, this still only works for very simple constraints; if you want to validate complex properties, doing it with types becomes almost a research problem (even something like 'this array must be sorted' encoded fully in types is going to add a lot to your program's length). Finally, the whole rich type culture is, like you point out, missing in C++. So, even if the whole team is on board with it, you will have to work with libraries that don't prove such complex properties about the types of values they produce, putting the entire burden on your own program - either roll your own libraries or as lots of complex-type-annotated wrappers.
- TheMonarchist 5y ago> Maybe the situation has gotten better since constexpr was introduced, though. Since C++11? Yes. > even something like 'this array must be sorted' encoded fully in types is going to add a lot to your program's length template< class Cmp, class Array> class Sorted;// The type of your parameter. I think this could be implemented even in C++03.
- tsimionescu 5y agotemplate< class Cmp, class Array> class Sorted;// The type of your parameter. That type achieves nothing. std::sort doesn't return an instance of Sorted, and nothing prevents me from populating an instance of Sorted with an array that is not, in fact, sorted. So, in my opinion the following two pieces of code are perfectly equivalent: void binary_search(const vector<int> sorted_arr); void binary_search(const Sorted<Cmp,vector<int>> arr); Considering these as functions in a program that otherwise uses the mainstream C++ library ecosystem, they are equally likely to be called with an unsorted array. In Idris or probably even in C++ with significant effort, you could create a type that can't represent an unsorted array, but that is, again, an almost research-level endeavour (and adding more complex constraints it will quickly evolve).
- TheMonarchist 5y ago> That type achieves nothing. The idea of taking params that can't be invalid is that validity is enforced by class invariant. > std::sort doesn't return an instance of Sorted It can't, because it sorts in place and therefore has no control over the sequence. Sorted constructor would sort to guarantee success.