|
Just a suggestion: Test parameter size, it could be 10.
Or there could be a '\0' character in the file you read.
Oh, and you could also test if afile is actually opened, just in case...
Jan
"It could have been worse, it could have been ME!"
|
|
|
|
|
jan larsen wrote:
there could be a '\0' character in the file you read.
I think this is the reason but how can I solve it?
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
You can't if you're trying to print/treat it as a C style string.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
As Christian is saying in this thread you cant't do anything about it if you want to print the raw char *.
But if the IO task went well then the pointer points to an array of size length and is an image of the data in the file.
If the file data are meant to be binary then you are misusing your pointer when you treat it as a string, i think that is one of the reasons why MS created the BYTE typedef so that you wont get confused.
If on the other hand the data is an array of zero terminated strings, then you could do something like this:
#include "stdio.h"
#include "string.h"
void PrintStrings(char * szString, int size)
{
int i;
char * pTmp;
i = 0;
pTmp = szString;
while (i < size)
{
printf(pTmp);
printf("\n");
i += strlen(pTmp) + 1;
pTmp = &szString[i];
}
}
Jan
"It could have been worse, it could have been ME!"
|
|
|
|
|
Take the address of your CString and enter it the memory window (debug). This will dump all of your memory including null characters, which i assume is causing your problems displaying all your data.
Cheers!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
The first thing that's wrong with it is that it is ugly as all hell. Why on earth are you using malloc and fread when you're using MFC, so you must be using C++ ?
You should use iostreams in C++, you should ALWAYS prefer C++ code to C code unless you have a real reason not to, and NEVER use malloc/free.
Try this:
CFileStatus fs;
CFile::GetStatus("c:\\myfile.ext", fs);
CString s;
s.Format("File length = %d bytes", fs.m_szie);
AfxMessageBox(s);
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
Thanks Christian ,The reason that I used AfxMessageBox and CString is JUST to test my 'char*' for myself not use in my application,I want to use 'char *' in my application and I want it as big as the size of my file,so what should I use instead malloc?
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Every malloced pointer needs to be freed and every newed pointer needs to be deleted. You can't mix them up. new is better because it offers constructors and destructors, so there is good reason to just use new/delete, and thus never get them confused. The fact you're using AfxMessageBox & CString means you've got MFC available, yes ? So use the code I gave you to get the file length, and if you've got some reason to want to create a char* yourself of that size, use new to create it. There's no direct benefit in this case, but there's a benefit as I said in preferring the C++ to the C 'equivelant'. There's more to it, but I'd need to dig up my copy of 'Effective C++' to remind myself of it all.
If you're going to fill a char array with the contents of the file, why not read it into a std::string via an istringstream and an ifstream to read the file ? No messing around with pointers, memory is managed for you, and if you need a char * directly, use c_str() on the std::string to get it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
Christian Graus wrote:
you're going to fill a char array with the contents of the file
Yes,thats exactly what I want to do,and after that I want to change the content of it character by character and write it again to that file.I think I can only do it with FILE structure.(Maybe you can point me to better thing)Can I do that with std::string?.
My C++ is really waek,Does your articles in CP have something about std::string?
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
I thought about it in the shower - don't use std::string, use a vector of unsigned chars instead. I have an article on vector, it's the first of my STL articles.
Basically you want to use an ifstream to read a file, and push the result into a vector. Like this:
This needs you to include fstream, vector, algorithm, iostream and maybe functional. I tacked it on the end of an existing project to test it. Give it the name of a real file, and it will read the file into the vector and then print it out to the console. Ignore the last line and the rest will give you a vector, which you can access with array notation, as in vec[0] = 5, etc. And it does not require you know before hand how big the file is, although knowing and preallocating the space in the vector would be an optimisation, as it stands, no MFC is required, nor do you need to manage any memory.
std::ifstream file("c:\\boot.ini");
std::vector<char> vec;
std::copy(std::istream_iterator<char>(file),std::istream_iterator<char>(), std::back_inserter(vec));
std::copy(vec.begin(), vec.end(), std::ostream_iterator<char>(cout, ""));
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- <b>Jon Hulatt, 22/3/2002</b>
|
|
|
|
|
hmmm,Its a little hard for me,its one of the first STL codes I faced. But I can understand what it is.
I have a question about first line,I retrieve path of files with CFileFind,and it returns CString,How can I pass it to ifstream?
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Well,I think I found it. :
string strfile=finder.GetFilePath();
ifstream file(strfile.c_str());
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Yup - that will do it. If you had a CString, then you'd use GetBuffer & ReleaseBuffer.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
Whether it's the cause of the problem or not, i don't know, but this line is wrong:
CString str1=(CString )(list1);
you can't cast list1, which is a char* to CString.
However, CString has an operator designed for the job:
CString str1 = (LPCSTR) list1;
jon
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
Jon Hulatt wrote:
CString str1 = (LPCSTR) list1;
hmmmm,thanks
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Hi,
I wrote a little tool for our current project here that automatically sends off messages to selected users using NetMessageBufferSend(). It works okay
when I sent off messages from my Win2000 system...every recipient gets the message. What's strange, the tool doesn't work on NT5.0 (SP6) machines -- I always get "NERR_NameNotFound" errors. I tried different ways to convert the relevant strings to UNICODE, but none of these does the trick:
(1)
#define MESGLEN 50000
WCHAR awcToName[MESGLEN*2];
ZeroMemory( awcToName, sizeof(WCHAR)*MESGLEN);
MultiByteToWideChar( CP_ACP, 0, strEmpf, strEmpf.GetLength(), awcToName, MESGLEN);
(2)
wchar_t name[256];
mbstowcs(name,strEmpf,256);
name[256 - 1] = L'\0';
(3)
_towchar(strEmpf) from TConvert.h written by Zoran M.Todorovic
Anyway, launching the usual "net send ..." from a CMD window works on the NT machines, so all required services, etc. seem to be up and running, so I believe it's a string converting problem, although I cannot see where the error might be, since any of the routines (1) - (3) mentioned above work perfectly under W2K.
Any suggestions anyone? I'd really appreciate your help with this.
Thanx in advance
--j
-----------------------------------------
There are three kinds of people:
Those who can count and those who cannot.
|
|
|
|
|
Helo everyone
I'm trying to develop aplication that can capture still images from TV live source.
theese are my inputs...
I'm using DirectShow filters (DirectX 8.1 SDK)
Capture device is
ATI Rage Theater Video Capture chip
My still cap graph contains all needed upstream filters
up to Capture BaseFilter
I rendered preview pin to see Live Preview (works fine), then
I rendered capture pin to get video file (works fine),
I rendered VBI / CC pin (works fine).
Here comes the pain :
I use SampleGrabber filter to get still image
as used in StillCap SDK example.
I add Sample Grabber filter to graph (its connected to capture pin)
and render SampleGrabbers output pin, no errors returned,
but when I try run this still cap graph it returns
"A device atached to system is not funcionating"
Same error ocured in StillCap example, but when I use ATI TV program
It captures still images with no problem.
I've forced this problem for month , so any suggestions are very welcomed.
|
|
|
|
|
There must be a good reason why
operator const E*() const;<code><br />
isn't a member of basic_string. Has there been any discussions regarding this on this message board? I really can't come up with a good example where this might be harmful. Maybe just avoiding implicit type conversion is the stand alone reason? Could anyone give an example why this operator is omitted? I'm sure there is a good reason, just can't figure out why. :confused:
|
|
|
|
|
...or maybe I'm just plain stupid. I can't even get the simple HTML tags right
|
|
|
|
|
The main reason why operator const E*() const was banned out of the standard is simply that too many people were againt them. There's a general suspicion about implicit conversions as the can make call to overload functions ambiguous and make the code less clear (allegedly). But the subject is somewhat controversial, and not everybody agrees with the resolution taken by the standard commitee. The example against operator const E*() const that I find most convincing is this: suppose the conversion operator actually exists, then the following piece of code works just fine:
void f(const char *)
{
...
}
...
string s1="Code";
string s2="Project";
f(s1+s2); But the following snippet will fail, although it seems an innocent version of the former:
string s1="Code";
string s2="Project";
const char *p=s1+s2;
f(p); The reason why this fails is that p is no longer valid because the temporary (s1+s2) according to the standard rules might have been deleted when the call to f comes. Introducing c_str does not prevent this problem, but at least make you think twice about it ((s1+s2).c_str() is an eye-catching sentence, isn't it.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
The main reason why operator const E*() const was banned out of the standard is simply that too many people were againt them
Totally agree with them, but in the beginning I was totally against, until I discovered the reasons for this behaviour. Of course as you pinpoint, there are a quite few people that strongly disagree with this, but after all even the standard cannot please all of us.
Although this guys are cleaver , sometimes they just make nonsense decisions like the vector<bool> specialization returning a proxy object  , of course this is just plain broken and will be fixed in next one, but this is a sample that this guys sometimes doesn't put the necessary thought on some things.Unfortunately even Stroustroup is against the ideia of incorporating in the C++ core proper multithreading support to do properly multithreading programming(and portable too). They could use policies to provide true thread safe capabilities to stl,not a difficult situation to deal with, and they also could provide true thread safe lazy initializion to c++, for instance in the case of the singleton pattern ..., but no, they don't want that ... lazy guys, and they are suprised that the guys on comp.lang.threads don't like them at all !!!
Joaquín M López Muñoz wrote:
(s1+s2).c_str() is an eye-catching sentence, isn't it
Definitely is ...
Cheers,
Joao Vaz
|
|
|
|
|
(Ok, RAMBLE WARNING!!!)
I hope they never introduce thread safety in the core STL objects such as vector. In my experience, my thread safety requirements extend far beyond just a single instance of a map or vector. Thus, having private locking for these objects does little good.
Then again, my opinion on adding every little thing into the standard is well know.
I was thinking about this stuff this morning and realized something.
1. I don't agree with shops that require that you use 100% standard objects. I think that is counter productive. You just can't have one solution that solves all problems. IMHO, as we get more and more specialized with elements we are adding to the standard, this will become more and more evident.
2. I don't agree with the idea that standard equates to portable. I have had enough years implementing standards to know that there is a huge gap between the ideal standard and that implemented standard.
People might not agree with me, but that isn't the point. If you assume these two points to be true, I think is would be easier to understand why I don't want a lot of junk added to the standard. If feel that people can still get the portability they need from well supported and designed initiatives like BOOST. I really don't see what there is to gain by adding it into the standard. If condition variables get added to the standard, MS isn't going to suddenly decide to add a CV primitive to the XP, W2K, NT4, ME, and 9x. They will just use one of the composite implementations. So what do we really gain? A red rubber stamp that says "this is now standard". Beyond that, what are the real tangible benefits?
If a solution is already portable, why does it suddenly become even more portable when it has the stamp of the standard?
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?
|
|
|
|
|
WARNING: LONG RANT HERE TOO
Tim Smith wrote:
I hope they never introduce thread safety in the core STL objects such as vector. In my experience, my thread safety requirements extend far beyond just a single instance of a map or vector. Thus, having private locking for these objects does little good.
Hum, you perhaps misinterpreted what I said, I will try to better explain this:
If you readed Modern C++ Design , the 1st chapter deals with the concept of policy classes, this concept is seemed with the strategy pattern, for instance
the policy class :
template<class ThreadModel = ThreadSafeRead>
class CThreadingModel
{
lock();
...
}
The vector instead of :
template <class Type,class Allocator = allocator<Type>> class Vector;
would be:
template <
class Type,
class Allocator = allocator<Type>
class ThreadModelSafety=CThreadingModel
>
Transparent, by default the normal STL behaviour, explicity full MT semantics or other hybrid thread model
Of course this lead to problems mixing classes with different thread models, but hey this is just a thought , besides it's a normal problem when mixing classes with different strategies ...
Tim Smith wrote:
I don't agree with the idea that standard equates to portable. I have had enough years implementing standards to know that there is a huge gap between the ideal standard and that implemented standard.
Of course is a very difficult task, not impossible ... but even so I liked the threading option to be added to the c++ core, not only the stl .
Tim Smith wrote:
If feel that people can still get the portability they need from well supported and designed initiatives like BOOST
A very nice initiative indeed
Tim Smith wrote:
. If condition variables get added to the standard, MS isn't going to suddenly decide to add a CV primitive to the XP, W2K, NT4, ME, and 9x.
Hey Tim, I'm not talking about CVS here , I known that you're still shaken by the not in the very past long arguments held here at CP 
But I'll warning you after I'm finally conclude my ICMP protocol article with c# , I'll write a article with a portable thread pool implementation, and suprise, it will have CVs, so I'm expect to be badly beaten by you respecting this and the possible quirks that it may have 
Tim Smith wrote:
If a solution is already portable, why does it suddenly become even more portable when it has the stamp of the standard?
Not more portable, only more standard
Cheers,
Joao Vaz
|
|
|
|
|
I strongly disagree with this approach for STL thread safety. It is consistent and would work, but IMHO almost never will suit any programmer's need. Consider for example a for_each operation performed on a std::vector: as for_each only sees the vector thru iterators, this implies that the operation locks and unlocks the vector every time it accesses it. In many occasions one will need that the entire for_each operation is done within a single lock section. Defining appropriate interfaces to achieve this in a generic manner is probably impossible. In more contrived examples, one seeks atomicity for several such operations executed in sequence, and now things become much more complicated than the simpler approach of doing the locking separately. In a nutshell: "atomicity" is too program-specific a concept to be reduced to access-level locking.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
Consider for example a for_each operation performed on a std::vector: as for_each only sees the vector thru iterators, this implies that the operation locks and unlocks the vector every time it accesses it. In many occasions one will need that the entire for_each operation is done within a single lock section
Of course with full mt semantics this will lock every operation, but imagine two threads writing to the same vector, and the vector doesn't care about the order in wich threads write, this will improve concurrency , than serializing all the insertions ...
If you want the transversal of vector to be more quickly, you would define the normal thread safe model that most STL implementations use, so using for_each will increase the speed of the loop.
So when you define your vector you must think carefully if this vector will be used much more times in a read scenario than a write scenario or vice-versa.
You could use also template operator= to convert on the fly the vector with threadmodel MT to be used with the normal Thread Read Safe model(possibly very costly or not advisable at all), or you could use the Adaptor Pattern to adapt the class to a different thread model ...
Cheers,
Joao Vaz
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
