帮我稍微排序一下编程语言

发布于 2024-09-05 23:32:10 字数 640 浏览 4 评论 0原文

所以前几天我在这里问了一下C#及其原理。现在,如果可以的话,我还有一些关于某些语言的一般性问题,因为对于像我这样的新手来说,这似乎有点令人困惑。确切地说,我想更多地询问语言功能而不是语法等。

说实话,就是这些特殊的功能让我很困扰,让我很困惑。例如,C 有 printf(),Pascal 有 writeln() 等等。我知道基本上这些函数的汇编程序的输出是相似的,每种语言或多或少都有其特殊的函数。用于控制台输出、文件操作等。但是所有这些函数实际上都是其操作系统 API 的一部分,那么为什么在 C 中区分 C 标准库函数和(在 Windows 上)WinAPI 函数,即使 printf() 也有要使用某些 Windows 功能,请调用其某些函数以在控制台窗口上实际显示所需的文本,因为实际的“显示”是由操作系统完成的。语言函数和系统API之间的界限在哪里?

现在我不太理解的语言——Python、Ruby 和类似的语言。更具体地说,我知道它们与 java 和 C# 类似,都被编译成字节码。但是,我不明白它在构建 GUI 应用程序方面的功能是什么。我看到了使用 Ruby 在 Linux 和 Windows 上编写 GUI 应用程序的教程。但这不就是某种升级吗?我的意思是其他教程似乎这些语言首先是用于小型脚本而不是构建大型应用程序。

我希望你能理解我为什么感到困惑。如果你这样做,请帮我解决一下,我没有人可以问。

so I asked here few days ago about C# and its principles. Now, if I may, I have some additional general questions about some languages, because for novice like me, it seems a bit confusing. To be exact I want to ask more about language functions capabilities than syntax and so.

To be honest, its just these special functions that bothers me and make me so confused. For example, C has its printf(), Pascal has writeln() and so. I know in basic the output in assembler of these functions would be similar, every language has more or less its special functions. For console output, for file manipulation, etc. But all these functions are de-facto part of its OS API, so why is for example in C distinguished between C standard library functions and (on Windows) WinAPI functions when even printf() has to use some Windows feature, call some of its function to actually show desired text on console window, becouse the actual "showing" is done by OS. Where is the line between language functions and system API?

Now languages I don't quite understand - Python, Ruby and similar. To be more specific, I know they are similar to java and C# in term they are compiled into bytecode. But, I do not unerstand what are its capabilities in term of building GUI applications. I saw tutorial for using Ruby to program GUI applications on Linux and Windows. But isn´t that just some kind of upgrade? I mean fram other tutorials It seemed like these languages was first intended for small scripts than building big applications.

I hope you understand why I am confused. If you do, please help me sort it out a bit, I have no one to ask.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

独自唱情﹋歌 2024-09-12 23:32:10

在底部,您拥有操作系统内核本身 - 在特殊 CPU 模式下运行的代码,允许直接访问其他受保护的资源。除非您是操作系统开发人员,否则您永远不必处理这个问题。

然后是一条禁止交叉的线,将“内核空间”与“用户空间”分开。作为“普通”开发人员,您所做的一切都是在用户空间中完成的。

操作系统内核将有限数量的非常基本的函数导出到用户空间,称为“系统调用”。例如,打开文件、读/写多个字节、关闭文件。

因为这些系统调用通常需要一些开发人员不想打扰的汇编代码,所以它们被“包装”在(通常)C 代码函数中:open()、read()、write()、close()。

现在有组 API 可供开发人员使用:操作系统 API 和标准语言 API。

标准语言 API 提供可在任何支持该语言的平台上使用的函数:fopen()、fputc()、fgetc()、fclose()。它还将提供更高级的函数,使生活更轻松:例如 fprintf()。

操作系统 API 提供了自己的一组函数。它们不能移植到不同的操作系统,但可能使用起来更直观,或更强大,或者只是不同。打开文件()、读取文件()、写入文件()、关闭文件()。同样,更高级别的函数可能可用,即 PrintLn()。

两组函数可能部分相互依赖,或者直接进行系统调用,但这不会给您带来太多困扰。但是,您应该事先决定要在项目中使用哪一组函数,因为混合这两组函数(虽然本身不​​是错误)会打开一个整体新的蠕虫罐头(即潜在的错误)。

At the bottom you have the OS kernel itself - code that runs in a special CPU mode that allows direct access to otherwise protected resources. You will never have to deal with this unless you're an OS developer.

Then comes a do-not-cross line seperating this "kernel space" from "user space". Everything you do as "normal" developer is done in user space.

The OS kernel exports a limited number of very basic functions into user space, dubbed "system calls". Open a file, read / write a number of bytes, closing the file, for example.

Because these system calls usually require some Assembler code developers don't want to be bothered with, they are "wrapped" in (usually) C code functions: open(), read(), write(), close().

Now come two sets of APIs available to the developer: The OS API, and the standard language API.

The standard language API provides functions that can be used on any platform supporting the language: fopen(), fputc(), fgetc(), fclose(). It will also provide higher-level functions that make life easier: fprintf(), for example.

The OS API provides its own set of functions. These are not portable to a different operating system, but might be more intuitive to use, or more powerful, or merely different. OpenFile(), ReadFile(), WriteFile(), CloseFile(). Again, higher-level functions might be available, i.e. PrintLn().

The two sets of functions might partially rely on each other, or make system calls directly, but that shouldn't bother you too much. You should, however, decide beforehand which set of functions you will want to use for your project, because mixing the two sets - while not a mistake in itself - opens a whole new can of worms (i.e., potential errors).

说不完的你爱 2024-09-12 23:32:10

C是可移植的。这意味着在不同的系统上,printf 的汇编器输出会有所不同......这是编译器根据您的目标系统所做的事情。编写 C 代码并编译为 Linux 应用程序,输出将不同于 Win32 应用程序,也不同于为 iPhone 或类似设备编译完全相同的代码。

在内部,当您调用 printf 时,C 标准库可能会包装对 Win32 API 的调用,但在大多数情况下这并不是您真正关心的问题。 C 标准库(例如 printf 和其他用于文件和内容的 I/O)包装执行您想要的操作所需的低级操作系统或硬件代码。

值得注意的是,Java 中也有同样的效果,但方式不同。从广义上讲:在 Java 中,您编写的代码总是编译为相同的字节码。但是,当 JVM 运行此字节码时,JRE 在运行时将其转换为特定于机器的指令,而不是在 C 上编译时。

C is portable. That means that on different systems the assembler output for printf will be different... this is something the compiler does based on what your target system is. Write C code and compile as a Linux app and the output will be different than as a Win32 app, and also different than if you compile the exact same code for an iPhone or something like that.

Internally, the C standard libraries might wrap a call to Win32 API when you call printf, but that's not really your concern in most cases. The C standard library (like printf and other I/O for files and stuff) wraps the low-level OS or hardware code needed to do what you want.

It's worth noting the same effect happens in Java, but in a different way. At a broad level: In Java, the code you write always compiles to the same byte-code. But then when the JVM runs this byte-code, the JRE translates it to machine-specific instructions at run-time, rather than at compile-time on C.

陈甜 2024-09-12 23:32:10

所以。

对于你的第一个问题,C API 和 OS API 之间的接口是 C 运行时。在 Windows 上,这是 MSVCRT.DLL 的某种形式,而在 Linux 上,这是 glibc。

对于第二个,大多数 GUI 工具包的本地语言是 C 或 C++。寻求使用它们的高级语言需要在语言和 C/C++ API 之间来回转换的绑定。

第三,这些高级语言似乎只用于“小脚本”。简单的事实是,它们比 C 或 C++ 更具表现力,这意味着它们具有与 C 或 C++ 程序相同或更多的功能,同时用更少的代码行编写。

So.

For your first question, the interface between the C API and the OS API is the C runtime. On Windows this is some incarnation of MSVCRT.DLL, whereas on Linux this is glibc.

For the second, the native language for most GUI toolkits is either C or C++. Higher-level languages seeking to use them require bindings which translate back and forth between the language and the C/C++ API.

For the third, these high-level languages only appear to be used for "small scripts". The simple fact is that they are far more expressive than C or C++, which means that they have equal or more capabilities than a C or C++ program while being written in fewer lines of code.

幻梦 2024-09-12 23:32:10

如果我认为这是您的核心问题:

语言函数和系统API之间的界限在哪里?

然后想象一下您是否愿意这样比喻:

OS API 系统调用就像乐高积木和乐高组件。

编程“函数”只不过是许多乐高积木的排列。这样组合就形成了一个工具。

因此,不同的语言可以以不同的方式“安排”和创建工具。

如果我让你用乐高积木制作一辆汽车,你可以想出许多不同的设计。

If I assume this is your central question:

Where is the line between language functions and system API?

Then imagine if you will this analogy:

OS API system calls are like lego bricks and lego components.

Programming 'functions' are merely an arrangement of many lego bricks. Such that the combination results in a tool.

Thus different languages may 'arrange' and create the tool in different ways.

If I asked you to create a car with lego's, you could come up with many different designs.

非要怀念 2024-09-12 23:32:10

C 的 printf() 是一个包装器。您可以使用它并在任何操作系统下编译代码,但生成的机器代码会有所不同。在 Windows 中,它可能会调用 Windows API 中的某些函数。在Linux中,它将使用Linux API。你问为什么Windows API有区别。这是因为,如果您正在为 Windows 编程,您可以使用它来执行一些特定于操作系统的操作,例如创建 GUI、操作控制台文本(而不仅仅是打印)、请求操作系统资源等等。 Linux 和 Mac(我猜还有所有其他操作系统)也存在类似的 API,它们可以让您做或多或少相同的事情。但与 printf() 不同的是,它们不可移植。

你问语言函数和系统 API 之间的界限是什么。语言函数只是调用操作系统的 API。您可以自己调用这些,但是这样您将无法在不同的系统上编译代码。

Python 和 Ruby(以及其他一些)是解释型的。它们在幕后被编译为字节码,但用户看到的只是双击源文件将运行它。无需编译。显然,这意味着它们比编译语言慢。然而,它们的动态特性可以加快开发速度,因为通常需要更少的代码来完成同样的事情(我说通常)。

这并不意味着这些语言不能用于“大型”应用程序:它们有 GUI 库。这是因为这些是通用语言,与 Bash 等其他语言不同。

C's printf() is a wrapper. You can use it and compile your code under any OS, but the resulting machine code will be different. In Windows, it might call some function inside the Windows API. In Linux, it will use the Linux API. You ask why is the Windows API distinguished. That's because, if you're programming for Windows, you can use it to do some OS-specific things like create GUIs, manipulate console text instead of just printing, asking for OS resources, and stuff like that. An API like that exists for Linux and Mac (and I guess all the other OS's) too, and they let you do more or less the same things. Unlike printf(), though, they are not portable.

You ask what is the line between language functions and the system API. The language functions simply call the OS's API. You can call these yourself, but then you won't be able to compile your code on different systems.

Python and Ruby (and some others) are interpreted. They are compiled to bytecode behind the scenes, but all the user sees is that double-clicking the source file will run it. No need to compile. That means, obviously, that they're slower than compiled languages. However, their dynamic nature makes for faster development, since you usually need less code to do the same thing (I said usually).

That doesn't mean these languages can't be used for "big" applications: There are GUI libraries for them. That's because these are general purpose languages, unlike some others like Bash.

长不大的小祸害 2024-09-12 23:32:10

更具体地说,我知道它们在编译成的术语方面与 java 和 C# 类似
字节码。

Ruby 和 Python 都是解释性语言,http://en.wikipedia.org/wiki/Interpreted_language,并且它们的代码在执行之前不会转换为字节码。

To be more specific, I know they are similiar to java and C# in term they are compiled into
bytecode.

Ruby and Python are both interpreted languages, http://en.wikipedia.org/wiki/Interpreted_language, and their code is not translated into bytecode prior the execution.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文