Why do people do such wired projects? Why not just using C++ instead of pure C?
It also compilers way faster than C++ code if that interests you :-)
Yet Another TypeSafe and Generic Programming Candidate for C
21–30 of 37 posts
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#22Why do people do such wired projects? Why not just using C++ instead of pure C?
Because I just don't like it as much and I wanted to see how much farther can we go by just using macro tricks.
Ok, it's fine, if you just wanted to experiment with macros. This seems to be a legit reason to use pure C.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#23Why do people do such wired projects? Why not just using C++ instead of pure C?
It also compilers way faster than C++ code if that interests you :-)
I agree, C++ code compilation is generally slower compared to C. But the compiler itself isn't particularity slower (under the hood it's the same compiler), but compiling C++ code with a lot of templates is slow.
For me personally compilation slowdown is just a price, which I am ready to pay for more language features, including better abstractions and type safety.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#24Re: Yet Another TypeSafe and Generic Programming Candidate for C
#25Why do people do such wired projects? Why not just using C++ instead of pure C?
Maybe because one is working on a legacy C program, and for various reasons adding C++ to said program is too risky or expensive?
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#26>Disclaimer: This library is not related to the MISRA C standard or guidelines. The name "MisraStdC" comes from the author's name, Siddharth Mishra, who is commonly known as "Misra" among friends. Why include the letters Std then? This seems like a purposeful typo-squatting effort and definitely makes me suspicious.
because it's my personal standard. I use it more than I use standard C utils.
Did you really take the name mishra and make it into misra.h then call your library MisraStdC and expect people to believe the confusion isn't intentional? This whole thing feels incredibly dishonest.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#27Earlier quoted context omitted.
because it's my personal standard. I use it more than I use standard C utils.
Did you really take the name mishra and make it into misra.h then call your library MisraStdC and expect people to believe the confusion isn't intentional? This whole thing feels incredibly dishonest.
Ok I'm saying this for the last time so I'll over-explain so everyone can follow the idea properly.
Not all people can pronounce names correctly. In a language some names are easier to pronounce if you take away a few letters. Some may find using Sid as short form for Siddharth, because it's just easier.
Now from my childhood, some friends used to pronounce my name differently. I noticed that they don't use the 'h' in Mishra, so I started using 'Misra' instead. They found it easier to pronounce and I felt connected more. Those who could pronounce it correctly, still used Misra because it's just easier and sounds more personal. Friends and loved ones do that. It's also sometimes called as a nickname, where you give other names to a loved one.
Now, it also just happens that my native language has the same root word for Misra and Mishra aaaand they mean the same! It essentially means a mixture of different things.
Now even if all this this reason does not sound good to you, just ignore it. It is my project, my name. I can pronounce however I want, with whatever spelling I want. A project is named by it's maintainer. I can name it exactly MISRA and still be happy with it because it's my project, I'm the maintainer.
I did mention that this is not related to the MISRA standard because I felt like users should know and not confuse it with my library.
I tried to ignore this matter but people over internet just keep poking you saying you're dishonest. Please don't bother yourself with the name of things, just use it if you need it otherwise ignore it. It's an advice for life. Name of things does not matter, it's what they do and achieve. I've put honest work into this library and I won't accept someone sitting behind a screen just say that I'm dishonest, I'm purposefully choosing this name. It is my name, I chose it, names clash in this world at least. Two entities can have same name but of different origin and use case.
Thanks for reading this if you read it till here.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#28Earlier quoted context omitted.
Did you really take the name mishra and make it into misra.h then call your library MisraStdC and expect people to believe the confusion isn't intentional? This whole thing feels incredibly dishonest.
Ok I'm saying this for the last time so I'll over-explain so everyone can follow the idea properly. Not all people can pronounce names correctly. In a language some names are easier to pronounce if you take away a few letters. Some may find using Sid as short form for Siddharth, because it's just easier. Now from my childhood, some friends used to pronounce my name differently. I noticed that they don't use the 'h' i…
I tried to ignore this matter but people over internet just keep poking
Did you really think naming something MisraStdC, then posting it to the internet, then rationalizing it wouldn't be noticed?
It's not even your name or a standard.
It really looks like you are trying to name it something that people would find from searches then somehow walk it back and come with a story after.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#29> A modern C11 library I'd say "mostly C11": it uses __VA_OPT__ that's been standardized only in C23. The "foreach" macros need a lot of refinement: passing the body in the parameters is asking for troubles, for example. And using a non-unique default name for the index prevents nested loops. To overcome the issues with generic and qualified types, have you considered using typeof_unqual? _Generic(*(typeof_unqual(x)*…
Yea the FMT trick uses VA_OPT. I consider myself a noob with C official specification, so you're probably right about that. I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool. This is the first time I came across typeof_unqual. I'll look into it, thanks . I spent a lot of time making this work across all…
> I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool.
Yes but the body in the parameters really is a show stopper. What if the body has a unprotected comma? Like
VecForeach(&v, e, {
int x, y;
...
});
#define VecForeachIdx(v, var, idx)\
for (size idx=0,_d=1; ValidateVec(v),_d; _d--)\
for (VEC_DATATYPE(v) var={}; idxlength && (var=VecAt(v,idx),1); idx++)
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#30Earlier quoted context omitted.
Yea the FMT trick uses VA_OPT. I consider myself a noob with C official specification, so you're probably right about that. I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool. This is the first time I came across typeof_unqual. I'll look into it, thanks . I spent a lot of time making this work across all…
> I do kinda like how foreach is implemented right now. This allows me to perform some strict checking for easy loop iteration based bugs and also it kinda looks cool. Yes but the body in the parameters really is a show stopper. What if the body has a unprotected comma? Like VecForeach(&v, e, { int x, y; ... }); Better to expand the macro into one or two "for" and let the body follow. For example: #define VecForeachI…
That sounds like a better idea. I'll test it. Debugging with my existing macros is a PITA, but if your suggestion works then it'll work well with debuggers as well!
Thanks :)