C / C++ / MFC

Re: const in class as a member variable?

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 | :)

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 6:22

sam_psycho

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()
{
}

Re: const in class as a member variable?

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

FindItem of ListCtrl not find exact string in list.

23-Jul-09 3:47

CWnd::SetOwner is a method of the MFC CWnd class. Since it isn't virtual you cannot override it (BTW: what would be the purpose of doing it?).
Smile | :)

Le@rner23-Jul-09 2:32

Le@rner

23-Jul-09 2:32

HI all

i m using FindItem find string in ListCtrl but its not find Exact string please tell me how can i find exact string with FindItem.

i m using this code.

CListCtrl m_list;
LVFINDINFO info;
	int nIndex;

	info.flags = LVFI_PARTIAL|LVFI_STRING;
	info.psz = _T("Test");

	// Delete all of the items that begin with the string.
	while ((nIndex = m_list.FindItem(&info)) != -1)
	{
	   m_list.DeleteItem(nIndex);
	}

here it can delete "test","test1" etc.

please help me for this.

To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.

Re: FindItem of ListCtrl not find exact string in list.

krmed23-Jul-09 2:43

krmed

23-Jul-09 2:43

Perhaps the find is case sensitive. You specified

_T("Test")

but the strings you show begin with

"test"

(notice the first letter case difference).

Hope that helps.

Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193

Re: FindItem of ListCtrl not find exact string in list.

Muhammad Mazhar23-Jul-09 2:54

Muhammad Mazhar

23-Jul-09 2:54

First look for some overload of Find method that takes some argument to tell him that this find is case sensitive.

Share your experience with others
Check my Blog...

Locking 24bpp bitmap portion

Chesnokov Yuriy23-Jul-09 1:24

23-Jul-09 1:24

How to select correct width to lock from 24bpp bitmap of random width, that the locked bitmpa data has the stride equal to 3 * locked bitmap data width?

bitmapData.stride == bitmapData.width * 3

Чесноков

uraeu23-Jul-09 3:08

uraeu

23-Jul-09 3:08

Depends how your bitmap is stored.
If you have this structure:

BITMAPINFOHEADER bmHeader

it has a member

//LONG   biWidth; 
LONG width = bmHeader.biWidth

Chesnokov Yuriy23-Jul-09 4:07

23-Jul-09 4:07

I need to do it using GDI+
How do we need to decrease bitmap width, that after it was locked to read its RGB triplets, the stride in that array will be equal to (3 * width)

e.g. 640x480 24bpp bitmap has stride 1920 = 3 * 640
but some 257x150 24bpp has stride not equal to 3 * 257

What is the formula to decrease 257 to fit into 3 * width = stride?

Чесноков

Randor 23-Jul-09 5:25

Randor

23-Jul-09 5:25

I believe the memory holding the pixel data is DWORD aligned. So wouldnt you just do:

#define ALIGN(val)((val + 3) & ~3)
DWORD iSize = (sizeof(RGBTRIPLE) * bitmapData.width);
iSize = ALIGN(iSize);

Am I right?

Best Wishes,
-David Delaune

Chesnokov Yuriy23-Jul-09 8:06

23-Jul-09 8:06

say we have width = 257;
what is the width should be to (width * 3) % 4 = 0

Чесноков

Randor 23-Jul-09 8:27

Randor

23-Jul-09 8:27

(((257 * sizeof(RGBTRIPLE)) + 3) & ~3) == 772;

Best Wishes,
-David Delaune

Chesnokov Yuriy23-Jul-09 19:24

23-Jul-09 19:24

I do not need to estimate stride of bitmap given the width I need to estimate width of the bitmap for a stride. In the equation 257 is the x variable needed to be found:

(((x * sizeof(RGBTRIPLE))) + 3) & ~3) = 772

we have width = 257
257 * 3 = 771, 771 / sizeof(DWORD) = 192.75

hence we need to decrease 257 the way the stride / 4 = integer
252 * 3 = 756, 756 / sizeof(DWORD) = 189

How can we found that width = 252 from original 257?

Чесноков