C / C++ / MFC

23-Jul-09 3:43

Is it possible to declare member variable of class as a const, if yes,please give me 1 example how to initialize it and if not, why?

Cedric Moonen23-Jul-09 3:47

Cedric Moonen

23-Jul-09 3:47

Yes, it is possible. You have to initialize it in the constructor initialization list:

MyClass::MyClass() : myConstInt(5) 
{
}

You can also initialize it in the header file too, when declaring it:

class MyClass 
{
   const int myConstInt = 5;
}

Cédric Moonen
Software developer

Charting control [v2.0]
OpenGL game tutorial in C++

sam_psycho23-Jul-09 3:56

23-Jul-09 3:56

This is working fine

 MyClass::MyClass() : myConstInt(5) 
{
}

but it is not possible,

class MyClass 
{
   const int myConstInt = 5;
}

compiler is giving error,

So I guess only one way to initialize const in a class..

Cedric Moonen23-Jul-09 3:58

Cedric Moonen

23-Jul-09 3:58

Ooops, my bad. I don't use that notation very often. I thought it was ok but it is only valid if the member is static also.

Cédric Moonen
Software developer

Charting control [v2.0]
OpenGL game tutorial in C++

CPallini23-Jul-09 3:53

23-Jul-09 3:53

sam_psycho wrote:
Is it possible to declare member variable of class as a const,

Yes.

sam_psycho wrote:
if yes,please give me 1 example how to initialize it

class A
{
  static const int  c = 299792458;	
  const int a;

  A():a(5){}
};

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

sam_psycho23-Jul-09 4:20

23-Jul-09 4:20

from above discussion I have come to conclusion that compiler does not allow
any type of initialization in class, so statement

static const int  c = 299792458;

in your code also creating problem... Frown | :(

CPallini23-Jul-09 6:06

23-Jul-09 6:06

You're wrong (I'm right, of course... Roll eyes | :rolleyes:

). It looks like you missed the static modifier.
Smile | :)

sam_psycho23-Jul-09 6:22

23-Jul-09 6:22

who is lying compiler or you?..but I should believe in compiler and it says that

error: c:\test.cpp 6: cannot initialize class member here

try this code

class temp
{
 static const int i=10;
};
void main()
{
}

CPallini23-Jul-09 6:50

Which low-level I/O API is better? MFC or POSIX

23-Jul-09 6:50

I never lie. Anyway maybe your compiler follows strictly the C++ stanbdard.
(my compiler doesn't complain, see [^]).
Smile | :)

TitleBar

kumar sanghvi23-Jul-09 3:36

kumar sanghvi

23-Jul-09 3:36

Hi,
How can i increase the height of the Title bar of a Dialog based on the font size.....

Re: TitleBar

Mahesh Kulkarni23-Jul-09 20:59

Mahesh Kulkarni

23-Jul-09 20:59

Why this question is repeated?

The secret of life is not enjoyment
but education through experience.
- Swami Vivekananda.

Dimitris Vikeloudas23-Jul-09 3:13

Dimitris Vikeloudas

23-Jul-09 3:13

Few years ago we ported our application low-level to MFC. Instead of using open, read, write etc. we moved to MFC specifics like CreateFile(), ReadFile & WriteFile. We also did the same for the locking functions i.e. use LockFileEx instead of fcntl. Recently we start using WRITE_THROUGH flags everywhere to force direct writing to disk rather than via O.S system cache. Whilst most customers are happy and solved few of their problems some of them still have issues that are hard to track and reproduce. Hence there is a thought to go back to POSIX I/O API but this may creates us again more problems than it solves.

My question is the following: Assuming that we are targeting a Win32 platform (XP and Vista) which I/O is the better low-level I/O it terms of a) performance, b) security of the following choices?
i. MFC specific functions like CreateFile, LockFileEx etc.
ii. POSIX style low-level I/O API like _open(), _fcntl()using a VC++ compiler
iii. POSIX style low-level I/O but this time using a late version gcc/g++ compiler.

If someone has the same dillemas would be nice to hear the views. Also if someone knows any article or comparisons could you please direct me to them?

Thanks.

Re: Which low-level I/O API is better? MFC or POSIX

CPallini23-Jul-09 3:41

Re: Which low-level I/O API is better? MFC or POSIX

23-Jul-09 3:41

If you're targetting only Windows then I would (politely) suggest you Win32 API, such as CreateFile, LockFileEx, etc..
Smile | :)

RomanMzh23-Jul-09 3:50

RomanMzh

23-Jul-09 3:50

Short answer
If your only targeting Windows platforms use CreateFile.

Longer answer
The main reason you would want to use the CRT functions (open() close() etc) is to make your program more portable there isn't any obvious advantage in speed or performance.
That said, using win32 APIs does allows you to specify various parameters that CRT doesn't like Security attributes, Template file etc.

It doesn't really matter what compiler you use in terms of the APIs you call the CRT you will use is the same regardless of the compiler used. That said I don't see a reason to use gcc to compile code for Windows.

Re: Which low-level I/O API is better? MFC or POSIX

Dimitris Vikeloudas23-Jul-09 4:25

Dimitris Vikeloudas

23-Jul-09 4:25

I am aware of the portability benefits of CRT functions. I also know that in standard C their API derives from the UNIX system calls. To my knowledge in a UNIX system usually (if not always) there isn't a lower level I/O function than open, read etc.

However, I couldn't find what happens in Win32 platforms. Are the CreateFile, ReadFile the equivalent of system calls? Does this mean that CRT functions like open or read are implemented using CreateFile and ReadFile. I suspect this is the case but I couldn't find any MS documentation stating that. It would be interesting actually to see outline of implementation of open/read etc using Win32 API and see what flags do they pass etc. if of course that's the way they have been written.

Re: Which low-level I/O API is better? MFC or POSIX

Randor 23-Jul-09 4:58

Randor

23-Jul-09 4:58

Dimitris Vikeloudas wrote:
Does this mean that CRT functions like open or read are implemented using CreateFile and ReadFile.

Yes. On the Windows platform many of the CRT functions are nothing more than wrappers for their Windows API equivalents. The function in question... fopen will ultimately result in a call to the CreateFile Function[^] with the OPEN_EXISTING disposition. Which is yet another wrapper for CreateFileW if your in a non-unicode build. Calling CreateFileW with OPEN_EXISTING will result in a call to the NtOpenFile Function[^] which will push all the arguments on the stack and will pass through a call gate[^] via the SYSENTER instruction and result in a call to the ZwOpenFile[^] function.

Best Wishes,
-David Delaune

Re: Which low-level I/O API is better? MFC or POSIX

Dimitris Vikeloudas23-Jul-09 6:09

Dimitris Vikeloudas

23-Jul-09 6:09

Thanks a lot...That clarifies a lot the picture.

I can suspect that compilers like g++ may provide their own implementation of open & read using the NtOpenFile or ZwOpenFile but from my perspective these internal functions are a no-go area. CreateFile etc are low-level enough Smile | :)

SetOwner(CWnd* pOwnerWnd);

Rakesh523-Jul-09 3:02

Rakesh5

23-Jul-09 3:02

Hi all,
I am new to VC++..

I saw that "void SetOwner(CWnd* pOwnerWnd)" is windows defined function..

Can we overwrite this function to our needs??

is there any function that do the same purpose, done by setowner function??

Thanks,
Rakesh.

Re: SetOwner(CWnd* pOwnerWnd);

CPallini23-Jul-09 3:47