C / C++ / MFC Discussion Boards

Zac Howland12-Jun-06 6:32

12-Jun-06 6:32

If you are reading in character buffers as a whole, yes, you will have a problem. If you are using them as C-style strings, then no, you won't. The reasoning is that C-style strings have a null-terminator.

Example:

const unsigned int ARRAY_SIZE = 20;<br />
char myBuffer[ARRAY_SIZE] = {0};<br />
<br />
// Right now, the entire buffer is 0's<br />
strcpy(myBuffer, "My funny String");<br />
<br />
cout << myBuffer << endl;<br />
cout << strlen(myBuffer) << endl;<br />
// Output will be:<br />
// My funny String<br />
// 15<br />
<br />
// Now, replace the buffer<br />
strcpy(myBuffer, "Hello");<br />
<br />
cout << myBuffer << endl;<br />
cout << strlen(myBuffer) << endl;<br />
// Output will be:<br />
// Hello<br />
// 5

The only time you would run into problems doing this is when you will be looking at the entire character buffer (so all 20 characters) for information. However, in that case, you most likely will not be treating the buffer as a string, and will not be using the strXXX family of functions on it either (or their _tsc equivalents).

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: array of char-newbie

James R. Twine12-Jun-06 6:53

James R. Twine

12-Jun-06 6:53

The standard string-handling functions like strcpy(...), strcat(...), sprintf(...), etc. will write a terminating NUL (not a NULL[^]) into the buffer you are using.

So if you use them, you normally do not have to worry about previous data causing issues (unless you are concerned about security, but that is another issue). Here is an example:

char caBuffer[ 50 ];
 
strcpy( caBuffer, "A Looooooooong String" );
strcpy( caBuffer, "A Short String" );
puts( caBuffer );

After the first call to strcpy(..) the buffer will contain (NUL is represented by Ø):

0123456789012345678901</CODE>
<CODE>----------------------</CODE>
A Looooooooong String<CODE>Ø

-and after the second call to strcpy(...), the buffer will likely contain:

0123456789012345678901</CODE>
<CODE>----------------------</CODE>
A Short String<CODE>Ø</CODE>String<CODE>Ø

When the string is shown using puts(...), it will display A Short String, even though the actual memory for the buffer has the extra data in it. Since string-handling functions use NUL as an end-of-string indicator, puts(...) stops when it gets to the first NUL it encounters.

Peace!

-=- James

If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)

Re: array of char-newbie

jhwurmbach21-Jun-06 22:01

jhwurmbach

21-Jun-06 22:01

James R. Twine wrote:
write a terminating NUL (not a NULL[^])

You really got a obsession there, right?
Big Grin | :-D

"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."

-- Caius Petronius, Roman Consul, 66 A.D.

Re: array of char-newbie

James R. Twine21-Jun-06 23:48

James R. Twine

21-Jun-06 23:48

jhwurmbach wrote:
You really got a obsession there, right?

Yup! It is what separates the wheat from the chaff... Smile | :)

Peace!

-=- James

Re: array of char-newbie

Nish Nishant12-Jun-06 8:50

Nish Nishant

12-Jun-06 8:50

Why is Zac's answer low-voted? It was an accurate answer, wasn't it? Confused | :confused:

Regards,
Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications.
Also visit the Ultimate Toolbox blog (New)

Re: array of char-newbie

Zac Howland12-Jun-06 10:41

Zac Howland

12-Jun-06 10:41

Nishant Sivakumar wrote:
Why is Zac's answer low-voted? It was an accurate answer, wasn't it?

Yes, it is accurate. Some people get hung up on the terminology (actually, just the spelling) of NUL vs NULL. In my opinion, as long as you know that you are talking about putting a 0 somewhere, it doesn't matter whether you call it a "nul-terminator" or a "null-terminator".

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: array of char-newbie

James R. Twine13-Jun-06 3:17

James R. Twine

13-Jun-06 3:17

   Personally, I did not vote you down. Since you have no idea that I did or not, I have to guess that the mentioning my NUL vs. NULL point is but a coincidence - otherwise it would be a highly inappropriate assumption on your part. Also, you will note that even if I did vote you down, there are 4 other votes there as well. Did it ever occur to you that perhaps others know something that you do not? (And that just because you do not know what someone else is talking about, that does not mean that they do not?)

   For the record, I voted your two earlier posts a 4. The fact that the first is now below that value may be indicative of something else.

   NUL is one thing, NULL (in uppercase) is another. They are not two ways to spell the same thing, even though they have the same value. NUL is the name/mnemonic for an ASCII encoded character with a value of zero. BS, ACK, and NAK are similar characters. I am sure you (should?) know the history of NULL, even in C.

   Consider this - my calling "C++" something else, like "G--; that C-ish language with the objects, and references, and virtual thingys" is not correct, even if I know that I am really talking about.

   Peace!

-=- James

Re: array of char-newbie

Nish Nishant13-Jun-06 8:49

Nish Nishant

13-Jun-06 8:49

Raymond Chen says null-terminated string here :-

http://blogs.msdn.com/oldnewthing/archive/2004/08/24/219444.aspx[^]

Most of MSDN documentation says null-terminated string too.

Maybe that's why people use that (null I mean) more often.

Regards,
Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications.
Also visit the Ultimate Toolbox blog (New)

Re: array of char-newbie

James R. Twine13-Jun-06 15:39

James R. Twine

13-Jun-06 15:39

Yep - lots of people also do not come to a complete stop at a stop sign, and still manage to get someplace in one piece. Smile | :)

And you should know by now that you should never use or site Microsoft as a model for anything software-related! :P :P :P

Peace!

-=- James

Re: array of char-newbie

Zac Howland13-Jun-06 12:19

Zac Howland

13-Jun-06 12:19

I wasn't referring to you personally. I actually hadn't even read your response yet when I posted that.

On similar topics in the past (not necessarily on this forum, but others), I've been flamed for the nul vs null argument. My point is that as long as the reader understands what you are saying, it doesn't matter how you spell it.

And yes, I'm well aware of the history of ASCII characters ... use to have to use them all the time in my last job (ACK/NAK especially).

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: array of char-newbie

antonaras12-Jun-06 21:39

antonaras

12-Jun-06 21:39

Personally i found the answer of Zac very accurate and helpful

Re: array of char-newbie

James R. Twine13-Jun-06 3:18

James R. Twine

13-Jun-06 3:18

It was mostly accurate, Nish... :P

Peace!

-=- James

General question linking Fortran to C/C++ using MFC

deltaseq012-Jun-06 4:56

deltaseq0

12-Jun-06 4:56

I’ve been working up the learning curve trying to link F77 functions and subroutines to C/C++ (Pentium, XP, VC++6). I got stuff to work using MinGW’s f77, gcc and g++ compilers in console mode. So now I’m trying to switch to a dialog GUI. I would like to use MFC.

When I got to compiling the .rc file (using windres in MinGW), I started to run into problems. I see that MinGW supports WIN32 API but my suspicion is that it does not work with MFC. Not much on the subject on the net that I was able to find so I would appreciate any perils you(‘ll) can give up.

Just a beginner so please reply in a Newbie dialect of English if you don’t mind.

Thanks,
Mike

Re: General question linking Fortran to C/C++ using MFC

Zac Howland12-Jun-06 5:33

Zac Howland

12-Jun-06 5:33

Do you have Visual Studio (or just Visual C++) installed? My guess is that you probably don't have the MFC headers and libraries (assuming you don't have them installed).

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: General question linking Fortran to C/C++ using MFC

deltaseq012-Jun-06 6:29

deltaseq0

12-Jun-06 6:29

I have Visual Studio 6 SP6 installed and use the VC++6 IDE. I have made MFC apps that run using the VC++ compiler. It is when I try to compile a source (or resource)created using MFC with MinGW compilers that I get into trouble.

I have just come across some snippets that indicate that I will not be able to compile MFC source with MinGW compilers since, for one thing, MFC is copyrighted. I'll try again with a Win32 Application project. If that fails, I'll look into some other IDE supporting Win32 API.

OK?

Re: General question linking Fortran to C/C++ using MFC

C^hris L^osinger12-Jun-06 6:36

C^hris L^osinger

12-Jun-06 6:36

deltaseq0 wrote:
for one thing, MFC is copyrighted

what does that have to do with anything?

Cleek | Image Toolkits | Thumbnail maker

Re: General question linking Fortran to C/C++ using MFC

Zac Howland12-Jun-06 6:40

Zac Howland

12-Jun-06 6:40

It isn't so much that it is copyrighted as it is that the source code isn't completely available and you are trying to complile on a different compiler. If you are already using VC, I'm not sure why you would want to go to MinGW ...

In any case, all MFC really is, is a set of thin wrappers around Win32 API's and objects. That is, if you know what parts of MFC you would be using, you could fairly easily make your own wrapper classes that do the same thing.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: General question linking Fortran to C/C++ using MFC

deltaseq012-Jun-06 7:39

deltaseq0

12-Jun-06 7:39

From some of the MinGW sites:
“
The MinGW basic runtime system, which is basically the glue to the underlying operating system, is completely in the public domain. The runtime system includes MinGW headers (such as stdio.h), libraries (such as libmingw32.a) and import libraries for CRTDLL/MSVCRT.

W32API, which consists of the headers and import libraries related to WIN32 API access, is released under copyright . The copyright agreement states no restrictions are placed on programs or object files compiled with the library.

Mingw provides access to the Win32 API. Theoretically, if you own the MFC source code you could build MFC libraries for Mingw. No one's tried this so far. If anyone does successfully accomplish it, please say so and it will be added to this document…
“

MinGW is the common denominator to link Fortran to C/C++. From what I’ve seen, Cygwin can be used on windows machines as well.
For example:
g77 -c test.f 2
g++ -o test test.cpp test.o
g77 will compile and assemble the Fortran source file test.f into the object file test.o
g++ will compile and assemble the C++ source test.cpp and link it to the Fortran object file test.o and create the test.exe executable. I haven’t come across how this can be done with VC++. To the contrary, not being able to do this sort of thing is one of the driving forces behind multi language compiler utilities such as MinGW.

::~AFX_MAINTAIN_STATE2 already defined

simwall12-Jun-06 4:49

simwall

12-Jun-06 4:49

I have an MMC snap-in project which compiles in VS2003. After converting to VS2005, I get a linker error:
uafxcwd.lib(afxinl2.obj) : error LNK2005: "public: __thiscall AFX_MAINTAIN_STATE2::~AFX_MAINTAIN_STATE2(void)" (??1AFX_MAINTAIN_STATE2@@QAE@XZ) already defined in mmc.lib(apimfc.obj).
It happens with Unicode and non-Unicode builds.
It happens only in debug builds.
Any ideas?

Re: ::~AFX_MAINTAIN_STATE2 already defined

Viorel.12-Jun-06 4:57

Viorel.

12-Jun-06 4:57

I think you should first compare the linker’s settings for Debug and Release modes, esp. the Additional Dependencies value in Linker --> Input page.

Then check if the the C/C++ --> Code Generation --> Runtime Library values are appropriate.

File creation date

LCI12-Jun-06 4:12

LCI

12-Jun-06 4:12

How do i get the creation date of a file?
So before i read a file, how can obtain the creation date of that file?

Re: File creation date

_AnsHUMAN_ 12-Jun-06 4:22

_AnsHUMAN_

12-Jun-06 4:22

CFile myfile(/* code to open the file*/);<br />
myfile.GetStatus()<br />

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

Re: File creation date

Viorel.12-Jun-06 4:29

Viorel.

12-Jun-06 4:29

In case of Windows API, use GetFileTime.

In case of MFC, use CFile::GetStatus.

In case of run-time C++ libraries, use fstat, perhaps combined with fileno.

Re: File creation date

Hamid_RT12-Jun-06 6:46

Hamid_RT

12-Jun-06 6:46

and see here

<br />
	WIN32_FIND_DATA lp;<br />
	FILETIME		Time;<br />
	SYSTEMTIME		stSystem;<br />
<br />
HANDLE handle=FindFirstFile(filename,&lp);<br />
FileTimeToLocalFileTime(&lp.ftCreationTime,&Time);<br />
FileTimeToSystemTime(&Time,&stSystem);<br />
<br />
stSystem.wDay, stSystem.wMonth, stSystem.wYear<br />
FindClose(handle);<br />

whitesky

Re: File creation date

LCI12-Jun-06 7:32

LCI

12-Jun-06 7:32

Can i compare entire filetimes.. SO for example...
Can i check to see if stSystem > some other date? Make a comparison that is.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.