I know what you going to think about this one: "silly trick". That's why I just put it in the title. Anyway, that is something I use everyday, so I thought it might be useful to who cares about productivity.
Well, as most of you already know, I really don't like mice. Nevertheless I respect the users who use it and like it. That is the reason why I am writing a little more about it. This time, I going to show a program I use every day: MouseTool, for the users who does not use the mouse and like it.
There is a document from Microsoft alerting about the hazards in putting your code inside a DllMain function. what is more comprehensive and easier to read than the MSDN observations. It is worth reading, even because the explanations about the loader lock and its side effects can do very good for your code health.
Wanderley,your explanation about why a program compiles in C++ and not in C seems to me logic and correct, but gave me some doubts, because I always learned that the C and C++ operator precedence are the same thing.I checked out the Appendix A in the "C ++ - How To Program" (sixth edition) and the book table is equal to the C operators precedence table and it is different from the C++ precedence table presented by you in the article.I went to the internet and found out in two websites the table and both are equal to the book table.http://en.wikipedia.org/wiki/Operators_in_C_and_C
http://www.cppreference.com/operator_precedence.htmlFrom where did you get the presented C++ table?[]s,Márcio Andrey Oliveira
The question: how to get the size of a struct member without declaring it as a variable in memory? In pseudocode:
static const size_t FIELD_SIZE_MSGID = 15; struct FEEDER_RECORD_HEADER { char MessageID[FIELD_SIZE_MSGID]; char MessageIndex[10]; }; // error C2143: syntax error : missing ')' before '.' char MessageIndexBuffer[sizeof(FEEDER_RECORD_HEADER.MessageIndex) + 1]; // error C2070: '': illegal sizeof operand char MessageIndexBuffer[sizeof(FEEDER_RECORD_HEADER::MessageIndex) + 1];
In this first try (even being a nice one) we can clearly see by instinct that the construction is not supposed to work. The compiler error is not even clear. The member access operator (the point sign) needs to have as its left some variable or constant of the same type of the struct. Since the operand is the type itself, there is no deal.
Once upon a time my old friend Kabloc wrote this little and "harmless" function in order to print the multiplication table:
#include <stdio.h> int main() { int f1,f2,s=0; for(f1=1;(f1==11&&s!=5)?s=5,f1=0,putchar(10):(f1<=10)?f1=f1:f1=12,f1<=11;f1++) for(f2=1+s;f2<=5+s;f2++)printf("%dx%d=%d%c",f2,f1,f1*f2,(f2==5+s)?10:9); return 0; }
Despite the fact the result is a strong candidate to "The International Obfuscated C Code Contest", the linux guys told him the code was not successful on GCC, and somewhere inside those four lines there was a non-standard piece of code.
I do love shortcuts. Since my very first years using computers, shortcuts had become my obsession. I research them through the time, collecting them, using them. For a long time I avoid myself from touching the mouse, trainning to remember all keystroke sequences I know.
Arrays are fascinating in C language because they are so simple and so powerful at the same time. When we start to really understand them and realize all its power we are very close to understand another awesome feature of the language: pointers.
When I was reading the K&R book (again) I was enjoying the language specification details in the Appendix A. It was specially odd the description as an array must be accessed: