Show HN: Stdcore, a toy container library
nedbingham.com
Show HN: Stdcore, a toy container library
1–9 of 9 posts
Re: Show HN: Stdcore, a toy container library
#2Range-v3 (https://github.com/ericniebler/range-v3) exists solving the same problem, and there's a standardization proposal (http://en.cppreference.com/w/cpp/experimental/ranges).
Re: Show HN: Stdcore, a toy container library
#3What’s the difference between an abstract class and a Java-style interface in a language that allows multiple inheritance? I’ve generally thought of interfaces as a way to get some of the features of multiple inheritance while preventing the parts of multiple inheritance that cause issues (e.g. the diamond problem). However, these days, every language I know of that has single inheritance+interfaces allows interfaces (or traits, in the case of PHP) to specify default implementations of their methods.
Re: Show HN: Stdcore, a toy container library
#4What’s the difference between an abstract class and a Java-style interface in a language that allows multiple inheritance? I’ve generally thought of interfaces as a way to get some of the features of multiple inheritance while preventing the parts of multiple inheritance that cause issues (e.g. the diamond problem). However, these days, every language I know of that has single inheritance+interfaces allows interfaces…
Inheritance as implemented by Go provides for a different school of thought from C++. In C++, you define the taxonomy, then define the objects in relation to that taxonomy. In Go its the opposite, defining taxonomy in relation to the objects.
In concrete terms for C++, this means that abstract base classes Must be defined before the objects are defined. So if I wanted to use a library, I would be entirely restricted to whatever abstract base classes they define.
For Go, I could use a library and then define whatever interfaces I needed specifically for the functions I want to implement. Its effectively a much more structured and rigorous architecture for templated code.
At least this is my understanding. I've explored Go just enough to get some of the higher level concepts but I haven't quite dug into it yet. So correct me if I'm wrong.
Re: Show HN: Stdcore, a toy container library
#5Range-v3 ( https://github.com/ericniebler/range-v3 ) exists solving the same problem, and there's a standardization proposal ( http://en.cppreference.com/w/cpp/experimental/ranges ).
Range-v3 seems to be solving a different problem. It seems to be introducing support for Pythonesque features like type-checking and list-comprehension. However, the algorithms that are documented still use first/last iterators (http://en.cppreference.com/w/cpp/experimental/ranges/algorit...). There seems to be a set of basic range class definitions and there seems to be a View class, but I'm not sure if they interact to provide the same type of generic slice definition that I've developed here.
Perhaps I am missing something though, could you expand a little on the specific part of Range-v3 that you are thinking of?
Re: Show HN: Stdcore, a toy container library
#6Range-v3 ( https://github.com/ericniebler/range-v3 ) exists solving the same problem, and there's a standardization proposal ( http://en.cppreference.com/w/cpp/experimental/ranges ).
Range-v3 seems to be solving a different problem. It seems to be introducing support for Pythonesque features like type-checking and list-comprehension. However, the algorithms that are documented still use first/last iterators ( http://en.cppreference.com/w/cpp/experimental/ranges/algorit... ). There seems to be a set of basic range class definitions and there seems to be a View class, but I'm not sure if they inter…
No, the primary purpose of range-v3 is to work with ranges (a container, a pair of iterators, or a view) instead of iterators. Lazy and pipeable (i.e. chainable) views are built on top of this.
Check the first link rather than the cppreference documentation.
By the way, type-checking isn't Pythonesque. Haskellesque perhaps.
Re: Show HN: Stdcore, a toy container library
#7Why would you not just use lexicographical_compare() to implement your operator<() for containers?
Re: Show HN: Stdcore, a toy container library
#8What’s the difference between an abstract class and a Java-style interface in a language that allows multiple inheritance? I’ve generally thought of interfaces as a way to get some of the features of multiple inheritance while preventing the parts of multiple inheritance that cause issues (e.g. the diamond problem). However, these days, every language I know of that has single inheritance+interfaces allows interfaces…
Inheritance as implemented by Go provides for a different school of thought from C++. In C++, you define the taxonomy, then define the objects in relation to that taxonomy. In Go its the opposite, defining taxonomy in relation to the objects. In concrete terms for C++, this means that abstract base classes Must be defined before the objects are defined. So if I wanted to use a library, I would be entirely restricted…
You should take a look at the Concepts TS - if I understand what you're trying to achieve correctly then Concepts are the approach C++ is taking to address these types of issues.
Re: Show HN: Stdcore, a toy container library
#9@OP: I'm curious about your motivation to post here. Are you looking for feedback? Getting people to try it out? Use it? I found it interesting to read (you had me at "trainwreck"), but you also posted a lot of warning signs: Toy, not production ready, proof of concept. Without going into detail why that is. Are you using it? Have you found any drawbacks? Why is it a toy library instead of a library?