|
Rage wrote: Type checking at compilation type is not done with #defines, type casting is much safer when used with types
Wrong,
since the #define is replaced before the compilation the compiler can check for type casting issues.
Rage wrote: Avoid #defines as much as possible
I can agree on this if you would use it solely as a typedef replacement.
But #defines are very usefull to make codeing easier like constants and macros
codito ergo sum
|
|
|
|
|
BadKarma wrote: Wrong,
since the #define is replaced before the compilation the compiler can check for type casting issues.
#define a 3
What is a ? an unsigned int ? a signed int ? a char ? ...
BadKarma wrote: #defines are very usefull to make codeing easier like constants and macros
I won't go into a flame war, but const is definitely better than a #define.
I agree though than SIMPLE macros can be useful.
~RaGE();
|
|
|
|
|
Hi,
don't take this wrong, but the question was which is preferred,
using #define or typedef to create a new type. You said its preferred
to use typedef (which I agree ) because when using #define the compiler
wouldn't be able to check the types.
I just stated the latter, as false.
Rage wrote: #define a 3
I agree that the 3 doesn't resemble a single type, but that wasn't what i meant.
Rage wrote: ..., but const is definitely better than a #define.
I could agree to this if one is writing an application for Computer based systems.
But when writing for embeded systems, where 2MB of memory is already considered to be a luxery,
every byte that you can save by using #defined constants is worthwhile.
And when it comes to MFC there is no such thing as a SIMPLE macros 
codito ergo sum
|
|
|
|
|
BadKarma wrote: to create a new type
Actually I even never considered using #define for creating types.
BadKarma wrote: I just stated the latter, as false.
Well, Ok.
BadKarma wrote: But when writing for embeded systems, where 2MB of memory is already considered to be a luxery,
every byte that you can save by using #defined constants is worthwhile.
I am also writing software for embedded systems (and we only have 512Ko), but I do not see where you save memory when using #defines.
If the const is loaded in RAM, which it should not, then the compiler does not optimize it correctly.
If the const is used in ROM, then it makes no difference with the #define, since the #define is replaced in-place in the code before compilation, but the value is also in the ROM.
~RaGE();
|
|
|
|
|
Rage wrote: I am also writing software for embedded systems (and we only have 512Ko), but I do not see where you save memory when using #defines.
You save memory because if you use const, the value is placed in ROM as a variable, and the compiler creates code to load it from memory like a variable every time it is needed. It (usually) takes more time and memory than if the compiler just loads an constant value.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Rage wrote: #define a 3
What is a ? an unsigned int ? a signed int ? a char ? ...
My guess to the answer - the type of "a" is not determined in the #define statement - it depends on where "a" is used in the program. As far as I know, "a" is replaced by "3" by the pre-compiler before compilation, so it may be treated as a char in one part of the program and as an int in another, etc.
So if you had the following code:
#define defValue3 3
char cOneChar;
int iIntVar;
cOneChar = defValue3 + 32;
iIntVar = defValue3 + 32;
|
|
|
|
|
Never, ever use #define to define new types. It's just asking for trouble.
One reason the others haven't mentioned yet is multiple variable definitions on one line. Say you do this:
#define INTPTR int*
INPTR p1, p2; You may think that p1 and p2 have the same type... They do not. p1 is an int* and p2 is an int. The preprocessor expands the macro definition to produce
int* p1, p2; Remember that the * modifies the variable, not the type, so the * only makes p1 a pointer.
Typedefs don't have this problem
typedef int* INTPTR;
INTPTR p1, p2; behaves exactly as expected.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
int* p1, p2;
You would not advertise this style, no? 
Were not doing C here - this is C++! 
When you really need the variable - that is when you are ready to give it a value - declare it like so:
int* p1 = WhateverGetsMeAnIntPtr();
or better still
int* p2( WhateverGetsMeAnIntPtr());
Stop definig variable you might end up not using.
Start definig variables when you need them.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Right ...
Until your compiler says "initialization of variable declared when needed skipped by goto" ... then you go back to declaring them all at the top of your function 
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Blake Miller wrote: ...goto...
Hmm - this sounds like Linux driver code.
Or is someone else still using goto on a regular basis?
Anyway, if you jump over one part of your code and are missing variables later, your code is deeply flawed anyway.
Some variables do need to exist throughout the whole function - most are not.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Well, I don't like to if( ...) statements nested 10 levels deep, and I am not fond of returns sprinkled throughout a function either. So ... goto FuncExit; in case of error. FuncExit is at bottom of funtion.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Blake Miller wrote: not fond of returns sprinkled throughout
For me, this is only a venial sin against the spirit of OO.
And a goto does make nothing clearer.
But when you only jump down to the return, you should miss no variables?
Sorry if I miss something obvious.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
We use goto a lot in functions that call other functions returning error codes.
suppose some pseudo-code like this...
if string pointer is null or string is empty
set error code
goto funcexit
if file can not be opened
set error code
goto funcexit
if file read error happens
set error code
goto funcexit
if memory allocation for structure fails
set error code
goto funcexit
FuncExit
if file opened
close file
return
-----------------
If you declare file handles, etc. as you need them, then the compiler will complain that the 'initialization' of the type was skipped by the goto.
In this case, the if statments would have only nested 5 levels deep ... ugh.
But in soeem of our more complex processing, there might be 15-20 function calls which might fail before the actual 'work' begins.
I WISH we were all OO - parts of this code base are untouched since the days of our company founders - back in 1989!
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
<sarcasm mode=true>
OMG :doh:
using a goto in c++, X|
why dont you use the functions <code>longjmp</code> and <code>setjmp</code> to write entirely incomprehensible code :laugh:
<sarcasm mode=false>
I known what you mean, because even in a switch you can have this problem.
but then again you could use { } to define the scope of that variable.
codito ergo sum
|
|
|
|
|
As long as you don't need the variable from the point of declaration all the way to end of function. Like a file handle you opened, you need it until you close the file.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
The question was about the difference between using typedef and #define for defining types, not about variable usage. I would say to use whatever style is clearest and most appropriate for your situation - I don't dictate that certain styles are evil. I have no problems with using all the features of a language (including goto...) if it is the most appropriate way of attacking a certain problem.
Besides, you seem to have misread that part of the question - that code sample is the expansion of the macro definition given before it...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I'd like to create my own string class like CString class in MFC.
Kindly suggest me some good links regarding operator overloading & Unicode-ANSI.
Thanks in advance,
Sarvan AL
|
|
|
|
|
Well for me it's pretty strange that someone wants to write another string class... there are thousands of them flying around. I'm a fan of sticking to the standard one (especially with the boost additions).
But every one his own's.
For operator overloading I would consult "The c++ programming language" from Bjarne Stroustrup.
I can't give you a real pointer for looking up some information to Unicode - ANSI because you didn't specify it more.
Well.. maybe some thoughts.
All the label says is that this stuff contains chemicals "... known to the State of California to cause cancer in rats and low-income test subjects."
Roger Wright
http://www.codeproject.com/lounge.asp?select=965687&exp=5&fr=1#xx965687xx
|
|
|
|
|
|
Sarvan AL wrote: Kindly suggest me some good links regarding operator overloading & Unicode-ANSI.
you can try this class
CCOMString[^]
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Anybody know how to/have any links to displaying images in widescreen aspect ratio with openGL?
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!
|
|
|
|
|
Nobody? I assume I just need to change the clipping rects of the front and rear planes which would alter the frustum accordingly.
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!
|
|
|
|
|
Hi all,
Sometimes I get runtime error in deleting the dynmically allocated object. I know the reasons. But how can I catch the exception during delete
Thanks in advance,
Sarvan AL
|
|
|
|
|
Most common type of problem is deleting an already deleted pointer.
You can check for null to avoid this...
if(pointer!=NULL)<br />
delete pointer;
Owner drawn
Jesus Loves
|
|
|
|
|
In C++ deleting a NULL pointer is a NOP - It is fine to do so.
You comment about a double delete is correct but only works if you NULL it after deleting it:
CSomeObject* pObj = SomeFunction();<br />
delete pObj;<br />
pObj = NULL;
delete pObj;
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
