📄 wpw_tool_vcpp_95.html
字号:
<HTML>
<HR><A NAME=TOOL_MSVC_LINK_BC>
Return to <a href="#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Link code from Borland 4.x with MS C++</H4><PRE>
In article <3ri4lm$6ln@imp.demon.co.uk> Howard Robinson <robinson@legal-es.demon.co.uk> writes:
>Hi all,
>i'm running into problems linking a library compiled under NT
>with the MS C++ compiler with some object files compiled with
>Borland C++ 4.x?
>Is this doable? Do any of the "gurus" know the details behind
>MSC and Borland obj formats?
>
>Thanks for your help,
>-Howard Robinson-
>robinson@legal-es.demon.co.uk
>
>PS, any pointers to faq's discussing these issues would be much
>appreciated.
Borland use the omf obj format versus the coff format used by
Microsoft. MSVC++ comes with editbin which will allow you
to convert from omf to coff.
-Frank
fhkim@cs.washington.edu
</PRE>
<HR><A NAME=TOOL_MSVC_DOS_APPS>
Return to <a href="#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Develop DOS Apps</H4><PRE>
jimp@congnos.com (Jim Patterson) said:
>Visual C++ 2.0 won't support "DOS extenders" of the kind that Watcom supports.
>However, do you really need it to run on "plain DOS" (i.e. outside of Windows),
>or just in a DOS-like command shell?
Actually, this isn't true. Visual C++ 2.0 supports at least one dos
extender I know of TNT. I wouldn't necessarily endorse TNT, but
it does generally run under Win 95.
>If you simply need a command-line program, and are satisfied with
>running it either in Windows 95 or in Windows NT, then a 32-bit Console
>Application will do what you want. You can build that with Visuall C++
>2.x or any other compiler that supports Win32. You can't run it from
>plain DOS or from Windows 3.1, however (even with Win32s).
True, the question is "Why do you want to run a DOS extender under win95?".
In general there is no need to, the console mode api is probably a better
solution in most cases.
glenn sills
Glenn Sills <sills@sills.mv.com> wrote:
>jimp@congnos.com (Jim Patterson) said:
>>Visual C++ 2.0 won't support "DOS extenders" of the kind that Watcom supports.
>>However, do you really need it to run on "plain DOS" (i.e. outside of Windows),
>>or just in a DOS-like command shell?
>
>Actually, this isn't true. Visual C++ 2.0 supports at least one dos
>extender I know of TNT. I wouldn't necessarily endorse TNT, but
>it does generally run under Win 95.
I'm sure console applications are great for those who want them,
however some of our clients specify DOS.
It sounds as if we have the choice of maintaining the DOS version
on a different tool (watcom), including the hassle of maintaining
short file names in a code base that is historically long filename,
or experimenting with an unknown dos extender.
Any experiences/information with/about "TNT" will be appreciated!
Thanks to all the mail and newsgroup replies!
-----------------------------------------------------------------------
(This is a private post, not my employer's. Standard disclaimers apply)
-----------------------------------------------------------------------
Avinoam Shmueli (mailto:shmueli@cs.umass.edu)
</PRE>
<HR><A NAME=TOOL_MSVC_DEBUG_CONSOLE_APPS>
Return to <a href="#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Debug Console app</H4><PRE>
rowen@ingr.com (B Owen) wrote:
>Well, you did so good with that one, can you try one more??
>MSVC++ debugger with a service?? I want to run the debugger with
>my service app to be sure my code logic is proper(at least once before
>saying "it works"). Have you ever tried to attach the debugger to a
>running service OR better yet, put a DebugBreak() statement to generate
>an exception so the just-in-time debugging process kicks in. All I
>get is a "Access Denied" in C++ when the debugger tries to start. I've
>tried both logging the service on as system account and my local account
>with the same results. It works on other processes, just not services.
>Thanks in advance
>Barry
PMFJI, but you can run your app under a debugger by simply running it
as a non-console app. In other words, run your app as a regular
windowed or console app while debugging, then when its ready to go,
register the EXE as a service and you're ready to go. When run as a
service, any windows or console output your program produces just
magically doesn't show up any more. If you need to go back and debug
again, just run against the EXE instead of starting the service.
Bruce
</PRE>
<HR><A NAME=TOOL_MSVC_COUT_PRINTF>
Return to <a href="wpw_tool_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Mixing cout with printf in VC++</H4><PRE>
easchwei@unity.ncsu.edu (Eric) writes:
>In article <3ru5i2$j2o@news.csus.edu>,
>PATRICK MASAO HORIO <pat@orion.sfsu.edu> wrote:
>>
>>When I compile and run a program which has a mixture of cout and
>>printf statements, all of the printf statements get executed first
>>and all of the couts get executed last regardless of what order their
>>in!
>You shouldn't mix printf and cout. Choose one and stick with it.
>You might want to check out "endl" and "flush" in your C++ libraries.
That isn't quite right.
The problem is that in most implementations, C stdio and C++ iostreams
are completely independent, particularly the buffering. Anything
you write to stdout is saved up until its buffer is full, and
anything you write to cout is saved up intil its buffer is full.
If you really need to write to both stdout and cout in the same program,
you can first (before any output) invoke the static member function
ios::sync_with_stdio();
That will cause any output to cout to first flush stdout, and then
flush cout. If you have lots of output to cout, that will really
slow things down. It is better to use either cout or stdout, but
not both in the same program (and the same with cin/stdin).
BTW, ios::sync_with_stdio() applies only to the standard input
and output streams (stdin/cin, stdout/cout, stderr/cerr),
and not to any other files.
There is no problem at all with using both stdio and iostreams in
the same program, and long as you use just one or the other on any
given file.
The C++ draft standard requires that stdio and iostreams work together
without your taking any special precautions. That in turn means
that the C and C++ library implementations must be integrated, so
it may be a while before all implementations catch up to this
requirement. I believe g++ works this way already.
--
Steve Clamage, stephen.clamage@eng.sun.com
<HR>
Yes Indeed,
A coworker of mine had just run into the same thing while trying dive
deep ino the C++ learning abyss!!! The C++ guru's (one of which I aspire
to be) all scratched their heads for about 15 seconds and came to the same
obvious conclusion. (I asume you are learning Microsoft Visual C++
because the example leads you to this!!) The printf function is
relatively low level. (compiler dependant) It flushes the output buffer
(or writes directly to hardware) immediately. The Cout archive (a high
level object, with the wonderfully overiden << operator) has a buffering
scheme that either writes IO when the 'out' buffer is full or when you
manually flush it, or when the program terminates. (the situation you are
seeing.) Therefore you will see printf's print before the 'cout <<'
unless you have alot of 'cout<<' lines. There is a manual flush funtion
in the IO class ( I forgot the function or even the class name) dig
around in the online help. If you ae using MSVC++ the online help is
invaluable!!!
Jim H.
<HR>
According to Jumblo <jumblo@aol.com>:
> The printf function is
^^^^^^^^^^^^^^^^^^^^^^
> relatively low level. (compiler dependant) It flushes the output buffer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (or writes directly to hardware) immediately. The Cout archive (a high
> level object, with the wonderfully overiden << operator) has a buffering
> scheme that either writes IO when the 'out' buffer is full or when you
> manually flush it, or when the program terminates.
Completely untrue. All the C streams are buffered, just like the C++
streams. The problem is that the C streams and C++ streams are
buffered _independently_ of one another, so flushing one does not
flush the other.
This has been changed in the current draft standard, so C++ streams
and C streams can be intermixed (even though I still don't consider
it good coding practice when you have a choice).
Pete
</PRE>
<HR><A NAME=TOOL_MSVC_COMPILER_ERROR>
Return to <a href="wpw_tool_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: VC++ Compiler error</H4><PRE>
In article <3rtvis$h90@news.csus.edu>
pat@orion.sfsu.edu "PATRICK MASAO HORIO" writes:
>
>I just installed VC1.51 on my system. Installation proceeded smoothly
>without any errors.
>
>However, I can't compile any programs! Even when I try to compile the
>simplest and shortest programs, I get this error message:
>
> Can't open the compilation response file
A common cause of this type of error is having a TMP or TEMP environment
variable which isn't pointing at a valid directory. Eg your AUTOEXEC.BAT
file says:
set TMP=C:\TMP
and you don't have a "C:\TMP" directory.
Chris
--
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK | Author of SkyMap v2 shareware |
| chris@chrism.demon.co.uk | astronomy program for Windows. |
| For more info, see http://www.winternet.com/~jasc/skymap.html |
| Author member of Association of Shareware Professionals (ASP) |
--------------------------------------------------------------------------
</PRE>
<HR><A NAME=TOOL_MSVC_DEBUG_RELEASE_MODE>
Return to <a href="wpw_tool_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: VC++ Debug Release Mode</H4><PRE>
In article <mdavies.28.00B2C03F@CAM.ORG> mdavies@CAM.ORG "Max Davies" writes:
>
> In Visual C++ 1.51 the following code snippet works perfectly when compiled in
> DEBUG mode, but
> misbehaves (without warning) when re-compiled in RELEASE mode.
>
> ====================================
> Max Davies - Software Specialist
> Open Universal Software, Montreal CANADA
> mdavies@cam.org
>
I am using Visual C++ V1.50. I had the same problem. I built an application
in debug mode, everything seems OK. But when I rebuilt in release mode,
suddenly it is a real mess. This only ocurred 2 to 3 times, and I was
never able to track the problem. Subsequent rebuilt seemed OK.
I also had a related problem. One of my program is built in release mode.
It runs in one computer OK, but suddenly became a mess when I loaded in
another computer. Again, I wasn't able to track it down, as I can't
reproduce the problem.
Does anyone else have the same experience?
--
Ming Fang
Applied Information Engineering
Lloyd's Register, Croydon
<HR>
In article <mdavies.28.00B2C03F@cam.org>, Max Davies <mdavies@CAM.ORG> wrote:
>
>In Visual C++ 1.51 the following code snippet works perfectly when compiled in DEBUG mode, but
>misbehaves (without warning) when re-compiled in RELEASE mode.
>
>I realize that most such discrepencies are caused by programming errors that simply have
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -