|
Hi
It is my understanding that local variables of a Multithread application i.e those declared on the stack for each function are thread safe. Each thread BP,SP registers have a unique address so variables declared on the stack are all unique to each thread. Am I correct in understanding this ?
Thanks
|
|
|
|
|
Each thread has its own stack. When calling a function from different threads, the local function variables reside on the stack of the thread from where the function has been called. So it is thread safe.
But note that this does not apply to local static variables. While also local variables (can't be accessed from outside of the function), there is only one instance of such variables. Accessing them must be guarded (locks, atomic operations) and the function must not return a pointer to them to make the function thread safe.
|
|
|
|
|
Thanks I think of static local variables as global. I am using a local variable as a switch if local variable BOOL foo = TRUE for thread A, It (BOOL foo is not the same) for thread B
is there any reason in a Multithread application I would have to guard them (local variables non static ) there are no references to them by pointers
Thanks
|
|
|
|
|
You only have to guard shared variables (like static variables). Variables on the stack are safe.
|
|
|
|
|
THANKS SO MUCH
|
|
|
|
|
I want to print elements of array a.
My print fun is :
void print(int *a){
int i;
for(i=0;i<3;i++){
printf("%d\n",a[i]);
}
}
which works fine. But if I give :
void print(int *a[]){
int i;
for(i=0;i<3;i++){
printf("%d\n",a[i]);
}
}
(array a[] defined in main.)
its not working.What makes the difference?
|
|
|
|
|
The difference is in the prototypes :
void print(int *a) vs
void print(int *a[])
The first takes a pointer to integer. The second takes an array of pointers to integers.
To make the second function work you have to dereference a pointer :
printf( "%d\n", *a[i] );
|
|
|
|
|
the equivalent of
void print(int *a)
with array notation is
void print(int a[])
|
|
|
|
|
void print(int *a[]):
It looks like a 2 dimensional array
I think so.
|
|
|
|
|
No, it's a one-dimensional array of pointers.
|
|
|
|
|
I am Using GCC running on Linux / Ubuntu
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)
I need / like to have a single bit variable / flag passed to / from SPI hardware.
Single bit defined
// need for SPI /I2C
typedef unsigned char bit : 1; // single bit
Implemented
char x;
static bit b; // defined in generic def header
Compiler error - what initializer is missing?
In file included from ../src/MODULES/M_SPI/CASPI.h:53 ,
from ../src/MODULES/M_SPI/CASPI.cpp:34:
/media/os64/Eclipse/eclipse/Workspace/Eclipse_Oxygen_1A/VNA_2/src/MODULES/MODULE_1602/C_GenericTypeDefs.h:77:33: error: expected initializer before ‘:’ token
typedef unsigned char bit : 1; // single bit
^
../src/MODULES/M_SPI/CASPI.cpp:239:1: error: ‘bit’ does not name a type
bit C_SPIClass::I2CTX(unsigned char d) {
^
Thanks for any help.
Cheers
|
|
|
|
|
You can only have bit fields in a struct or union, it would be physically stupid to have them outside a struct or union because they couldn't be packed anyhow you might as well pick any normal type. Your somewhat pointless definition (it saves zero memory space) would be
typedef struct {
unsigned bit : 1; // single bit
} BIT;
The initialize would be
static BIT bit = { 0 };
or
static BIT bit = {.bit = 0};
The only point to bit fields is to save space or make naming and offsets easier in particular for hardware registers.
The other recommendation I make is only define them as sign or unsigned you don't have to assign a normal C type the
compiler internally knows how to cast bit fields to do operations on them.
Usually what you are doing on hardware registers is assigning the bits to match something like an 8 bit definition
typedef struct __attribute__((__packed__, aligned(1))) {
unsigned Clk : 1; // clk bit
unsigned Bit : 1; // Data bit
unsigned CS : 1; // Chip select
unsigned _reserved: 5; // 5 unused bits
} MYREGISTER;
In the above you have 8 bits packed into a byte so it saves space carrying them.
In vino veritas
modified 7-Jan-18 21:41pm.
|
|
|
|
|
|
for ex,
input: My name is Bay Max.
output: Max Bay is name My.
below is my code, but its too long and messy. How do i make it more concise and readable?
Any alternative would be appreciated.
#include <stdio.h>
#include <string.h>
#define EOL '\n'
#define MAX_SIZE 100
int main(){
char text[MAX_SIZE], back[MAX_SIZE], temp[MAX_SIZE];
int count, i, mark[50];
for(count=0; (text[count] = getc(stdin))!= EOL; ++count){
mark[count]=0;
}
text[count] = '\0';
for(i = count-1; i>=0; --i){
back[(count-1)-i] = text[i];
}
back[count] = '\0';
for(i=count-1; i>=0; --i){
if(back[i]== ' '){
mark[i] = i;
}
}
int j, k=0, l=0;
for(i=0; i<count-1; i++){
if(mark[i] != 0){
for(j=mark[i]-1; j>=k; j--){
temp[l] = back[j]; l++;
}
temp[mark[i]] = ' ';
l= l+1;
k = mark[i]+1;
}
}
for(i=count-1; i>=k; i--){
temp[l] = back[i]; l++;
}
printf("\n%s", temp);
return 0;
}
Thank you.
|
|
|
|
|
I'd make a map of the words (array of pointers to char), then iterate it backward.
|
|
|
|
|
I would be tempted to use strtok() . Then just read the returned value in reverse order.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I am developing a c++ application which deals secured information which should not be viewed but to be saved to a file.
Is there a way to write to a file which cannot be viewed directly by the user from disk whereas it could be read by the program.
|
|
|
|
|
manoharbalu wrote:
Is there a way to write to a file which cannot be viewed directly by the user from disk whereas it could be read by the program. Encrypt it?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Don't save it on the user's system.
|
|
|
|
|
manoharbalu wrote: Is there a way to write to a file which cannot be viewed directly by the user
no.
|
|
|
|
|
Do what Richard says encrypt it when your write and decrypt when you read it.
You can go from simple XOR encryption if it isn't that important to the real heavy stuff and there is a pile of libraries and code out there.
In vino veritas
|
|
|
|
|
I am using huge structure template and size is around 100kb with various member variables like char array, int, long and short. I am writing this entire structure using fwrite. But when I retreive the structure data from file using fread, some of the structure members especially long variable shows incorrect value.
Kindly suggest me if writing a full structure is wrong or how to work around.
|
|
|
|
|
Without seeing your code it is impossible to guess what you are doing wrong. How are you writing it, with a single fwrite call, or separate calls for each structure item?
|
|
|
|
|
manoharbalu wrote: Kindly suggest me if writing a full structure is wrong
As described probably it is incorrect. Even the design is suspect. Such a large collection must be divisible and as such it should be programmed that way. Note of course that this doesn't mean it cannot be handled as a serialized data stream. That is in fact what all files on disk are exactly.
Other than that it is likely that you have a bug in your code that reads or writes the data. Probably you have a size wrong. If the process was broken into smaller pieces (as I said above) then you could individually test each of those and thus insure that the entire thing was valid.
|
|
|
|
|
Have you made sure you open the file for write in binary mode.
FILE * binfile = fopen("somefilename.bin", "wb"); //Open writable bin file
You open it with just "w" command and it's in text mode some of the raw struct characters will be translated to tabs, CR, LF etc.
In vino veritas
|
|
|
|