|
This is not the least bit standard. It's the result of someone trying to be cute.
Certainly it works - see the other responses for why - but it's pointless.
|
|
|
|
|
It's "cute" coding following the style of STL streams, where you can chain a lot of stuff together like:
cout << "Hello " << "Bob" << endl;
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I'm using MFC and when I use level 4 warnings, I get all kinds of warnings in the VS files. Especially using std::vector. The warnings are things like C4201, C4100, C4663, C4018, and C4244. I put
#pragma warning(disable: 4201 [etc...] )
in stdafx.h, but they still come up. Any way I can get rid of them, or fix them? What do you do when building on Level 4??
Nitron
_________________________________________--
message sent on 100% recycled electrons.
|
|
|
|
|
I don't build on level 4. Why bother, if you'll have to disable the warnings anyway? When i want level 4 warnings, i'll do
#pragma warning(push,4)
#pragma warning(pop)
This lets me have that good, clean feeling about *my* code, but not be annoyed by all the crap i can't change in the headers.
Shog9
------
No one's immune now, from a world of problems
No one's exempt now, from a world of pain
That's the way that it goes
when you're down here with the rest of us...
|
|
|
|
|
Thanx! That's exactly what I want to do. 
Nitron
_________________________________________--
message sent on 100% recycled electrons.
|
|
|
|
|
I have a linked list of 1000 X 1000 arrays of float, which I need for doing some simulations. When I run the part of the appln that declares the array, I get a stack overflow error. Is there a way to increase the memory allocated to my appln? With 10^6 elements repeated many times in my list, I need a lot of xtra mem. I currently have 350 MB available. Thx,
Ralf.
ralf.riedel@usm.edu
|
|
|
|
|
The stack has its limitations. You run into less than in the old 16 bit days, but its still there.
Rather than doing something like:
void MyFunction ()<br />
{<br />
float Wheee [1000][1000];<br />
....<br />
}
You can do:
void MyFunction ()<br />
{<br />
float *Whee = new float [1000*1000];<br />
....<br />
<br />
delete [] Whee<br />
}
Or other dynamic (off the heap) allocations. (e.g. LocalAlloc, IMalloc etc).
Good luck,
Iain.
|
|
|
|
|
Put your array on the heap rather than the stack. I would even wrap it in a class:
class CABigArray
{
public:
float theArray[1000][1000] = 0;
};
then:
void main()
{
CABigArray* p_ba = new CABigArray;
for(int i=0; i<1000; i++)
{
for(int q=0; q<100; q++)
p_ba->theArray[i][q] = i * q;
}
delete p_ba;
}
Nitron
_________________________________________--
message sent on 100% recycled electrons.
|
|
|
|
|
Besides the heap. You can also just
declare it "static". You'll lose
reentrancy so it will make the method
useless for multithreading or recursion,
but it's a simple one word fix.
|
|
|
|
|
Normally the stack is guarded by a guard page.
If you call a function and its stack frame doesn't fit within the current stack size anymore, the guard page will be 'touched'. That will generate a page-fault. The logic of the guard page will then increase the stack by one page and put on top another guard page.
If you have a lot of local variables (and the stack frame would be larger than one page), the compiler is responsible for generating code to touch the guard pages until the stack has grown with enough pages.
We noticed in the past that if Fortran is linked in (I think the main had to be written in fortran as well, but I'm not sure) that this logic did not work (the code to touch all the guard pages was missing in the fortran version I think). You don't have fortran in your application, do you ?
Another reason for a stack overflow could be an infinity recursion.
But I agree with Iain, allocating it is much better.
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
I try to manipulate strings of a combox dropdown list, codes as shown below:
((CComboBox *)GetDlgItem(IDC_COMBOBOX))->DeleteString(1);
((CComboBox *)GetDlgItem(IDC_COMBOBOX))->AddString(CString("hello"));
((CComboBox *)GetDlgItem(IDC_COMBOBOX))->InsertString(-1, CString("hello"));
The first line works, but the second and third lines fails (nothing happens
there, the program can go on executing). WHY??? So frustrating! Did i need to
do something before adding/inserting a string? Thanks a lot!!!
Wenrich
|
|
|
|
|
your code is OK. what is the return value from AddString?
-c
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw
|
|
|
|
|
return value from both AddString() and InsertString() is 0; but it's supposed
to be inserted at the end, therefore should be some positive value(my combox
is not empty). Any more information? Thanks!!!!!!!
|
|
|
|
|
You get an error, or only you can not see the strings?
Regards
Carlos Antollini.
Pi Five Creator
Sonork ID 100.10529 cantollini
|
|
|
|
|
If you haven't already, try doing what you did in CMyDialog::OnInitiateDialog() member function.
ralf.riedel@usm.edu
|
|
|
|
|
It's strange, isn't it? HELP!
|
|
|
|
|
I need to add basic serial port access to my Visual C++ program. I only need the program to be able to do two things:
1) Send a hex value to the serial port.
2) Wait until a hex value is received.
Baud rate will be low, I don't need anything complicated, just really basic access to serial ports, but I don't know how to do it... all the stuff on MSDN is geared towards more complex terminal emulation type stuff.
I'm not using MFC.
Thanks, any help would be greatly appreciated!
|
|
|
|
|
You can treat the serial port just like a file. In fact for Win32 programming, you have to!
m_hComPort = ::CreateFile ("COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
To write a byte out:
void WriteComByte (BYTE byOut)
{
DWORD dwWritten;
::WriteFile (m_hComport, &byOut, 1, &dwWritten, NULL);
}
Reading (blocking)
BYTE ReadByte ()
{
DWORD dwRead;
BYTE byIn;
::ReadFile (m_hComPort, &byIn, 1, &dwRead, NULL);
return byIn;
}
etc.
If you don't know when you will have input, then either put the reading in a separate non-UI thread,
or use overlapped IO to read from the com port.
Good luck,
Iain.
|
|
|
|
|
Hello, i have a small problem with saving a bitmap to file.
Well, in WM_PAINT case i have implemented a code that receives a bitmap from clipboard
adds a text there and.. yep and i dont know how to save it into a file.
Please help me with it, i am searching it for 2 weeks and havent found explanation of that problem.
Ohh im not MFC programmer. Pure API.
Regards.
|
|
|
|
|
if you are getting a DIB from the clipboard, all you have to do is fill-in and write a BITMAPFILEHEADER struct, followed immediately by your DIB.
if you're getting an HBITMAP from the clipboard, you'll get to get a DIB from it then follow the steps above. use GetDIBits.
-c
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw
|
|
|
|
|
So there isnt any function that makes it automatically?
I mean something like savetobmp(...)?
Could you please, help me to solve this problem?
|
|
|
|
|
no, there is no such function.
the process i described can be done in less than 10 lines of code, if you have the DIB. it is entirely trivial.
-c
Alcohol is the anesthesia by which we endure the operation of life.
-- George Bernard Shaw
|
|
|
|
|
Yes, but as you said "if i have the DIB". The operation i am doing is:
OpenClipboard(hwnd);
hBitmap = (HBITMAP)GetClipboardData(CF_BITMAP);
Please, help me to write those "10 lines of code".
|
|
|
|
|
|
Big thanks, you really helped me.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
