|
sanket.patel wrote: but dont you think this should not be allowed??
play VB if you're age to play with a plastic hammer.
if you code in C/C++, know that you can break much more than that.
don't code what you can regret later...
|
|
|
|
|
VB and C# are languages written to cater to the lowest common denominator. C++ assumes a level of skill in the developer. #define is a hangover from C, which C++ is derived from. The designer of C++ would prefer it was not there, but it's still true that his design philosophy is to give the language powerful features and assume his users know how to use them.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: #define is a hangover from C, which C++ is derived from. The designer of C++ would prefer it was not there, but it's still true that his design philosophy is to give the language powerful features and assume his users know how to use them.
A hangover, maybe, but it is o so powerful. But with every powerful it should be used with care.
#define is a dangerous tool in the hands of the unexperienced.
codito ergo sum
|
|
|
|
|
BadKarma wrote: hangover, maybe, but it is o so powerful.
I agree with Stroustrup. I try to avoid using it whever I can, I think it's a poor tool. But, it is powerful, and no doubt can be used effectively at times.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
You got sig-ed. 'nce again.
VB and C# are languages written to cater to the lowest common denominator. C++ assumes a level of skill in the developer. - Christian Graus
|
|
|
|
|
sanket.patel wrote: #define private public
sanket.patel wrote: I was able to access private member outside the class? why did this work?
of course you could !! you told it (with the #define) to replace each private keyword occurence by public... so that every private member is actually public.
why on earth where you trying to do with such horror ?! 
|
|
|
|
|
Actually !!
I was asked to find the ways to access private members outside the class?
so one method is using friends....
and i thought of this as the other way...
Thanks,
sanket
|
|
|
|
|
sanket.patel wrote: I was asked to find the ways to access private members outside the class
and you chose the worst...
if members are private, it's to deliberately hide them from the outside.
look. if you have an object engine, do you know how it works internally ? certainly not. you only see the apis (accelerator, starter, etc...).
anyway, have you thought to members accessors (getters, setters) ?
|
|
|
|
|
Thank you very much!
yeah I know about getters and setters and I know I choose the worst!
but the the question is about that only.. i.e. the unusual ways to access the private data.
Thanks,
sanket
|
|
|
|
|
GIGO - if you pull stunts like that, don't be surprised when you get odd results.
|
|
|
|
|
sanket.patel wrote: #define private public
My opinion is that you will *EXCEL* in the "Coding Horros" forum. Well, what are you waiting for? Post some of your fantastic code there! 
Nobody can give you wiser advice than yourself. - Cicero
ப்ரம்மா
|
|
|
|
|
To make the most of your coding experience, you probably should try:
To save testing:
<br />
#define true false<br />
this always happens anyway:
<br />
#define this NULL<br />
to avoid accidental deletion
<br />
#define delete /##/<br />
avoid wasting loop iterations:
<br />
#define break continue<br />
just in case the others are boring:
<br />
#define try do<br />
#define catch while<br />
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
EXCELLENT!
These fixed a bunch of my problems.
Thanks!
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I have just upgraded from 6.0 to Visual studio 2005. None of my code from programs written under C++ 6.0 will build. I get all sorts of errors "cannot convert perameters" etc... Is there a way to set my project so I can use my original code?
|
|
|
|
|
You're getting those errors because the compilers in VC 7 and 8 are vastly improved over VC 6, and don't accept code that VC 6 did. You'll need to bite the bullet and fix up the code.
|
|
|
|
|
Thanks for your response. I am able to open the original project with VC 8 and it builds fine but, uses the old visual styles. I would just like to be able to use the new styles without re-writting the whole program. I was hoping there were some depecndancies or something along those lines that would accomplish this. Seems kinda harsh to have re-write the whole thing
Thanks Again,
Terry
|
|
|
|
|
Google for "common controls manifest" - there's info about the visual styles all over the place.
|
|
|
|
|
Anyone know how to change the text color for a particular column in a record list?
I have:
COLORREF crBkColor = (255,0,0);
m_RecordList.SetTextColor(crBkColor);
m_RecordList.SetItemText( m_nSelItem, THE_COLUMN, TEXT("HELLO") );
But i only want to color that record in that specific column and not all records in all columns.
|
|
|
|
|
I hope i could get a view on this .
if i have an STL vector
vector<BYTE> vec[45] ;
Now BYTE * p = reinterpret_cast<BYTE*>&vec[0] ;
some operations
..
p++;
is it safe to assume that the pointer p can be used safely even though its pointing to the address of a vector ?
-- modified at 15:44 Wednesday 11th April, 2007
-- modified at 16:32 Wednesday 11th April, 2007
Engineering is the effort !
|
|
|
|
|
It can be if you intend on accesing bytes of the vector objects.
It doesn't point to the elements contained in the vectors.
*edited*
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
Mark Salsbery wrote: It can be if you intend on accesing bytes of the vector object.
 You win a free Fish Filet! 
led mike
|
|
|
|
|
Thanks man! I'm HUNGRY!
Looking at it again... &vec is the address of the address of the first vector in the array?
Help
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
Sorry I intended to use
Now BYTE * p = reinterpret_cast<BYTE*>&vec[0] ;
This is meant to point to the first byte .
however is it safe to do operations such as
p++ and expect it to move to the next vector element( next byte in this case) .
I am asking this since someone gave me this as a solution of creating a block of memory dynamically and not worrying about calling delete ( as one would with doing new) .
Engineering is the effort !
|
|
|
|
|
act_x wrote: Sorry I intended to use
Now BYTE * p = reinterpret_cast<byte*>&vec[0] ;
Cool. That syntax reads better to me Just reinterpret_cast<BYTE*>(vec) "works" too.
act_x wrote: however is it safe to do operations such as
p++ and expect it to move to the next vector element( next byte in this case) .
p points to the first byte of the first vector object, NOT to the elements of the first vector.
So, no.
Mark
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
|
act_x wrote: I am asking this since someone gave me this as a solution of creating a block of memory dynamically and not worrying about calling delete ( as one would with doing new) .
A "smart pointer" or similar may be a better solution.
"If you can dodge a wrench, you can dodge a ball."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
