|
if (Promise == Prosise) goto WinAPI;
|
|
|
|
|
little question:
i am using an ifstream and getline like this
while (1)
{
if (!std::getline (file, line1))
break;
}
well.. this works very well.. but some of the textfiles i'm reading don't have got CR+LF in their last line.. means that this call returns false.. and that i am missing the last line.
can somebody explain me how to do this correctly or a workaround?
Sometimes I think the surest sign for intelligent life elsewhere in
the universe is that none of them ever tried to contact us.
|
|
|
|
|
I'm not able to reproduce your problem. This tiny program
#include <string>
#include <fstream>
#include <iostream>
using namespace std;
int main()
{
ifstream in("test.txt");
for( ; ; ){
string str;
if(!getline(in,str))break;
cout<<str<<"LF"<<endl;
}
return 0;
} emits the same output no matter whether the last line of test.txt is CR+LF terminated or not.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
yeah.. it really works.. so i've cut out the original code.. cause it is a little bit more complex.. but i thought i cut it down to the "root of its evil"
while (1)
{
if (!std::getline (file, line1))
break;
std::streampos here = file.tellg();
std::getline (file, line2);
file.seekg (here);
....
}
well.. the code is something like 2 steps forward, one step back.. i use this because i need the context of every single line in the text file..
it works perfectly for text files where the last line is terminated with CR+LF, but if the file is not terminated with CR+LF it breaks when reading this line.. and not when the EOF is reached..
thanks in advance
bernhard
Sometimes I think the surest sign for intelligent life elsewhere in
the universe is that none of them ever tried to contact us.
|
|
|
|
|
This patch seems to fix the thing
while (1)
{
if (!std::getline (file, line1))
break;
std::streampos here = file.tellg();
std::getline (file, line2);
<font color=#ff0000>file.clear();</font>
file.seekg (here);
....
} But my impression is that the code should work without the patch... maybe it's an STL bug. I'll do some more investigation later.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
well.. i hardly can believe this (this problem is hanging around in my head since three month..)
it is not an a+ project..
AND NOW IT FINALLY WORKS.. THANK YOU !
really great...
bernhard
Sometimes I think the surest sign for intelligent life elsewhere in
the universe is that none of them ever tried to contact us.
|
|
|
|
|
enclosed an article of Microsoft, source of this statement:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q240015
Krz
FIX: getline Template Function Reads Extra Character (Q240015)
-------------------------------------------------------------------------
The information in this article applies to:
The Standard C++ Library, used with:
Microsoft Visual C++, 32-bit Enterprise Edition, version 6.0
Microsoft Visual C++, 32-bit Professional Edition, version 6.0
Microsoft Visual C++, 32-bit Learning Edition, version 6.0
-------------------------------------------------------------------------
SYMPTOMS
The Standard C++ Library template getline function reads an extra character after encountering the delimiter. Please refer to the sample program in the More Information section for details.
RESOLUTION
Modify the getline member function, which can be found in the following system header file string, as follows:
else if (_Tr::eq((_E)_C, _D))
{_Chg = true;
// _I.rdbuf()->snextc(); /* Remove this line and add the line below.*/
_I.rdbuf()->sbumpc();
break; }
NOTE : Because the resolution involves modifying a system header file, extreme care should be taken to ensure that nothing else is changed in the header file. Microsoft is not responsible for any problems resulting from unwanted changes to the system header files.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.
This problem was corrected in Microsoft Visual C++ .NET.
MORE INFORMATION
The following sample program demonstrates the bug:
//test.cpp
//Compiler options : /GX
#include <string>
#include <iostream>
int main () {
std::string s,s2;
std::getline(std::cin,s);
std::getline(std::cin,s2);
std::cout << s <<'\t'<< s2 << std::endl;
return 0;
}
Actual Results:
Hello<enter key="">
World<enter key="">
<enter key="">
Hello World
Expected Results:
Hello<enter key="">
World<enter key="">
Hello World
-------------------------------------------------------------------------
Published Sep 16 1999 12:33PM Issue Type kbbug
Last Modifed Feb 11 2002 7:06PM Additional Query Words STL
Keywords kbtemplate kbLangCPP kbSTL kbVC kbVC600 kbVC600bug kbNoUpdate
|
|
|
|
|
Hello All,
How do I create a color ramp from two ranges of colors? some of 2 by 2 matrix. Anyone with a suitable algorithm?
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan.
|
|
|
|
|
A 2x2 matrix requires you decide to ignore red, green or blue. Better you convert to HLS and then ignore one of those. Anyhow, once you decide which value to keep constant, just build a range between the two value sets you want to work with.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
Thanks.
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan.
|
|
|
|
|
My memory has failed me badly and the code from when I did this last time was lost in a major disaster.
If I have an Bitmap drawn on a MemDC what is the fast way to put it in a CBitmap object which is then to be added to a CImageList.
I have searched the site and not found the answer.
Happy programming!!
|
|
|
|
|
Build a BITMAP from CDC::GetCurrentBitmap, use that to create a new CBitmap, put it into a CDC and BitBlt. I think if you grab GetCurrentBitmap, you'll have troubles as the DC owns it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
If you create a simple microsoft Win32 DLL function, it creates an entry point file plus the stdafx files which contain the windows.h include file.
However, if you start adding header and cpp files which make reference to stuff like CRecordSet and have references to stuff like afxdb, then Windows.h and afxdb.h get in one another's way.
Then, if you comment out the windows.h and use afxdb.h, you get an error as following:
Linking...
nafxcwd.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in test2.obj
Debug/test2.dll : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
And if you comment out the DLLMain at this point, everything compiles well.
Why does this happen? Can I not have a DLL with a DLLMain which also uses afxdb.h? How do I go about fixing this problem?
thanks
|
|
|
|
|
First, remove the windows.h include, and change it to afxwin.h.
Second, regular MFC DLLs are made completely differently from plain Win32 DLLs. You need a global CWinApp object, and MFC provides the DllMain().
--Mike--
Fetchez la vache!
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan and Jamie Salé.
|
|
|
|
|
Hmmm.
Look at this code snippet :-
STDMETHODIMP CNishFirst::GetArray(BSTR **pbstrArray)
{
// TODO: Add your implementation code here
USES_CONVERSION;
BSTR *tmpArray[25];
for(int i=0;i<25;i++)
*tmpArray[i]=SysAllocString(A2W("Nish Test"));
*pbstrArray=*tmpArray;
return S_OK;
}
You'd think it was fine [ignoring that amazing warning I got which I had reported in the previous thread]
But when I tried to test the function using VB I got an error saying that I was attempting to use an OLE Automation feature not supported by VB!
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Aaah, you're going to love this, Nish.
To pass arrays in Automation, you're going to have to use the dreaded... SAFEARRAY. The old C-style array is not supported. Have fun with SAFEARRAY (I know I do!)
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Derek Waters wrote:
Aaah, you're going to love this, Nish.
I hope so too
Derek Waters wrote:
To pass arrays in Automation, you're going to have to use the dreaded... SAFEARRAY. The old C-style array is not supported. Have fun with SAFEARRAY (I know I do!)
Hmmm. Safe Arrays!!!
Nish
p.s. This ATL stuff is deeper than I imagined even though I had imagined it to be pretty deep, so you can guess how deep it really is.
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
interface INishFirst : IDispatch
{
[id(1), helpstring("method GetString")] HRESULT GetString([in] BSTR* pbstrInString, [out,retval] BSTR* pbstrOutString);
[id(2), helpstring("method GetArray")] HRESULT GetArray([out,retval] BSTR** pbstrArray);
};
It's showing an error :-
warning MIDL2039 : interface does not conform to [oleautomation] attribute : [ Parameter 'pbstrArray' of Procedure 'GetArray' ( Interface 'INishFirst' ) ]
Am I not allowed to have BSTR **s????
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
BSTR is already a pointer. So BSTR** is a "triple pointer" (omg! ), which of course is not supported by automation.
From MSDN:
typedef OLECHAR FAR* BSTR;
|
|
|
|
|
You can have BSTR **, so long as you don't want your COM object to be Automation-compatible (ie usable in ASP). The Automation type standard is quite strict on this sort of thing.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
I might want to add:
- use BSTR for your [in] param
- use BSTR* for your [out] param
Edit: fixed the little bug in my 2nd statement
|
|
|
|
|
|
Derek Waters wrote:
You can have BSTR **, so long as you don't want your COM object to be Automation-compatible (ie usable in ASP). The Automation type standard is quite strict on this sort of thing.
Thanks again Derek. I jus found that out
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Nish [BusterBoy] wrote:
I was just advised to use BSTR* as my out parameters
I meant to say that actually, must be smoking crack...
Sorry for the confusion
|
|
|
|
|
Just some more information...
The OLE Automation restriction is there for a reason. The idea is that if an interface supports OLE automation no external proxy code is required to marshal the calls.
I leave it to the reader to translated what I just said into English. I know for the longest time I had NO CLUE what any of that ment. (Heh, and I hope I got the statement right.)
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|