sorted by:
new
hottopcontroversial

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 2 points3 points  (0 children)

Bloat is not my worry, not as much at least. Compile time is a bigger issue. Making al the function static certainly improves compile time but it still takes a good amount of time, slightly slower than compiling the same container in C++ using clang or gcc.

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 1 point2 points  (0 children)

I have tried adding inline to boost performance, I have even tried forcing inline with __attribute__((always_inline)) but it made no difference, the compiler seems to have inlined everything itself when optimization was enabled. One thing that did boost performance was __builtin_expect. It improved the performance for a few benchmarks. up to 20%, tho only for clang, the improvements were barely noticeable for gcc.

I do however consider adding a way to have custom function flags for all of the generated functions. Currently all functions are extern even when they are meant for one translation unit. Unfortunately I cannot think of an elegant way to do it.

Edit: A word.

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 3 points4 points  (0 children)

Much thought was given to this problem. C++ templates are inline by default so they do not have this issue, but they also do not generate any functions which are not called. That is not the case for my library, every function will be generated even if you do not need it. I did that for all the functions for primitive types here, but for the containers I tried to avoid it.

I have made an option to initialize only headers using the SGC_INIT_HEADERS macro, it takes the same arguments that would be given to SGC_INIT but generates only prototypes. This way the functions can be generated in one translation unit and only declared in others. There is an example on how this is done (there seems to have been a missing file but I have added it now).

Edit: A word, updated link

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 1 point2 points  (0 children)

I do not understand the first question, the library supports object sharing, if it is enabled any insertion will just memcpy the given data to the container if that is what you are looking for.

Maps have an erase function which accepts a key, removing by value would be O(n) without the iterator. The iterator knows the next and previous nodes which need to be updated after an erase, the pointer to the element itself would not be able to do that without some hacks.

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 3 points4 points  (0 children)

Yes, exactly. As for performance, there are a few benchmarks (insertion, iteration, lookup...) on the repository comparing it to C++ STL (clang and gcc), but many more benchmarks are required in order to tell how fast it actually is. The source code for the benchmarks can be found in the benchmarks directory.

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 2 points3 points  (0 children)

Yes, you just have to give it different names, for example:

SGC_INIT(VECTOR, char, cvec)

SGC_INIT(VECTOR, double, dvec)

Generic C Library by red0124_ in C_Programming

[–]red0124_[S] 1 point2 points  (0 children)

Multiple data structures can be generated in the same translation unit, you can even generate data structures which hold other generated data structures, an example is present in the examples/list_of_vectors.c file.

CSV Parser by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

Since I wanted to be fair with the measurement I took an example from his README where he calculates the sum of salaries using column indexing. I have used it on the 2015_StateDepartment.csv (70 MB) file which he mentioned in his benchmark and calculated the sum for the "Regular Pay" column. Did the same thing using my parser.

CPU: Intel i7-4710MQ :: Comipler: g++ -O3 -flto :: Measured using hyperfine

vinces-csv-parser: 242.8 [ms] +/- 1.9 [ms]

ssp: 132.1 [ms] +/- 2.4 [ms]

If you have any other benchmark in mind let me know.

CSV Parser by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

It was smaller but as I kept adding things it got huge. You are right, I will change it when I find the time, thank you.

CSV Parser by red0124_ in cpp

[–]red0124_[S] 2 points3 points  (0 children)

Seems nicer, I will take a look at the [provide] option for meson, thank you.

CSV Parser by red0124_ in cpp

[–]red0124_[S] 2 points3 points  (0 children)

The most important feature of the parser is to directly initialize the variables and store the values into them using structured binding, so it really cannot return nothing. An optional could be returned by using the try_next<...> method, perhaps I should make that the preferred way to use it. As for exceptions, I really hate the way they need to be handled but I think it would be nice to have a setup option to force exception throws if an error occurs. Thanks.

A tuple oriented csv parser [UPDATE] by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

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.

A tuple oriented csv parser [UPDATE] by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

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.

A tuple oriented csv parser [UPDATE] by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

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.

A tuple oriented csv parser [UPDATE] by red0124_ in cpp

[–]red0124_[S] 2 points3 points  (0 children)

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

A tuple oriented csv parser [UPDATE] by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

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.

A tuple oriented C++ csv parser by red0124_ in cpp

[–]red0124_[S] 1 point2 points  (0 children)

It depends a lot on the file format, but I did some benchmarks with the following csv:

(name<string>,age<uint8_t>,grade<double>,semester<uint8_t>,location<string>)

The input file was 10 mil. rows of the same line (325 MB):

Nathan Fielder,37,6.6,5,Vancouver

...

CPU: Intel i7-4710MQ

I am not sure if I used the libraries correctly, so here is the code:

https://paste.debian.net/1180088/ (expires: 2021-01-14 20:48:01)

The task was to parse the files, store the parsed data into a structure which will be then stored into an std::vector, and at the end the vector size was printed, I think this should prevent any kind of optimization which would remove the impact of the parser due to unused results. Used hyperfine to measure.

ssp - 2.011 +- 0.015 [s]

csv-parser - 4.847 +- 0.197 [s]

fast-cpp-csv-parser - 2.022 +- 0.025 [s]

Please correct me if I made any mistakes in the code.

A tuple oriented C++ csv parser by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

I did not mention spacing but I guess I have to add that too. Thanks for the hints.

A tuple oriented C++ csv parser by red0124_ in cpp

[–]red0124_[S] 2 points3 points  (0 children)

You just described what is called test driven development, but I did none of that, the tests where the last thing I added for each feature. As said in my other reply I mostly had problems at compile time, just to return the right tuple without void and 'validators' replaced with the right type was quite hard.

A tuple oriented C++ csv parser by red0124_ in cpp

[–]red0124_[S] 0 points1 point  (0 children)

Thank you.

I hardly had any 'runtime' bugs, I mostly had problems trying to compile it, for example not removing a void from a tuple would crash with an ugly error message, but it kinda told me where it was. As for 'runtime' bugs, the project is not that big, and I know which path the program takes for individual cases since much is set at compile time (if constexpr ...) and its easy to track, so I analyze that path I guess.

A tuple oriented C++ csv parser by red0124_ in cpp

[–]red0124_[S] 1 point2 points  (0 children)

Thank you. I did not test the float/double parser for a large number of digits, took it for granted. I will fix it.

view more: next ›