Casting an unsigned integer that is bigger than the maximum value of a signed integer, or casting a signed integer that is negative, are both recipes for trouble as well. Casting a float to an integer, especially one that is unsigned (if the float is negative) or is smaller than sizeof(float), might be a bad idea too.
@Xander314
Basic/default/scalar types are types defined by the language. I'm not sure if that includes pointers and arrays, but I assume it would. User-defined/composite types are things like structs, classes and unions.
@chrisname I know what intrinsic types are ;) I was just unsure about the status of a pointer like LPCWSTR.
The context in which I was casting ints to floats was to get integer display resolutions to floating point values to rescale an SFML sprite. The values were 800 and 600 so there were no risks there I think...
EDIT: I've just realised that by casting ints to Qt enumerations, I am evading compiler errors. is this an acceptable circumstance?
61. Listening to music when I'm thinking about a complex problem
62. Not listening to music when I'm doing normal coding that doesn't require much thinking (and getting bored leading me to stop coding)
63. Sloppy Formatting (this one's actually quite important)
64. Leaving too many TODOs scattered throughout the code
65. Underestimating the complexity/difficulty of a task
I'm not sure if that includes pointers and arrays, but I assume it would.
An array is not a type, it's a data structure; there is no type that means "an array of ints".
T * and T * const are basic types for all valid T.
Although I don't know what a "Qt enumeration" is, casting between enum types and integers is acceptable if the enum members have well-defined integer values.
@coder777,
That should be "Using goto inappropriately". There are some cases where using goto is a good idea:
Linux Coding Style wrote:
The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.
The rationale is:
- unconditional statements are easier to understand and follow
- nesting is reduced
- errors by not updating individual exit points when making
modifications are prevented
- saves the compiler work to optimize redundant code away ;)
int fun(int a)
{
int result = 0;
char *buffer = kmalloc(SIZE);
if (buffer == NULL)
return -ENOMEM;
if (condition1) {
while (loop1) {
...
}
result = 1;
goto out;
}
...
out:
kfree(buffer);
return result;
}
69. Not adhering to the principle that I should shorten code to see the big picture without scrolling
70. Breaking my policy of keeping .cpp and .hpp within 100-200 lines at most
71. When stuck on a problem, too much persistance (switching to another part of the app is better)
72. Trying to code C++ logic that is much more easily done via SQL
73. Trying to save memory via clever logic when I should buy more RAM at $10/GB instead!
edit: didn't realize how cheap memory was until I was looking today to upgrade a 3yr old HP ML110 box - a HP ML150 G6 can hold 48GB RAM (for <$500 self-upgrade) - I know someone's going to ask why I need that much memory - nope, not editing videos or stashing porn or running virtual machines: it's a compute server
I know, but my point was that no-one could possibly need *that* much memory for streaming videos (of any kind ;) )
Unless kfmfe's point was to leave the computer on 24/7 and use the RAM as some kind of long term storage device. (perhaps I'm reading too much into it... :p)
74. Strictly and solely using one language and one paradigm as a solution to all your applications, no matter what purpose of the software will be.
75. Attempting to convert others to this ideology through means of propaganda and the berating of those who disagree.
76. 'Inventing' your own language to be [x]language but better. (chances are this means you've extended x language then picked up the metaphorical project and smashed it on a stone tablet. The shattered pieces are then gathered back together in a random assortment giving life to something new and exiting....much like a form modern art....