What disturbs me is the need to Init() everything. In the Vec type (the only one I've analyzed, actually) all it does is to fill everything with zeros and add a "magic" field certifying that the initialization happened. So why don't simply fill everything with zeros, which can be achieved with ={} if you're super modern or ={0} if you're not, and then drop the check for the magic field? Of course that wouldn't detect a missing intialization, but neither is it detected for any standard type.
Yet Another TypeSafe and Generic Programming Candidate for C
31–37 of 37 posts
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#32What disturbs me is the need to Init() everything. In the Vec type (the only one I've analyzed, actually) all it does is to fill everything with zeros and add a "magic" field certifying that the initialization happened. So why don't simply fill everything with zeros, which can be achieved with ={} if you're super modern or ={0} if you're not, and then drop the check for the magic field? Of course that wouldn't detect…
It is a bit crazy but forcing this kinda makes a habit. That way, a habitual user will tend to initialize other variable types as well.
That's why I call it a standard, because the library has its own coding style. Take the ownership semantics explained in concepts section of README for example. I provide a way to very clearly specify ownership.
Also the init() instantly detects bugs related to uninitialized struts. When they do happen, sometimes very deep in the code they take a lot of time.
This is also one of the reasons why there are so many ValidateX checks in implementation code. Try to catch bugs faster.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#33Earlier 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…
How would you implement 'var = ...' while respecting that 'VecAt(...)' could return 0?
I am currently working on a similar problem and can't seem do seem figure out how to handle these for-loops and setting the iterator properly.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#34Earlier quoted context omitted.
Wow! Thanks for pointing that out, so misleading…
yep, glad you pointed that out. To explain a bit more : MisraStdC is 3 parts : Misra + Std + C - Misra is derived from my name. That's why I needed to specify that the repo is not related to the MISRA standard.
Thanks for the clarification but it makes zero sense
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#35Earlier quoted context omitted.
> 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…
How would you implement 'var = ...' while respecting that 'VecAt(...)' could return 0? I am currently working on a similar problem and can't seem do seem figure out how to handle these for-loops and setting the iterator properly.
The ",1" ignores var and keeps 1.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#36Earlier quoted context omitted.
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.
While I do think there might be some squatting here, I have to defend that dropping the h is also a common spelling of that name.
Re: Yet Another TypeSafe and Generic Programming Candidate for C
#37Earlier 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…
I just tested this, and it works flawlessly! This is amazing! Thanks for the suggestion.