hi i'm working on a personal project
for a transport parser.
i want to be able to represent a recived packet in binary number and afterwards be able to set specific bits.
I've got a pretty good idea how to do the second part but i'm really stuck at the beginning
ive got an advice to use unsigned char for that but can i really represent a full packet in that variable.
thanks
an unsigned char array is probably what you need: you can store whatever you want in this structure and access it in whatever means pleases you.
You could have this container in a bigger container too: the bigger container would have pointers to the each layer's beginning & end etc.
I'd probably have a simple class (simple to begin with anyway):
class Packet
{
public:
Packet(unsigned int length);
Packet(void *data);
bool getBit(unsigned int bit);
void setBit(unsigned int bit,bool set);
private:
std::vector<unsigned char> bytes;
};
That's just to start, no doubt it would get more complex depending what you use it for. You might consider overloading the array operator but that's probably outside "beginner level" and maybe best ignored right now.
Related
This MIPS simulator will read in a text file consisting of LC3100 machine code instructions (represented as decimal values), and execute the program, then display the values of register files and memory after each instruction is completed.
I do not understand how this can be done and simply need a format for what steps I need to take in order to create the simulator in MIPS. Do I write code in C++ or write the code in MIPS? How do I read files if it is in MIPS? Honestly, just confused.
I do not know where I need to start from. This is what I am asking to help figure out.
I'd imagine you'd want to create some global variables that represent your registers and memory:
int memory[0x80000000/4];
int reg_v0;
int reg_t0;
int* reg_pc;
// etc
And then define some functions that mimic the way MIPS behaves. You'll need to read up on how the CPU operates (which is why this example function may seem arbitrary but really it isn't.)
void MIPS_multu(int regA, int regB)
{
// void because we're writing to global variables.
uint64_t temp = regA * regB;
reg_hi = temp >> 32;
reg_lo = (temp & 0x00000000FFFFFFFF);
}
Finally, you'll need to understand how MIPS instructions are encoded and create a routine that can unpack them and select the correct function.
int memory[0x80000000/4];
int reg_v0;
int reg_t0;
int* reg_pc;
// etc
int main()
{
reg_pc = &memory[0];
while (reg_pc < &memory[0x80000000/4])
// chances are this is either invalid C or just bad practice,
// but I can't think of a better way to express the idea
{
int temp = *reg_pc;
// use bitwise operators etc to figure out what the instruction represents,
// and switch cases to pick the functions.
reg_pc++;
}
}
standard C lib:
int fputc(int c , FILE *stream);
And such behaviors occured many times, e.g:
int putc(int c, FILE *stream);
int putchar(int c);
why not use CHAR as it really is?
If use INT is necessary, when should I use INT instead of CHAR?
Most likely (in my opinion, since much of the rationale behind early C is lost in the depths of time), it it was simply to mirror the types used in the fgetc type functions which must be able to return any real character plus the EOF special character. The fgetc function gets the next character converted to an int, and uses a special marker value EOF to indicate the end of the stream.
To do that, they needed the wider int type since a char isn't quite large enough to hold all possible characters plus one more thing.
And, since the developers of C seemed to prefer a rather minimalist approach to code, it makes sense that they would use the same type, to allow for code such as:
filecopy(ifp, ofp)
FILE *ifp;
FILE *ofp;
{
int c;
while ((c = fgetc (ifp)) != EOF)
fputc (c, ofp);
}
No char parameters in K&R C
One reason is that in early versions1 of C there were no char parameters.
Yes, you could declare a parameter as char or float but it was considered int or double. Therefore, it would have, then, been somewhat misleading to document an interface as taking a char argument.
I believe this is still true today for functions declared without prototypes, in order for it to be possible to interoperate with older code.
1. Early, but still widespread. C was a quick success and became the first (and still, mostly, the only) widely successful systems programming language.
I haven't written C in quite some time and am writing an app using the MySQL C API, compiling in g++ on redhat.
So i start outputting some fields with printfs... using the oracle api, with PRO*C, which i used to use (on suse, years ago), i could select an int and output it as:
int some_int;
printf("%i",some_int);
I tried to do that with mysql ints and i got 8 random numbers displayed... i thought this was a mysql api issue and some config issue with my server, and i wasted a few hours trying to fix it, but couldn't, and found that i could do:
int some_int;
printf("%s",some_int);
and it would print out the integer properly. Because i'm not doing computations on the values i am extracting, i thought this an okay solution.
UNTIL I TRIED TO COUNT SOME THINGS....
I did a simple:
int rowcount;
for([stmt]){
rowcount++;
}
printf("%i",rowcount);
i am getting an 8 digit random number again... i couldn't figure out what the deal is with ints on this machine.
then i realized that if i initialize the int to zero, then i get a proper number.
can someone please explain to me under what conditions you need to initialize int variables to zero? i don't recall doing this every time in my old codebase, and i didn't see it in the example that i was modeling my mysql_stmt code from...
is there something i'm missing? also, it's entirely possible i've forgotten this is required each time
thanks...
If you don't initialize your variables, there's no guarantee of a default 0/NULL/whatever value. Some compilers MIGHT initialize it to 0 for you (IIRC, MSVC++ 6.0 would be kind enough to do so), and others might not. So don't rely on it. Never use a variable without first giving it some sort of sane value.
Only global and static values will be initialized to zero. The variables on the stack will always contain garbage value if not initialized.
int g_var; //This is a global varibale. So, initialized to zero
int main()
{
int s_var = 0; //This is on stack. So, you need to explicitly initialize
static int stat_var; //This is a static variable, So, initialized to zero
}
You always neet to initialize your variables. To catch this sort of error, you should probably compile with -Wall to give you all warnings that g++ can provide. I also prefer to use -Werror to make all warnings errors, since it's almost always the case that a warning indicates an error or a potential error and that cleaning up the code is better than leaving it as is.
Also, in your second printf, you used %s which is for printing strings, not integers.
int i = 0;
printf("%d\n", i);
// or
printf("%i\n", i);
Is what you want.
Variable are not automatically initialized in c.
You have indeed forgotten. In C and C++, you don't get any automatic initialization; the contents of c after int c; are whatever happens to be at the address referred to by c at the time.
Best practice: initialize at the definition: int c = 0;.
Oh, PS, and take some care that the MySQL int type matches the C int type; I think it does but I'm not positive. It will be, however, both architecture and compiler sensitive, since sizeof(int) isn't the same in all C environments.
Uninitialized variable.
int some_int = 0;
Why is it bad practice to declare variables on one line?
e.g.
private String var1, var2, var3
instead of:
private String var1;
private String var2;
private String var3;
In my opinion, the main goal of having each variable on a separate line would be to facilitate the job of Version Control tools.
If several variables are on the same line you risk having conflicts for unrelated modifications by different developers.
In C++ :
int * i, j;
i is of type int *, j is of type int.
The distinction is too easily missed.
Besides having them on one line each makes it easier to add some comments later
I think that there are various reasons, but they all boil down to that the first is just less readable and more prone to failure because a single line is doing more than one thing.
And all that for no real gain, and don't you tell me you find two lines of saved space is a real gain.
It's a similar thing to what happens when you have
if ((foo = some_function()) == 0) {
//do something
}
Of course this example is much worse than yours.
In C/C++, you also have the problem that the * used to indicate a pointer type only applies to the directly following identifier. So a rather common mistake of inexperienced developers is to write
int* var1, var2, var3;
and expecting all three variables to be of type 'int pointer', whereas for the compiler this reads as
int* var1;
int var2;
int var3;
making only var1 a pointer.
With separate lines, you have the opportunity to add a comment on each line describing the use of the variable (if it isn't clear from its name).
Because in some languages, var2 and var3 in your example would not be strings, they would be variants (untyped).
Why is that bad practice? I don't think it is, as long as your code is still readable.
//not much use
int i, j, k;
//better
int counter,
childCounter,
percentComplete;
To be honest I am not against it. I think that its perfectly feasible to group similar variables on the same line e.g.
float fMin, fMax;
however I steer clear when the variables are unrelated e.g.
int iBalance, iColor;
Relevance.
Just because two variables are of type String does not mean they are closely related to each other.
If the two (or more) variables are closely related by function, rather then variable type, then maybe they could be declared together. i.e. only if it makes sense for a reader of your program to see the two variables together should they actually be placed together
Here's my reasons:
Readability, easier to spot if you know there's only one on each line
Version control, less intra-line changes, more single-line additions, changes, or deletions, easier to merge from one branch to another
What about the case such as:
public static final int NORTH = 0,
EAST = 1,
SOUTH = 2,
WEST = 3;
Is that considered bad practice as well? I would consider that okay as it counters some of the points previously made:
they would all definitely be the same type (in my statically typed Java-world)
comments can be added for each
if you have to change the type for one, you probably have to do it for all, and all four can be done in one change
So in an (albeit smelly code) example, is there reasons you wouldn't do that?
Agree with edg, and also because it is more readable and easy for maintenance to have each variable on separate line. You immediately see the type, scope and other modifiers and when you change a modifier it applies only to the variable you want - that avoids errors.
to be more apparent to you when using Version Control tools (covered by Michel)
to be more readable to you when you have the simplest overflow/underflow or compile error and your eyes failed to point out the obvious
to defend the opposite (i.e. multi-variable single-line declaration) has less pros ("code textual vertical visibility" being a singleton)
It is bad practice mostly when you can and want to initialize variables on the deceleration. An example where this might not be so bad is:
string a,b;
if (Foo())
{
a = "Something";
b = "Something else";
}
else
{
a = "Some other thing";
b = "Out of examples";
}
Generally it is, for the version control and commenting reasons discussed by others, and I'd apply that in 95% of all cases. however there are circumstances where it does make sense, for example if I'm coding graphics and I want a couple of variables to represent texture coordinates (always referenced by convention as s and t) then the declaring them as
int s, t; // texture coordinates
IMHO enhances code readability both by shortening the code and by making it explicit that these two variables belong together (of course some would argue for using a single point class variable in this case).
while attempting this question https://www.interviewbit.com/problems/remove-element-from-array/
Method 1 gives Memory Limit exceeded for this code:
Type 1:
int i,j;
Type 2:
int i;
int j;
type 1: Gives Memory Limit Exceeded
int removeElement (int* A, int n1, int B)
{
int k=0, i;
for(i=0;i<n1;i++)
if(A[i]!=B)
{
A[k]=A[i];
k++;
}
return k;
}
Whereas type 2 works perfectly fine
int removeElement (int* A, int n1, int B)
{
int k=0;
int i;
for(i=0;i<n1;i++)
if(A[i]!=B)
{
A[k]=A[i];
k++;
}
return k;
}
When is it appropriate to use an unsigned variable over a signed one? What about in a for loop?
I hear a lot of opinions about this and I wanted to see if there was anything resembling a consensus.
for (unsigned int i = 0; i < someThing.length(); i++) {
SomeThing var = someThing.at(i);
// You get the idea.
}
I know Java doesn't have unsigned values, and that must have been a concious decision on Sun Microsystems' part.
I was glad to find a good conversation on this subject, as I hadn't really given it much thought before.
In summary, signed is a good general choice - even when you're dead sure all the numbers are positive - if you're going to do arithmetic on the variable (like in a typical for loop case).
unsigned starts to make more sense when:
You're going to do bitwise things like masks, or
You're desperate to to take advantage of the sign bit for that extra positive range .
Personally, I like signed because I don't trust myself to stay consistent and avoid mixing the two types (like the article warns against).
In your example above, when 'i' will always be positive and a higher range would be beneficial, unsigned would be useful. Like if you're using 'declare' statements, such as:
#declare BIT1 (unsigned int 1)
#declare BIT32 (unsigned int reallybignumber)
Especially when these values will never change.
However, if you're doing an accounting program where the people are irresponsible with their money and are constantly in the red, you will most definitely want to use 'signed'.
I do agree with saint though that a good rule of thumb is to use signed, which C actually defaults to, so you're covered.
I would think that if your business case dictates that a negative number is invalid, you would want to have an error shown or thrown.
With that in mind, I only just recently found out about unsigned integers while working on a project processing data in a binary file and storing the data into a database. I was purposely "corrupting" the binary data, and ended up getting negative values instead of an expected error. I found that even though the value converted, the value was not valid for my business case.
My program did not error, and I ended up getting wrong data into the database. It would have been better if I had used uint and had the program fail.
C and C++ compilers will generate a warning when you compare signed and unsigned types; in your example code, you couldn't make your loop variable unsigned and have the compiler generate code without warnings (assuming said warnings were turned on).
Naturally, you're compiling with warnings turned all the way up, right?
And, have you considered compiling with "treat warnings as errors" to take it that one step further?
The downside with using signed numbers is that there's a temptation to overload them so that, for example, the values 0->n are the menu selection, and -1 means nothing's selected - rather than creating a class that has two variables, one to indicate if something is selected and another to store what that selection is. Before you know it, you're testing for negative one all over the place and the compiler is complaining about how you're wanting to compare the menu selection against the number of menu selections you have - but that's dangerous because they're different types. So don't do that.
size_t is often a good choice for this, or size_type if you're using an STL class.