|
The following code should read a text file and update Sentences (defined as std::list<string> Sentences).
However, fstream does not seem to like 'string' types. Is it possible to retain string types and convert it to char?
bool CSentenceList::readFile(const string strFileToRead)
{
string strLine;
fstream fileToRead((char*) strFileToRead,ios::in);
if (ios::good != false)
{while (!fileToRead.eof() && Size < MAX_LINES)
// Read line of text from file and update Sentences.strSentence.
{ fileToRead.getline(strLine, MAX_SENTENCE_LENGTH);
Sentences.push_back(strLine);
Size++;
}
return true;
}
else
{ throw "File cannot be read!";
return false;
}
fileToRead.close();
}
Errors:
SentenceList.cpp(23): error C2440: 'type cast' : cannot convert from 'const std::string' to 'char *'
SentenceList.cpp(28): error C2664: 'std::basic_istream<_Elem,_Traits>::_Myt &std::basic_istream<_Elem,_Traits>::getline(_Elem *,std::streamsize)' : cannot convert parameter 1 from 'std::string' to 'char *'
with
[
_Elem=char,
_Traits=std::char_traits<char>
]
Are there other objects I can use so I can read text files from 'string' types, since they are less prehistoric?
Jon
|
|
|
|
|
First, about std::string, if you want a char*, you should use the c_str() function,
other methods are not safe.
But this is not relevant to your problem. You should take a look at streams.
You'd create an istream, from your file, and then do things like
istream >> strline;
|
|
|
|
|
A precision to my former post.
the istream I was refering to was a stringstream, as you mentionned you were looking
for less prehistoric methods, I think streams provide nice high level objects, but you'd
need to do some readings on the topic.
For a quick fix to your code, you could do something like:
string strLine(MAX_SENTENCE_LENGTH, ' ');
This creates a string with the right size. To read directly into the string buffer,
you can acces it with &(*(strLine.begin())), this gives you a pointer to the internal
buffer.
|
|
|
|
|
OK, where do we start? The constructor for the fstream class does not take a string class, it needs a const char*, easy to fix, call the c_str() member of strFileToRead. That should get your file open. Next you are tring to read the line directly into a string class, this is not possible with the istream class. You must allocate a buffer of type char and read into that, then assign that buffer to the string class.
|
|
|
|
|
|
(Hope this is not seen as off-topic ! Apologies, if so !) Can anyone point me to an article which describes the generic actions that take place when the drivers for a hardware device get installed in a Windows system ? Is there any API which supports any of these actions ? Thanks !
Doug
|
|
|
|
|
First, you can start with information in the Windows Driver Kit[^]. You'll also need information on the Setup API[^], which handles the INF files used to install drivers.
Unfortunately, the device driver group within Microsoft is a bit of their own private kingdom. Their development tools and documentation aren't nearly up to the standards of the rest of the company. The best approach to handling device driver installation is to adapt their examples until you have something that installs your driver.
Software Zen: delete this;
|
|
|
|
|
Thanks Gary - very useful pointers ! (didn't know about the Setup API which will help enormously - I hope !!)
Doug
|
|
|
|
|
And here we go with another problem. I am declaring a constant string within my code, wrapping it with the _T() macro. In a unicode build this translates to the L prefix. The problem I am having is, my string is actually a multibyte pathname, there are Chinese characters within the string. I am trying to use this string within a function but having problems. With an MBCS build, the string length is 60, but in UNICODE the length is 64. Any ideas?
|
|
|
|
|
In MBCS strings each Chinese character takes two chars, but in wide char strings, each Chinese character only takes one wide char. That will cause the difference in string length.
|
|
|
|
|
In MBCS a Chinese character takes 2 bytes, in UNICODE it also takes 2 bytes. My question is, why does the 'L' macro not map the string correctly. Instead of leaving the Chinese caracters as they are it is breaking them up further, giving each character 4 bytes. How can I overcome this without passing the string through a MultiByteToWideChar() function? I'm sure this does not only apply to Chinese characters, it must be the same with any unicode character enetered into a litteral string.
|
|
|
|
|
I think you cannot escape the call to MultiByteToWideChar. Actually even two, one
for getting the buffer size, and one for filling the buffer.
|
|
|
|
|
Yeah, I figured. I decided to use the ATL macros. But look at this snippet, I can't work it out.
USES_CONVERSION;
length *= 2;
char *text = new char [length+1];
memset(text,0,length+1);
WideCharToMultiByte(936,0,(unsigned short *)data,length/2,text,length+1,NULL,NULL);
strings[_added_strings] = new String( A2T(text) );
_added_strings++;
delete[] text;
data += length;
Basically, I am reading from a byte array which contains UTF16 text. Here I am converting it to multibyte, but for a unicode build I want to leave it as it is. Problem is, if I turn that text into a wchar_t and memcpy the bytes over, I get no text. The only way I can do it is to first convert to multibyte, then convert it back to wide.
|
|
|
|
|
IMO, the difference in length should be related to the string representation.
I would guess the unicode string starts with the length of the string. So
with a simple memcpy you might incorrectly copy the string.
|
|
|
|
|
L"" is not a macro, it's simply a means of indicating a unicode string literal. ie. whatever is within it has to be a valid unicode string. If you're specifying a MBCS string literal then it's within your unicode build that you have to do the conversion from MBCS (specifying the codepage the string is in) to unicode.
You should also consider what happens if for the MBCS build, the user is not running with the codepage that the MBCS string is in. (MBCS strings are all codepage specific). So what happens then? Converting your MBCS string to unicode and then back to the user's current codepage would probably fail (being unable to do the mappings), and using that MBCS string ignoring the user's current codepage is very wrong and might represent invalid file path characters on that user's codepage.
If you are using VC7 and up, you should use the new ATL conversion classes[^]instead though there are some differences.
|
|
|
|
|
The behaviour will depend on the codepage that the compiler uses to read the source file, which is the user's default codepage - for a Western developer, that will normally be Windows-1252. Newer versions of the compilers I think can recognise the Byte Order Mark to handle UTF-16 or UTF-8 source code files (the BOM is the character U+FEFF, so if the file begins with the bytes 0xFF 0xFE, it's likely to be a UTF-16 little-endian file, while if it starts 0xEF 0xBB 0xBF, it's probably a UTF-8 file).
In VS2003 and 2005, you can go to File, Advanced Save Options and specify the encoding to use for a given source file.
You may get best results using either a UTF-8 or UTF-16 source file, if your environment supports it, or using the hex escapes to explicitly specify the characters. I'm not sure if Visual C++ supports the '\u' syntax for specifying Unicode characters directly - I don't think it does.
Note that any Latin characters in your MBCS string will be encoded using one byte, not two: indeed, any character coloured white on, for example, this reference chart[^] (Simplified Chinese CP936).
Finally, you're not explicitly encoding the translation of 'Program Files', are you? There are many locations that you can, and should, discover the localized path for using the SHGetSpecialFolderPath API.
|
|
|
|
|
The file I am reading is a standard Biff8 excel file, going by the docs for the file format I am reading it the correct way. As it happens I don't need to worry to much about dealing with multibyte characters, I live and work in China so I am surrounded by them on a daily basis. My problem is with unicode, utf-7 utf-8 utf-16, little endian, big endian, where does it end?
Usually all my builds are MBCS to be compatible with win95 systems (don't ask), but lately I have begun to realise the importance of unicode. So it looks like I am going to have to start learning all over again.
|
|
|
|
|
#ifdef UNICODE
LPCWSTR str = L"\x4f60\x597d";
#else
LPCSTR str = "\x81\xf1\x8f\x11";
#endif You can't do it with one literal because the contents of the literal have to match the character set that you're compiling for.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
So it's probably better to store all string literals in a string table, that way LoadString() can handle the mess. But saying that, the string table is converted to unicode, so won't the same thing happen?
|
|
|
|
|
No, because when you call LoadStringA(), the OS will convert the string to MBCS for you. (All ANSI APIs on NT work this way.)
|
|
|
|
|
I'm trying to create a structure which implements a linked list of strings, which should include the following functions:
* sort in alphabetic order
* search for a word
* read
* insert
* delete item (top / bottom / random point if possible)
* clear list
In order to create the linked list from scratch I was planning to use std::list structure to implement a linked list:
#include <list>
#include <string.h>
using std::list;
void main ()
{
String strName("Joe");
list<strName> li;
li.push_back("joe");
}
This code is 'garbage' as in it doesn't compile, however, I would appreciate for ideas on these lines.
Jon
|
|
|
|
|
when you declare the list variable you have to put the type inside the <>'s not the variable name. also you could probably just use the STL string class.
#include <list><br />
#include <string><br />
<br />
using std::list;<br />
using std::string;<br />
<br />
void main()<br />
{<br />
string strName("Joe");<br />
<br />
list<string> li;<br />
<br />
li.push_back(strName);<br />
}
I think you're just confusing the variable type and the actual variable in your code. When you declare a list, the stuff in the <>'s (template arguments) are telling the list what type of variable you want it to hold. Then you can add variables of that type to the list.
-- modified at 11:45 Saturday 26th August, 2006
|
|
|
|
|
|
jon_80 wrote: ...I was planning to use std::list structure to implement a linked list:
Why? std::list is already a (doubly) linked-list data structure.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I am going through some of my old code making it more unicode friendly, basically adding TCHAR instead of char, when I came across the _fcvt() function. Now most stl string functions have their ansi/unicode equivlents, but it appears this one does not, it only returns a char*. Does anybody know of a similar function that will do the job?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
