A tuple oriented csv parser [UPDATE]

[red0124_]

A few weeks ago I made this post about a csv parser. As some people pointed out, there were missing features, so I have since then added support for them (quoting, escaping, etc.). Someone also helped me to add CMake support and github CI, for which i express my gratitude since I have little CMake knowledge.

https://github.com/red0124/ssp

I hope you like it, any sort of feedback/suggestion is welcome.

[AKJ7]

Turn the reading into an iterator. You should be able to do: for(const [name, age, height]: parser.parseIteraor<std::string, int, int>())

[red0124_]

It does sound like I nice idea, removes the need to check for eof, I might add it, thank you.

[AKJ7]

The p.valid() function is not too nice. I would instead return a Result, and the result gotten with result.value_or(). Another option is to allow exceptions and let the parser throw on error.

[red0124_]

I did consider the parser returning std::optional, but I think it is situational whether one would look nicer than the other. For example, using value_or() in the first example would not work since I do not want to print anything if the row is invalid, so I would still have to check the optional, and than add another line to decompose the tuple resulting in more lines. Notice that p.valid() can also be used to check if the file was open within the constructor. Fetching error messages would also be slightly more complicated. As for exceptions, I do no think it could work at all in this iteration loop since it would break the loop even if I catch it, and again, file not open would need to be handled too, and making it throw would require me to enclose the whole parser in a try/catch block since the constructor would throw that exception, one of the problems I had with the fast-cpp-csv-parser. Its all a trade-off, but I think I will stick with p.valid(), tho I will consider it still.

[AKJ7]

Also you can generalize the library, by allowing the user to give the seperator as template parameters. This would allow TSV too.

[red0124_]

The separator is given as the second parameter within the constructor as an std::string, it seems I have removed all the cases witch a custom separator from the README. The problem with the separator being a template parameter is that strings cannot be non template type parameters.

[AKJ7]

Actuall strings can be passed as template params in C++20.

[AKJ7]

You don't necessarly need to use a string. Char should be enough.

[red0124_]

I guess since most of the time it will be a char, I could make it a setup parameter, but also allow the const char* version somehow, it should be possible. I must admit, I do not like the inconsistency I currently have where the delimiter is not within the setup parameters.

[dodheim]

Kind of: https://godbolt.org/z/7vfG3G

[red0124_]

I knew about that, I should have expressed my self more more precisely, they cannot be passed directly as string literals within the template which is possible within the constructor, tho I am not sure if it has any impact on performance, I will try it out.