Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a disagreement with my colleague about sending/receiving a data structure between two machines (Also with different compilers) by UART.
Our data structure has several simple variable types as its fields (like int32, uint8 and etc).
In his opinion, to have a data structure with the same sequence and alignment in their fields, we have to use serializer and deserializer. Otherwise, Our code has the potential of different struct layout between two sides.
But I did it without using serializer/deserializer many times and never saw any problem.
I think using from the #pragma pack(...), guarantee our purpose. Because of most differences in each compiler (In data structures compiling) occurs in fields alignment due to padding for speedup or size optimization. (Ignore the different of endianness).
For more details, We want to send/receive a struct between a Cortex-M4 (IAR) and PC (Qt in windows) by UART currently.
Am I in a wrong way? Or my friend?!
This is, I'm afraid, fundamentally a question of opinion, that can never be fully resolved.
For what it's worth, I am adamantly, vociferously with your colleague. I believe in writing explicit serializers and deserializers. I don't believe in blatting out an in-memory data structure and hoping that the other side can slurp it down without error. I don't believe in ignoring endianness differences. I believe that "blatting it out" will inevitably fail, in the end, somewhere, and I don't want to run that risk. I believe that although the explicit de/serializers may seem to be more trouble to write up front, they save time in the long run because of all the fussing and debugging you don't have to do later.
But there are also huge swaths of programmers (I suspect a significant majority) who agree entirely with you: that given enough hacking, and suitable pragmas and packing directives, you can get the "blat it out" technique to work at least most of the time, and it may be more efficient, to boot. So you're in good company, and with as many people as there are out there who obviously agree with you, I can't tell you that you're wrong.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
An experienced programer claims that passing values by pointer can slow the program or at least the compiler. Is that true ?
https://www.youtube.com/watch?feature=player_embedded&v=w7ay7QXmo_o#t=288
I watched the given segment of the video.
Situation:
A guy has a small third-party struct and passes it by value.
Why is it good:
1. Small struct doesn't take so much space to slow down the parameter passing through stack and you can (theoretically) achieve better memory/cache usage since you don't use the pointer to access memory. It's possible that compiler/optimizer couldn't do this for you as the guy mentions.
2. It is a third-party struct, it is not very probable that its size will change during the development of the program.
3. There is a difference in what the function signature is saying about its access/ownership with regard to the struct when it takes const pointer vs non-const pointer vs value, ...
What is questionable:
1. The guy doesn't really explain in-depth what is going on and why he did this optimization. Why to do it and speak about it at all then?
2. I don't see how this would slow down a compiler/optimizer in any way, but I'm not any expert on this matter.
Why this shouldn't be a general programming rule:
1. If you're not using a third-party struct, it is quite probable that your struct will change during the development process and you will either have inefficient code or alot to rewrite. Or probably the compiler will do the job for you and then there's no point of starting with it in the first place.
2. In development process where you are creating a new code, only thing you should think about performance-wise is the efficiency of the core algorithms and datastructures. If you write terrible sort algorithm, you won't help it by passing a struct by a value. As mentioned in comments, it depends on the consequences. I doubt that anyone can really foresee that something as marginal (performance-wise) as passing by value vs passing by pointer, when it comes to small structs, makes significant performance impact. Making such decision should be based on either knowing the consequences very well (ideally having solved this exact issue earlier) or having a profiler report that states that there is a performance problem with this.
Taking that into account, then a function that updates the game(?) window, that is run 60 or possibly even 120 times per second, is to be assumed the core of the program and should be optimized as much as possible. And it seems that the guy was working on it and found that he gets better results by passing the struct by value instead of passing by pointer.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Is there a C standard conforming way to do struct alignment?
I know that one could put the biggest elements first but I am in a situation where I am about to implement a protocol.
No, not in general.
You absolutely cannot change the order of elements in a structure, they have to be in the exact order as declared.
But you also cannot know in advance what some future processor will prefer, in terms of alignment.
Protocols (which are "external" representations) should never involve directly copying to/from a struct in memory; instead you must serialize/deserialize each struct member on its own.
For implementing a protocol, it is best to serialize the values as needed and deserialize them as well.
This retains compatibilty across architectures with varying data field sizes, alignment requirements and endianness.
You can specify alignment in C11 with the _Alignas keyword (see also stdalign.h). You can look it up in the draft of the C11 standard that is freely available.
Depending on some kind of directive is probably not a good idea. I would not do it. Custom serializers/deserializers are the standard here.
I suggest writing a simple parser that would process a struct declaration and prepare a set of serialize/deserialize functions. If it is a simple plain old data structure, the parser and code generator will be very simple and efficient.
It sounds like you plan to do something like a union overlay to encode / decode the protocol. This is a bad idea. It is much better to do a proper serialise / deserialise, field by field.
This is much more portable.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
At this link here it says that the basic unit of oracle storage is a data block.
"One data block corresponds to a specific number of bytes of physical database space on disk."
Is it wrong to say that a data block is a like a .txt file?
A database block is a unit of organisation. So it really isn't very like a .txt file. In fact, it is more like processed cheese.
Perhaps a museum specimen cabinet is a better metaphor. It is a storage device, with a specific location (a table) and broken up into smaller units (rows).
Although, as the data block is actually a unit of I/O we can think of it as a train carriage.
Ultimately, it is best to read the Concepts Guide. Metaphors make for great poetry, but a poor one can confuse more than it enlightens. Find out more.
Off hand, I suspect that a data block has more in common with a file system block. Database files on disk are binary; they can hold anything in whatever representation the database wants. They could even hold parts of things and the rest be scattered across the file. One would almost never try to interact with their content directly. We let the database worry about what is in those files and stay out of its way, much like you would stay out of your OS's way when it's handling your disk drives.
So in short, you shouldn't care. Don't touch the content in those files unless you really, really, really, really know what you're doing. Based on the fact you're even asking this question, you don't know enough about what you're doing to mess with them.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My anti-virus identifies the compiled ".exe" of this source as a virus
"Gen: Variant:Graftor" . Can anybody explain why?
void main()
{
float x=3.0/7.0;
double y=3.0/7.0;
int a= (x==y);
}
Well, unmanaged / native programs can pose security risks and probably your antivirus marked this as such. Antiviruses use heuristics - so the algorithms are aproximate, they tend to work on a "best effort" idea, and in case of antiviruses "false positives" like your sample is preferable to missing actual viruses.
Another possibility is the way you compiled your program, there are a lot of compiler optimization and some are related to security - so your program randomizes certain parts of the memory etc. Maybe the antivirus looks at how a C program is compiled and yours has no security flags turned on? Hmm...
About Generic Detections
Unlike more traditional detections (also known as signatures or single-file detections) a Generic Detection does not identify a unique or individual malicious program. Instead, a Generic Detection looks for broadly applicable code or behavior characteristics that indicate a file as potentially malicious, so that a single Generic Detection can efficiently identify dozens, or even hundreds of malware.
This is a false positive. These sometimes occur in every antivirus product because of the complexity of present-day malware and file compression/protection utilities that are used on both malware and legitimate software.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
c89
gcc (GCC) 4.7.2
Hello,
I am looking at some string functions as I need to search for different words in a sentence.
I am just wondering are the c standard functions fully optimized.
For example the functions like these:
memchr, strstr, strspn, strchr, etc
In terms of high performance as that is what I need. Is there anything better?
Regards,
You will almost certainly find that the standard library functions have been optimised as much as they can, and they will probably outdo anything you code up in C.
Note that this is for the general case. If there is some restriction you're able to put on the functions, or some extra piece of information you have on the data itself, you may be able to get your code to run faster, since you have the advantage of that restriction or information.
For example, I've written C code for malloc that blew a library-supplied malloc away because I knew the application would never ask for more than 256 bytes so I just gave 256 bytes on every request. Yes, that was a waste of memory but it allowed speed improvements beyond the general case.
But, for the general case, you're better off sticking with the supplied stuff.
Fully optimized? Optimized for what?
Yes, C functions of stdlib written to be very efficient and were tested/debugged for a years, so you definitely shouldn't worry about most of them.
Assuming, that you always align your data to 16-byte boundaries and allocate every time about 16 bytes extra or so, it's definitely possible to speed up most stdlib routines.
But assuming that eg. strlen is not known in advance, or that reading just one byte too much can cause a segmentation fault, I wouldn't bother.