30.04.2013, 10:19
Don't get me wrong, I didn't mean anything bad and what to use is entirely up to the one designing their code.
However my personal opinion always is that people need to know what their code does and how exactly it is done unless using convenient functions isn't going to slow your code down.
Of course I understand that, given the speeds of modern day processors and clever compiler optimizations in C++, talking about performance cost in a situation where there need to be maximally ~50 string comparisons is somewhat stupid, but personally I wouldn't dismiss such "cost" unless working with a larger team where everyone needs to grasp what's written on the fly.
The reason I objected towards the usage of SELECT * is that with larger sets of information, not every piece of data is required in every situation. Once again something extremely trivial and perhaps not going to give a noticeable gain in speed, but if your table has 30 fields and you only need to use 20 of them, retrieve only these 20. I'd say it is just good practice and has another upside to it - you'll know the field "indexes" to use in cache_get_row (or cache_get_row_int, cache_get_row_float).
I mention the function only briefly in my tutorial though. Not because I don't like the function itself, but because my examples aren't really based on that.
Edit: I think there may be a problem with your code, where cache_get_field_content is supposed to fill an enum member! If this function has a parameter calling sizeof() on the enumeration member, it is going to return the actual size of the enum, not the size of the member!
This is close to the situation that the thread author has addressed by using 24 as the last parameter. But it isn't exactly necessary in his case as it is not a member of an enum. Also, should the string sizes change and the array be made larger, every cache_get_row call will need to be modified. sizeof is useful here to avoid that!
However my personal opinion always is that people need to know what their code does and how exactly it is done unless using convenient functions isn't going to slow your code down.
Of course I understand that, given the speeds of modern day processors and clever compiler optimizations in C++, talking about performance cost in a situation where there need to be maximally ~50 string comparisons is somewhat stupid, but personally I wouldn't dismiss such "cost" unless working with a larger team where everyone needs to grasp what's written on the fly.
The reason I objected towards the usage of SELECT * is that with larger sets of information, not every piece of data is required in every situation. Once again something extremely trivial and perhaps not going to give a noticeable gain in speed, but if your table has 30 fields and you only need to use 20 of them, retrieve only these 20. I'd say it is just good practice and has another upside to it - you'll know the field "indexes" to use in cache_get_row (or cache_get_row_int, cache_get_row_float).
I mention the function only briefly in my tutorial though. Not because I don't like the function itself, but because my examples aren't really based on that.
Edit: I think there may be a problem with your code, where cache_get_field_content is supposed to fill an enum member! If this function has a parameter calling sizeof() on the enumeration member, it is going to return the actual size of the enum, not the size of the member!
This is close to the situation that the thread author has addressed by using 24 as the last parameter. But it isn't exactly necessary in his case as it is not a member of an enum. Also, should the string sizes change and the array be made larger, every cache_get_row call will need to be modified. sizeof is useful here to avoid that!