|
Calin Negru wrote: ***PointerInd2 = 31; // just a guess
Yes, nothing wrong with that. I don't see why you see it as deceiving. If you miss one of the indirection operators and you write:
**PointerInd2 = 31; compiler will flag it with an error like "cannot assign 'int' to 'int*' ".
But, again, cases where you need more than two level on indirection are exceedingly rare. Probably because we humans aren't great at keeping track of stack levels.
Mircea
|
|
|
|
|
>I don’t see why you see it as deceiving
It’s just a single &sign one that could make you believe it’s a typical pointer you’re dealing with. You need to be in a high alert so to speak and always have in mind what you have declared.
modified 14-Sep-23 16:05pm.
|
|
|
|
|
Calin Negru wrote: you believe it’s a typical pointer you’re dealing with.
The developer should of course be aware of the code they are writing/modifying.
And this should not be something that is used very often.
|
|
|
|
|
>The developer should of course be aware
I know. If you look at the address assignation alone you don’t have a clue what that is (Something = &SomethingElse) you have look at the declaration to figure it out. Sorry if that sounds like repeating the same thing. What I’m saying is that it’s not your C# fire and forget.
modified 15-Sep-23 3:36am.
|
|
|
|
|
Correct, I think. A simple test program would confirm that, but I'm not feeling the urge.
But if you need more than two or three levels of indirection, then the problem space should lead to sensible variable naming. That and intelligent comments should make your intent clear. And, of course, you've got typedefs or C++ using statements to help reduce the brain cramp that I find multiple indirection sometimes brings. If you're using C++, you also have references which might help reduce the (apparent) levels of indirection going on.
Keep Calm and Carry On
|
|
|
|
|
int Strawberry = 10;
int * PointerInd0 = &Strawberry;
std::cout << "*PointerInd0: " << *PointerInd0 << std::endl;
int ** PointerInd1 = &PointerInd0;
std::cout << "**PointerInd1: " << **PointerInd1 << std::endl;
int *** PointerInd2 = &PointerInd1;
std::cout << "***PointerInd2: " << ***PointerInd2 << std::endl;
int **** PointerInd3 = &PointerInd2;
std::cout << "****PointerInd3: " << ****PointerInd3 << std::endl;
Results:
*PointerInd0: 10
**PointerInd1: 10
***PointerInd2: 10
****PointerInd3: 10
And so until the compiler or the application gives up. If you are really interested then get an assembly listing and see what the machine code is doing.
|
|
|
|
|
Thank you Richard, you make it clear.
modified 14-Sep-23 16:02pm.
|
|
|
|
|
You're welcome. It always helps to look at actual code.
|
|
|
|
|
I have changed my mind about what I want to ask. I’m not interested in groups anymore.
How do you solve units colliding at all? If it’s just two units is it about where the two units have been ( last visited node ) and where they are traveling towards?
Also what if a unit collides with more than one unit in a short amount of time?
|
|
|
|
|
Hi,
It sounds like you just need a push in the right direction. Have a look at the Flow Field family of algorithms.
Flow field algorithm
Did you have a C++ related question to ask?
|
|
|
|
|
|
Randor wrote:
It sounds like you just need a push in the right direction.
Heh, I thought the paronomasian response was clever but I doubt anyone noticed. 
|
|
|
|
|
Every move requires distance and direction (target point; angle).
Prior to the actual move, one checks for any units that will be "intersected" by moving to that point. Rectangles have position and size. Rectangles collide when they interest. (Unless rotated, then you need to deal with polygons)
(The actual move is then shortened so you don't "pass through" the target).
The "mover" then is obviously the attacker; the other the defender. If both moving, it was attacking and counter-attaching. The result of a "charge" is a melee or a repulse; followed by a pursuit. There are no "simultaneous" collisions. Any subsquent collisions creates another attacker-defender scenario.
And infantry won't pursue other infantry; they fire them down.
Cavalry will run down (dispersed) infantry.
Cavalry can not be expected to pursue (and catch) other cavalry.
Artillery is unable to "run" without limbering up.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
My guess is there is more than one way to solve the problem. Age of Empires version 1 for instance had some issues when a unit was caught between two other units, a problem Warcraft 3 didn’t have.
|
|
|
|
|
It's all in the "detecting". Collision detection involves enemies AND friendlies. Is the collision a "blocking" situation, or a "merge" in terms of hand to hand.
What you're refering to are "bugs": "trapped" sprites.
Regarding "group collisions": in the some "systems", any party "within a minute", is considered party to the "collision" / conflict; i.e. 100 yds for infantry, 300 yds for cavalry.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Thanks for your comments Gerry
|
|
|
|
|
You're welcome!
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Code Segment (I) :
int dequeue() {
if (isFull(f)){
printf("Queue Underflow! Nothing
to Dequeue");
}
int dqd =f->data;
f = f->next;
return dqd;
}
Code Segment (II) :
int dequeue(){
int val=-1;
struct Node *ptr=f;
if(f==NULL){
printf("Empty\n");
}
else{
f=f->next;
val=ptr->data;
free(ptr);
return val;
}
}
In Code I, DeQueue operation is being carried out directly using front pointer.
In Code II, The same is happening but this time another Node pointer is created to store the front pointer.
So, What's is the Difference in these two methods!
|
|
|
|
|
Well...
The second one releases memory (while the first one does NOT relaase memory).
Moreover, in the first one, the
if (isFull(f)){line looks suspicious.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Sir, first code doesn't actually need to free something as it is not creating a node to perform operation rather doing the same thing using the front pointer directly.
And yes I have wrote a function 'isFull' already
|
|
|
|
|
Quote: first code doesn't actually need to free something as it is not creating a node
Neither the second one is. So the second code wrongly releases memory.
Quote: And yes I have wrote a function 'isFull' already
But you should check for not-empty condition, with is NOT quite the same of is-full, is it?
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
How is that possible sir! Second code is written by a renowned youtuber 'code_with_harry'. Okk, for your better understanding i'm pasting full source code here:
#include <stdio.h>
#include <stdlib.h>
struct Node *f = NULL;
struct Node *r = NULL;
struct Node{
int data;
struct Node *next;
};
void traversal(struct Node *f){
struct Node *ptr=f;
printf("------------\n");
while(ptr!=NULL){
printf("%d ",ptr->data);
ptr=ptr->next;
}
printf("\n------------\n");
}
int isEmpty(struct Node *f){
if (f == NULL){
return 1;
}
return 0;
}
int isFull(struct Node *f){
struct Node *n = (struct Node *)malloc(sizeof(struct Node));
if (n == NULL){
return 1;
}
return 0;
}
struct Node *enqueue(int val){
if (isFull(f)){
printf("Queue Overflow! Can't Enqueue %d\n", val);
return f;
}
else{
struct Node *n = (struct Node *)malloc(sizeof(struct Node));
n->data = val;
n->next = NULL;
if (isEmpty(f)){
f = r = n;
}
r->next = n;
r = n;
return f;
}
}
// int dequeue(){
// if (isFull(f)){
// printf("Queue Underflow! Nothing to Dequeue");
// }
// int dqd = f->data;
// f = f->next;
// return dqd;
// }
int dequeue(){
int val=-1;
struct Node *ptr=f;
if (f==NULL){
printf("Empty\n");
}
else{
f=f->next;
val=ptr->data;
free(ptr);
return val;
}
}
int main(){
enqueue(11);
enqueue(22);
enqueue(33);
enqueue(44);
traversal(f);
dequeue();
dequeue();
traversal(f);
return 0;
}
|
|
|
|
|
ZAID razvi wrote: Second code is written by a renowned youtuber
At least 90% of YouTube coding tutorial videos aren't worth the paper they're printed on.
And how do you know that this Harry is "renowned"? Is this something that other well-known, competent, and respected developers have said? Or is it an adjective he's applied to himself?
Either way, if the code doesn't work, there are two options: either you've made a mistake in copying it, or he made a mistake in writing it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Okay sir! Got your point, please calm down 😊
|
|
|
|
|
Quote: ouTube coding tutorial videos aren't worth the paper they're printed on.
Or the screen they are presented on.
Quote: either you've made a mistake in copying it, or he made a mistake in writing it
Indeed, back to the drawing board.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
