[MrPickles]

Originally Posted by fysiks I know that. If you forget to include the 100 in the input array then you'll go out of bounds though. My point is that you're relying on having to remember that you have to pass a 100 in the input array. It obfuscates the purpose of the input variable (e.g. the variables intent is to contain X's but you require it to include Y). Also, if you ever need to make that number some other value, it requires you to remember to update it in every location which makes it non-scalable. At this point, I'm not really worried about the its core functionality and more giving suggestions for robustness and scalability. Regardless, you're free to ignore my suggestions and do it however you'd like. You've got the most important part worked out by using a function with a loop in it. I also just noticed that you should validate that the values ("__int_Entitys[i]") in the array are less than "sizeof __int_TransEnts[]". But again, you're welcome to omit many of these types of checks if you're the only one that will ever use the function and you'll guarantee that the values will never exceed the appropriate limits.

mm I think that adding the 100 is a little more efficient than obtaining the size of the array each time the function is used, literally, it is placing the numbers in the array that you need plus the 100, it is not very stressful

"I also just noticed that you should validate that the values ("__int_Entitys[i]") in the array are less than "sizeof __int_TransEnts[]"."

as I said with < 100 it is more than enough, because at that moment it does not continue checking

[fysiks]

Originally Posted by MrPickles mm I think that adding the 100 is a little more efficient than obtaining the size of the array each time the function is used, literally, it is placing the numbers in the array that you need plus the 100, it is not very stressful

It does not "obtain the size of the array" every time the function is called because it is determined at compile time (sizeof is a preprocessor directive/function). I.e. it is the same as hard coding the size of the array as the second argument. It does add a variable in the function but it won't change the efficiency in any appreciable way.

Also, I wasn't making the suggestion to make it negligibly more efficient (it won't make any difference for the server). I made the suggestion for the reason that I explained: robustness and scalability of the function.

But, like I said, if you're not publishing this function as a reusable function for others, you can ignore good advice and do whatever you want.

Originally Posted by MrPickles "I also just noticed that you should validate that the values ("__int_Entitys[i]") in the array are less than "sizeof __int_TransEnts[]"." as I said with < 100 it is more than enough, because at that moment it does not continue checking

I know how your code works. This part of my post was predicated on implementing the function more robustly as stated in the beginning of the post.

[MrPickles]

Originally Posted by fysiks It does not "obtain the size of the array" every time the function is called because it is determined at compile time (sizeof is a preprocessor directive/function). I.e. it is the same as hard coding the size of the array as the second argument. It does add a variable in the function but it won't change the efficiency in any appreciable way. Also, I wasn't making the suggestion to make it negligibly more efficient (it won't make any difference for the server). I made the suggestion for the reason that I explained: robustness and scalability of the function. But, like I said, if you're not publishing this function as a reusable function for others, you can ignore good advice and do whatever you want. I know how your code works. This part of my post was predicated on implementing the function more robustly as stated in the beginning of the post.

you are wrong, because every time you call the function, you will get the size of the array, because or can be

__int_Array1 = {2,3,100} // max 3
__int_Array2 = {2,4,6,2,100} // max 5

The compiler does not determine the maximum size of the array in the function, since something will change over time, the array and the size of the array is obtained when the function is called, because as I said, the size of the array will change all the time.

removeTransEnts( Client, __int_Array1 );
removeTransEnts( Client, __int_Array2 );

It seems to me less robust and more efficient to add just one more cell

"But, like I said, if you're not publishing this function as a reusable function for others"

I think that if they should use it, it is less elegant, but a little more efficient, and nothing tedious to add a 100 at the end

"It obfuscates the purpose of the input variable (e.g. the variables intent is to contain X's but you require it to include Y). Also, if you ever need to make that number some other value, it requires you to remember to update it in every location which makes it non-scalable."

It is an example that has nothing to do with what I did, the 100 at the end has a clear purpose, which is to identify the end of the loop, and not obtain the size each time the function is called, Here we are not talking about origins or vectors

[Natsheh]

No1 will use your method because its hardcoded and robust, you're just being stubborn and ignorant to listen.

[MrPickles]

Originally Posted by Natsheh No1 will use your method because its hardcoded and robust, you're just being stubborn and ignorant to listen.

God I think we have a fan here, I think it will be the 6th post where you do not understand and remain ignorant

It's very easy, instead of getting the size of the array each time the function is called, it just adds an extra cell to identify when the loop stops, that's all.

I doubt you read all 4 pages and just shot
Do you find it very robust just adding a cell that identifies instead of obtaining the size of the array every time the function is called? xd

[fysiks]

Not really sure why you keep trying to optimize like it's 1980's computers running this stuff.

[MrPickles]

Originally Posted by fysiks Not really sure why you keep trying to optimize like it's 1980's computers running this stuff.

It's not that, I just like it, and if I try to be better to the last drop and more effective to the last drop, I'll do it, I'm a perfectionist and meticulous, it just bothers me that some don't even bother to read and just They shoot without knowing( not u )

[fysiks]

There is always a tradeoff between efficiency and robustness/scalability/modularity, etc. These days, the efficiency reduction to achieve these aforementioned attributes is negligible. Anyways, I suspect you know that. I generally try to get the best advice I can but I guess I'll try to remember that you probably won't take it anyways.

[MrPickles]

Originally Posted by fysiks There is always a tradeoff between efficiency and robustness/scalability/modularity, etc. These days, the efficiency reduction to achieve these aforementioned attributes is negligible. Anyways, I suspect you know that. I generally try to get the best advice I can but I guess I'll try to remember that you probably won't take it anyways.

Giving it one more cell does not affect robustness or solidity in the slightest, nor does it affect modularity, as I said it has a purpose, to be the limit, and as I said, we are not talking about vectors, to obtain the size of the array each time time the function is called if it is less efficient, with conspicuousness

[fysiks]

Originally Posted by MrPickles Giving it one more cell does not affect robustness or solidity in the slightest, nor does it affect modularity, as I said it has a purpose, to be the limit, and as I said, we are not talking about vectors, to obtain the size of the array each time time the function is called if it is less efficient, with conspicuousness

Wow, you just keep going.