控制台C ++ [英] Console C++

问题描述

...
我当时在程序中使用Turbo C ++编译器，但是现在我才搬到Visual Studio并开始使用Visual Studio .NET2008.即使在标准库中，这也与我以前的版本有很大的不同...为什么?而且对C ++控制台程序是否仍然有任何要求，它们又是什么...我想留在C/C ++开发中...对吗?

谢谢，..
Dinesh Balu:thumbsup:

Hi,...
I was using Turbo C++ compiler for my programs and now i just moved to Visual studio and started working with Visual studio .NET 2008.This one is much different than my old one even in the standard libraries... Why is that... And Is There still any requirement for C++ console programs and what are they...I like to stay in C/C++ development... Is that right?

Thank You,..
Dinesh Balu :thumbsup:

推荐答案

大问题.这取决于您要做什么以及如何以及在何处部署应用程序.

1)Win32将允许您使用所有标准C/C ++库

优势:您的应用程序没有什么可部署的.
缺点:功能较少.

2)MFC建立在win32库的基础上，并在很大程度上增加了类库，但并不令人惊讶，它与Windows UI有关.

优势:更加丰富的功能
缺点:取决于MFC库，从而增加了应用程序的外观


3)CLR/C ++.NET将允许您使用studio 2008访问.Net Framework 2.0、3.0或3.5.此外，您还可以访问MFC和标准C/C ++库.

优点:功能更丰富，可以访问托管环境
缺点:您使用的哪个.NET框架都需要安装在运行应用程序的计算机上.


注意.NET是一个托管环境(为您删除了内存)，当与MFC和非托管标准库混合使用时会出现问题.

摘要
这在很大程度上取决于您的需求，相当于Turbo C ++编译器的最认真的是Win32控制台应用程序，但选择是您自己的.

Big Question. It depends on what you want to do and how and where you want to deploy your applications.

1) Win32 will allow you to use all standard C/C++ libraries

Advantages : nothing appart from you application to deploy.
Disvantages: Less functionality.

2) MFC is built on top of win32 libraries with the addition of a class library largely, but no excusivly, concerned with windows UI

Advantages : Richer functionality
Disadvantages: Dependant on MFC libraries increasing foot print of your application


3) CLR/ C++.NET Will allow you to access .Net framework 2.0, 3.0, or 3.5 with studio 2008. Also you would be able to access MFC and standard C/C++ libraries.

Advantages : Richer functionality, Access to Managed Environment
Disadvantages: Which ever .NET framework you use it will need to be installed on the machine that runs your application


Note .NET is a Managed environment (memory is deleted for you) which will present issues when mixed with MFC and standard libs which are unmanaged

Summary
It very much depends on your needs, the nerest equivalent to a turbo C++ compiler would be a win32 console application, but the choice is yours.

似乎您是供应商声称的受害者标准"实际上是他们自己的发明.

Standard C ++与Windows和控制台无关:它只是一种表达算法的语言，通常采用输入序列和输出序列.

实施交互式终端"(也称为控制台")概念的操作系统(在今天，实际上是所有商用和Opensurce OS)都用于将默认输入和默认输出(以及默认错误)映射到控制台输入(即以字符序列的形式序列化键盘操作)并输出(使字符序列在自滚动屏幕或窗口的上下文中表示).
在这种情况下，作为TurboC ++的MSC ++和MinGW/Codeblocks以及其他任何环境都完全等效.这是ISO C ++标准的唯一内容.

当您想在图形环境中管理不同类型的用户交互(例如:鼠标输入)时，事情会发生变化.
ISO标准对此一无所获，至少必须使用操作系统API(通常:Windows上的Win32或Unix/Linux上的Xlib).

这些API在概念上并没有什么不同，但是在形式上并没有什么不同-为了保持二进制兼容性-必须具有C链接(因为C ++标准没有为目标文件指定二进制格式)，因此有许多C ++库已部署为给这些API(从概念上讲是面向对象的)提供了一个OOP一致的接口.

TurboC拥有自己的产品，Microsoft拥有自己的(MFC)，其他社区也开发了自己的产品-有时旨在从基本API进行抽象，并具有独立于OS的通用接口.

为了使事情复杂一点，许多脚本语言和解释语言(例如Java-我知道，这不是事实，但那不是重点-跟我来吧)出现了自己的内存模型和托管"环境保证了更高效和更少出错"的编程.
在这种情况下，Microsoft提出了".Net"倡议，并发明"了一种语言(C#)，该语言是从托管.NEt环境开始的一种C ++演变.

为了保持与旧代码的兼容性，C ++语言随后通过一些特定功能和关键字得到增强，以允许非托管"代码也与托管"组件/环境进行交互.
结果是针对CLR(我之前所说的托管运行时环境)的名为C ++/CLI的C ++扩展，这是Microsoft向ECMA提出的(因此现在他们可以说这是一个标准)，但从未被ISO采纳. (这是标准C ++的所有者)，因此使C ++/CLI和C ++成为两个不同的事物.

关键是MSVisualC ++或TurboC ++都不是"STANDARD C ++".
它们是符合ISO要求的C ++编译器以及特定于制造商的工具，以支持开发当今环境所需的非ISO应用程序，这些应用程序是:
-Windows本机代码(或Linux或MAC/OS本机代码)
-与操作系统无关的本机代码(通过与操作系统无关的API无关的库，取决于操作系统的版本)
-依赖于操作系统的托管"代码.

It seems you are a victim of the vendors claiming "standard" what are -in fact- their own invention.

The Standard C++ has nothing to do about windows and consoles: it is just a language to express algorithms taking generically an input sequence and an output sequence.

Operating systems that implement the concept of "interactive terminal" (also called "console" - in practice all the commercial and opensurce OS today) use to map the default input and default output (as well as default error) to the console input (that serialize the keyboard action in the form of a character sequence) and output (that makes sequence of character to be represented into the context of a self-scrolling screen or window).
In this, MSC++ as TurboC++ as MinGW/Codeblocks and whatever environment are prefectely equivalent. And this is the only thing the ISO C++ standard is about.

Things changes when you want to manage different kind of user interactions (es: mouse input) in a graphical environment.
The ISO standard says nothing about this, and you have to work -at least- with the operating system APIs (typically: Win32 on windows or Xlib on unix/linux).

These API are not that different in conceptualization, but they are in their formalization, and - to retain binary compatibility- have necessarily C linkage (since C++ standard don''t specify the binary format for the object files) hence a number of C++ libraries had been deployed to give to these API (that are conceptually object oriented) also an OOP consistent interface.

TurboC has its own, Microsoft has its own (MFC) and other communities developed their own -sometime with the purpose to abstract from the basic API and have a common interface that is OS independent.

To complicate things a little bit more, a number of scripting language and interpreted languages (like Java - I know, that''s not the truth, but that''s not the point- just follow me) appeared with their own memory model and "managed" environment promising a more productively and "less prone to error" programming.
In this scenario, Microsoft proposed the ".Net" initiative and "invented" a language (C#) that was a sort of C++ evolution form the managed .NEt environment.

To retain compatibility with legacy code, the C++ language was then enhanced with some specific features and keywords to allow "unmanaged" code to interact also with "managed" component / environment.
The result is an extension of C++ named C++/CLI that target the CLR (The managed runtime environment I talk before), that was proposed by Microsoft to ECMA (so now they can say it is a standard) but was never adopted by the ISO (that is the owner of the standard C++), thus making C++/CLI and C++ two different things.

The key point is that neither MSVisualC++ or TurboC++ is "STANDARD C++".
They are ISO compliant C++ compiler plus manufacturer specific tools to support the development of non-ISO application that are required for today environment that are:
- Windows native code (or Linux or MAC/OS native code)
- OS independent native code (through OS dependent version of OS independent API library)
- OS dependent "managed" code.

假设您的Visual Studio已安装c ++，您仍然可以在win32或C ++.NET中创建c ++控制台应用程序.
要创建Win32控制台应用程序，请遵循以下菜单路径:

文件->新建-> Visual C ++-> Win32-> Win32控制台应用程序

要创建C ++.Net控制台应用程序，请遵循以下菜单路径:


文件->新建-> Visual C ++-> CLR-> CLR控制台应用程序

Assuming your visual studio has c++ installed, you can still create c++ console applications in win32 or C++.NET

To create a win32 console application follow the following menu path:

File->New->Visual C++->Win32->Win32 console Application

To create a C++.Net console application follow the following menu path:


File->New->Visual C++->CLR->CLR Console Application

这篇关于控制台C ++的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！