Вопрос к программистам на C , Исходники ядра Linux

Цитата Flex Ferrum @ 20.07.06, 23:21

А также покажи мне в поставке компилятора от мелкомягких загловочный файл unistd.h.

Всё брошу и буду в цинду перезагружаться -- ищи в том, что описано в "библии M$" -- MSDN. Там всё написано. Или, в M$ врут?

Цитата Flex Ferrum @ 20.07.06, 23:21

Ты для начала сам для себя определись - что и какой стандрат описывает. Что описывает стандарт IEEE 1003.1x/ISO IEC 9945−2:1993, и что - ISO 9899. Hint: первый упомянутый мною стандарт язык С точно не описывает.

Где ты это старьё отрыл -- Х.З. Я ссылку дал. На IEEE Std 1003.1-2001 цитата оттеда:

Цитата

IEEE Std 1003.1-2001 is one of a family of standards known as POSIX. The family of standards extends to many topics; IEEE Std 1003.1-2001 is known as POSIX.1 and consists of both operating system interfaces and shell and utilities. IEEE Std 1003.1-2001 is technically identical to The Open Group Base Specifications, Issue 6, which comprise the core volumes of the Single UNIX Specification, Version 3.

Всё ясно или перевод выделенного фрагмента нужен? Так вот, стандарт от 1993г., как следует из названия описывает всё то же, только раньше. Если ты до сих пор считаешь что стандарт не меняется со временем, то... Мне жаль.

Стандарт ISO 9899 и его соотвествие POSIX?
Взгляни сюда -> http://www.pasc.org/standing/sd11.html#statustable

А, вообще, чтоб мне тут в клаву долго пальцами не тыкать, кося под Прометея, вот тебе FAQ -> http://www.opennet.ru/base/faq/posix_faq.txt.html

Цитата Flex Ferrum @ 20.07.06, 23:21

Все еще не понятно? Интерфейс не может быть языком. А язык - интерфейсом. У них разные задачи.

Ой, извини, не дери мосск... Мне уже всё понятно. Особенно насчёт "слабосвязанных вещей".
Отношение своё к данной теме я уже сформулировал, а следить за извержением "доказательств" при отсутствии знаний по данному вопросу и отвержению очевидных фактов (я про M$DN), извини, просто и без затей задолбаллло.

DIXI.

Интересно, почему никакого другого исхода этой темы я и не ожидал?

Цитата e-yes @ 20.07.06, 21:06

У меня почему-то два насчиталось.

mov esi,[instancePtr] ; Это по-любому делается и в C
mov eax,[esi] ; Предположим, что указатель на vtbl лежит прямо в начале структуры
                     ; этот mov и есть единственный overhead
push esi ; this
call [eax + 4] ; Вызываем метод

В C был бы сразу вызов call [esi + methodOffset], так что оверхед только один mov.
Но, честно говоря, не приходилось видеть таких реализаций ООП в C. То, что делают в ядре я бы назвал "handler", а не "method", хотя виртуальные методы туда довольно хорошо вписываются.

Цитата the_Shadow @ 20.07.06, 23:05

И откуда следует что это -- слабосвязанные вещи, вообще-то?

the_Shadow, сейчас ты пытаешься доказать, что GTK для C -- это единственно верный GTK, а все многочисленные биндинги -- это уже не GTK. Такая аналогия отношения POSIX <-> C лучше отражает суть дела, чем "компьютер" и "клавиатура".

Цитата the_Shadow @ 20.07.06, 23:41

Всё ясно или перевод выделенного фрагмента нужен? Так вот, стандарт от 1993г., как следует из названия описывает всё то же, только раньше. Если ты до сих пор считаешь что стандарт не меняется со временем, то... Мне жаль.

Если для тебя описание "shell and utilities" == "спецификация на язык С", то говорить действительно больше не о чем.

Цитата the_Shadow @ 20.07.06, 23:41

Стандарт ISO 9899 и его соотвествие POSIX?
Взгляни сюда -> http://www.pasc.org/standing/sd11.html#statustable

Много букв. Не осилил. Скинь цитату, на которую ты просишь обратить внимание.

Цитата the_Shadow @ 20.07.06, 23:41

Всё брошу и буду в цинду перезагружаться -- ищи в том, что описано в "библии M$" -- MSDN. Там всё написано. Или, в M$ врут?

Было достаточно тех ссылок, которые ты привел раньше. Там во всех примерах использовался gcc. А отнюдь не vc.exe.

Цитата the_Shadow @ 20.07.06, 23:41

а следить за извержением "доказательств" при отсутствии знаний по данному вопросу и отвержению очевидных фактов (я про M$DN), извини, просто и без затей задолбаллло.

Ессесно. Шад у нас знает все и лучше всех. Все остальные тут и рядом не стоят... Ибо обвинения в некомпетенции по различным вопросам слышны только от Шада. Что-то я не слышал ничего подобного ни от trainer'а, ни от Ho Im'а, ни от Hryak'а, ни от многих других ни в отношении меня, ни в отношении других участников форума. Да и странно получается - как только Шаду задается прямой вопрос, он от него мягко уходит. Я, например, прямо спросил тебя, в чем я ошибся:

Цитата Flex Ferrum @ 20.07.06, 21:15

Я ошибся в том, что POSIX и ISO C - это два разных стандарта?
Я ошибся в том, что POSIX - это стандарт на интерфейс, а C - это инструментарий для работы с этим интерфейсом?
Я ошибся в том, что POSIX и CRTL в некоторой мере пересекаются?
Я ошибся в том, что из кода на ассемблере я не могу сделать вызов метода, определенного в POSIX?

Ты ни на один вопрос прямо не ответил. А ответы очень хотелось бы услышать. И не в виде ссылок и фраз "читай букварь", а в виде цитат, которые однозначно показывают, что мое утверждение не верно. Только в этом случае обвинение в некомпетенции будет мною рассмотрено как обоснованное.

Flex, извини, но POSIX является, вообще говоря, зарегистрированной торговой маркой IEEE.
Стандарт POSIX 1.x является полным аналогом IEEE 1003.1/x.
Более того, 1003.1х состоит из :
1003.1 System Interface 9945-1, 1003.1a Additional System Services 9945-1, 1003.1b Realtime Extensions 9945-1, 1003.1c Threads 9945-1, 1003.1d Additional Realtime Extensions 9945-1, 1003.1e Security 9945-1, 1003.1f Transparent File Access 9945-1, 1003.1g Protocol Independent Interfaces 9945-1, 1003.1h Fault Tolerance 9945-1, 1003.1i Fixes to 1003.1b 9945-1, 1003.1j Advanced Realtime Extensions 9945-1, 1003.1k Removable Media API 9945-1, 1003.1m Checkpoint/Restart 9945-1, 1003.1n Fixes to 1003.1/1b/.1i/.1c 9945-1, 1003.1p Resource Limits 9945-1, 1003.1q Tracing 9945-1, 1003.1r 1003.1g Alignment w/ Single Unix Spec 9945-1, 1003.1s Sync Clock 9945-1.
Я уже привёл ссылку на стандарт IEEE 1003.1. Выше. Здесь опубликовать весь стандарт не имею ни сил ни желания. А вот сюда глянуть рекомендую -> http://www.kuzbass.ru:8086/docs/sus2/functions/contents.html
"System Interfaces", знаете ли, и почему там кроме С нет асма или Java? Не знаю.
По этой причине, слова:

Цитата Flex Ferrum @ 21.07.06, 09:14

Если для тебя описание "shell and utilities" == "спецификация на язык С", то говорить действительно больше не о чем.

Есть откровенное враньё, показывающее что ты, Flex, в данном вопросе некомпетентен. Это не обвинение. Это факт. Ты просто путаешь ряд вещей. Коль скоро ты их путаешь, то... Вывод только один -- твёрдо ты их не знаешь. Извини, но мне со всем этим приходится работать... UNIX, знаешь ли...

По этой причине фраза:

Цитата

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи.

На основании стандарта IEEE 1003.1x это простой и откровенный бред.

RTFM!

Цитата linuxfan @ 21.07.06, 06:43

сейчас ты пытаешься доказать, что GTK для C -- это единственно верный GTK, а все многочисленные биндинги -- это уже не GTK. Такая аналогия отношения POSIX <-> C лучше отражает суть дела, чем "компьютер" и "клавиатура".

Положим, этого я не пытался доказать... Имея, скажем так, некоторое представление о сути спора и стандарте UNIX считаю это доказательство избыточным. Ты именно так понял то, о чём мы здесь? Жаль... Весьма жаль...

Цитата linuxfan @ 21.07.06, 06:43

Но, честно говоря, не приходилось видеть таких реализаций ООП в C. То, что делают в ядре я бы назвал "handler", а не "method", хотя виртуальные методы туда довольно хорошо вписываются.

Вписываются, но на фиг там не нужны.

Добавлено 21.07.06, 10:32

Цитата Flex Ferrum @ 21.07.06, 09:14

Ессесно. Шад у нас знает все и лучше всех. :) Все остальные тут и рядом не стоят...

Flex, нарушение правил. Переход на личности. Но, если честно, то да. В данном случае ты просто не осведомлён о том, о чём ты споришь. Извини, но это так. По сумме факторов.

Всё. Учи матчасть.

Цитата linuxfan @ 21.07.06, 06:43

mov esi,[instancePtr] ; Это по-любому делается и в C
mov eax,[esi] ; Предположим, что указатель на vtbl лежит прямо в начале структуры
; этот mov и есть единственный overhead
push esi ; this
call [eax + 4] ; Вызываем метод

В C был бы сразу вызов call [esi + methodOffset], так что оверхед только один mov.

push esi - тоже оверхед, т.к нам не всегда (скорее почти никогда) нужен this в методе класса, содержащем одни методы, без данных. Но C++ разве позволяет определять static virtual method??? /* Вроде как и нет */

ЗЫ. А разве this в стек пихается? По моему, только в esi и передается. Следовательно в оверхеде имеем два mov'а.

Сообщение отредактировано: e-yes - 21.07.06, 11:07

Цитата the_Shadow @ 21.07.06, 10:30

1003.1 System Interface 9945-1, 1003.1a Additional System Services 9945-1, 1003.1b Realtime Extensions 9945-1, 1003.1c Threads 9945-1, 1003.1d Additional Realtime Extensions 9945-1, 1003.1e Security 9945-1, 1003.1f Transparent File Access 9945-1, 1003.1g Protocol Independent Interfaces 9945-1, 1003.1h Fault Tolerance 9945-1, 1003.1i Fixes to 1003.1b 9945-1, 1003.1j Advanced Realtime Extensions 9945-1, 1003.1k Removable Media API 9945-1, 1003.1m Checkpoint/Restart 9945-1, 1003.1n Fixes to 1003.1/1b/.1i/.1c 9945-1, 1003.1p Resource Limits 9945-1, 1003.1q Tracing 9945-1, 1003.1r 1003.1g Alignment w/ Single Unix Spec 9945-1, 1003.1s Sync Clock 9945-1.

Замечательный список. Какой из этих документов описывает язык С? Просто его номер. С фразой: "вот это - стандарт на язык С". А то, что в

Цитата the_Shadow @ 21.07.06, 10:30

"System Interfaces", знаете ли, и почему там кроме С нет асма или Java? Не знаю.

так все описание WinAPI - на чистейшом С. Наверное, C является частью WinAPI и WinAPI содержит спецификацию языка С? Не находишь?

Цитата the_Shadow @ 21.07.06, 10:30

На основании стандарта IEEE 1003.1x это простой и откровенный бред.

Приведи, пожалуйста, цитату из этого документа, которая однозначно бы показала, что такая моя фраза - откровенный бред. Иначе я утвержусь во мнении, ты не делаешь никакого различия между средством программирования (языком С) и используемым программным интерфейсом (POSIX). Что для тебя эти два понятия - суть одно и тоже. При таком раскладе дискуссия совершенно терят смысл, потому как (не побоюсь этого слова) большинство из здесь присутствующих прекрасно понимают разницу между языковыми средствами и используемыми программными интерфейсами. Ибо интерфейсом я могу пользоваться так, как хочу, и оттуда, откуда хочу. И язык использовать совершенно не для того, чтобы дергать с его помощью методы интерфейса.

Цитата the_Shadow @ 21.07.06, 10:30

Но, если честно, то да. В данном случае ты просто не осведомлён о том, о чём ты споришь. Извини, но это так. По сумме факторов.

В который раз я прошу тебя прокомментировать (цитатами из стандартов) вот эти мои вопросы:

Цитата Flex Ferrum @ 21.07.06, 09:14

Я ошибся в том, что POSIX и ISO C - это два разных стандарта?
Я ошибся в том, что POSIX - это стандарт на интерфейс, а C - это инструментарий для работы с этим интерфейсом?
Я ошибся в том, что POSIX и CRTL в некоторой мере пересекаются?
Я ошибся в том, что из кода на ассемблере я не могу сделать вызов метода, определенного в POSIX?

Ну и еще один (до кучи):
Я ошибаюсь в том, что язык программирования и интерфейс прикладных программ - это совершенно разные (не сравниваемые) вещи?
иначе (коль уж ты заговорил о правилах), то ты легко попадешь под их пятый пункт. Ибо никакой четкой и однозначной аргументации приведено не было. Приводимые ссылки слишком обширны, чтобы служить таковыми аргументами, тем более из твоих комментариев становится ясно, что некоторые из них ты проглядывал "по диагонали". А обвинение в некомпетенции - весьма серьезное обвинение. И должно быть доказано таким образом, чтобы ни у кого не возникло сомнений в том, что Flex Ferrum совершенно не осведомлен в вопросах, которые берется обсуждать.

Добавлено 21.07.06, 11:43
И еще немного по этому поводу:

Цитата the_Shadow @ 20.07.06, 23:41

and consists of both operating system interfaces and shell and utilities.

Раздел Shell & Utilities/Utilities содержит помимо утилиты под названием c99, такие утилиты, как:
fort77
yacc
lex
Давай мы, в таком случае, будем считать стандарт на язык Fortran 77, спецификации на БНФ-грамматки а также на регулярные выражения, используемые в lex - также частью стандарта POSIX.

Flex Ferrum, опять таки, зрит в корень. По сложившейся традиции, видать.

Дабы у Шада опять не возникло сомнений в том, что я не RTFM'лю, приведу некоторые выдержки из указанных им документов:
Берем в руки докмент под заглавием "The Open Group Base Specifications Issue 6 IEEE Std 1003.1-2001", открываем и читаем.
В разделе Rationale/Portability Considerations (Informative):

Цитата

User Requirements
This section describes the user requirements that were perceived by the developers of IEEE Std 1003.1-2001. The primary source for these requirements was an analysis of historical practice in widespread use, as typified by the base documents listed in Scope .

IEEE Std 1003.1-2001 addresses the needs of users requiring open systems solutions for source code portability of applications. It currently addresses users requiring open systems solutions for source-code portability of applications involving multi-programming and process management (creating processes, signaling, and so on); access to files and directories in a hierarchy of file systems (opening, reading, writing, deleting files, and so on); access to asynchronous communications ports and other special devices; access to information about other users of the system; facilities supporting applications requiring bounded (realtime) response.

The following users are identified for IEEE Std 1003.1-2001:

Those employing applications written in high-level languages, such as C, Ada, or FORTRAN.

Users who desire conforming applications that do not necessarily require the characteristics of high-level languages (for example, the speed of execution of compiled languages or the relative security of source code intellectual property inherent in the compilation process).

Users who desire conforming applications that can be developed quickly and can be modified readily without the use of compilers and other system components that may be unavailable on small systems or those without special application development capabilities.

Users who interact with a system to achieve general-purpose time-sharing capabilities common to most business or government offices or academic environments: editing, filing, inter-user communications, printing, and so on.

Users who develop applications for POSIX-conformant systems.

Users who develop applications for UNIX systems.

В разделе Rationale: Base Definitions/Introduction читаем:

Цитата

Scope of IEEE Std 1003.1-2001
The (paraphrased) goals of this development were to produce a single common revision to the overlapping POSIX.1 and POSIX.2 standards, and the Single UNIX Specification, Version 2. As such, the scope of the revision includes the scopes of the original documents merged.

Since the revision includes merging the Base volumes of the Single UNIX Specification, many features that were previously not "adopted" into earlier revisions of POSIX.1 and POSIX.2 are now included in IEEE Std 1003.1-2001. In most cases, these additions are part of the XSI extension; in other cases the standard developers decided that now was the time to migrate these to the base standard.

The Single UNIX Specification programming environment provides a broad-based functional set of interfaces to support the porting of existing UNIX applications and the development of new applications. The environment also supports a rich set of tools for application development.

The majority of the obsolescent material from the existing POSIX.1 and POSIX.2 standards, and material marked LEGACY from The Open Group's Base specifications, has been removed in this revision. New members of the Legacy Option Group have been added, reflecting the advance in understanding of what is required.

Единственное, что требуется, чтобы стадарт POSIX сохранял обратную совместимость с ISO 9899:1999:

Цитата

It was agreed that there should be no breakage of functionality in the existing base documents. This requirement was tempered by changes introduced due to interpretations and corrigenda on the base documents, and any changes introduced in the ISO/IEC 9899:1999 standard (C Language).

Но это объясняется в другом месте:

Цитата

The ISO C standard was selected as a model because most historical implementations of the standard utilities were written in C. Thus, it was more likely that they would act in the desired manner without modification.

Using the ISO C standard is primarily a notational convenience so that the many procedural languages in the Shell and Utilities volume of IEEE Std 1003.1-2001 would not have to be rigorously described in every aspect. Its selection does not require that the standard utilities be written in Standard C; they could be written in Common Usage C, Ada, Pascal, assembler language, or anything else.

Т. е. так исторически сложилось. Но это совершенно не означает, что все, что пишется под Unix с использованием POSIX должно писаться именно на С (см. выделенный фрагмент). В том числе и системыне утилиты. (раздел Rational: Shell & Utilities/Introduction/Concepts Derived from the ISO C Standard).

Какие еще выдержки из FM (которую я, вроде как, не читаю) привести?

Цитата e-yes @ 21.07.06, 10:58

Но C++ разве позволяет определять static virtual method???

Что тебе больше нравится: namespace или static void do_something?
Вот ты сам подумай, что такое "статические виртуальный метод".

Цитата e-yes @ 21.07.06, 10:58

ЗЫ. А разве this в стек пихается? По моему, только в esi и передается. Следовательно в оверхеде имеем два mov'а.

Ну если мы действуем на C и компилятор использует стандартные соглашения для вызовов, то this'у быть только в стеке. В C++, возможно, используется что-то свое, но по-моему тоже в стек кладется -- не уверен, могу врать.
Да где два mov'а? По-любому надо указатель на instance для начала куда-нибудь положить и в результате имеем оверхед из одного mov'а для загрузки адреса vtbl.

Очевидно, что POSIX базируется на C Runtime Library. Так уж исторически сложилось. Вплоть до 6-го релиза часть раздела System Interface содержала лишь ссылки на соответствующие функции, описанные в ISO С 9899:1999. Но я не нашел ссылок на то, что

Цитата the_Shadow @ 20.07.06, 21:34

Но сам по себе С основан на POSIX 1.x ("x" -- по причине того, что комитет меняет "номер версии").

Все говорит лишь о том, что POSIX основан на ISO С 9899:1999, и его составители обязуются вносить изменения в стандарт POSIX синхронно с изменениями в стандарте С. А также помечать в статьях, составляющих стандарт (там где ISO C и POSIX пересекаются) места, где идут расширения, не указанные в стандарте С:

Цитата

POSIX.1 and the ISO C Standard
Previous revisions of POSIX.1 built upon the ISO C standard by reference only. This revision takes a different approach.

The standard developers believed it essential for a programmer to have a single complete reference place, but recognized that deference to the formal standard had to be addressed for the duplicate interface definitions between the ISO C standard and the Single UNIX Specification.

It was agreed that where an interface has a version in the ISO C standard, the DESCRIPTION section should describe the relationship to the ISO C standard and markings should be added as appropriate to show where the ISO C standard has been extended in the text.

A block of text was added to the start of each affected reference page stating whether the page is aligned with the ISO C standard or extended. Each page was parsed for additions beyond the ISO C standard (that is, including both POSIX and UNIX extensions), and these extensions are marked as CX extensions (for C Extensions).

(Rationale: Base Definitions/POSIX.1 and the ISO C Standard). Что еще раз говорит о том, что
1. POSIX и ISO C - это разные стандарты.
2. В основе POSIX System Interface лежит часть стандарта ISO C (а если быть точнее - раздел 7. Library).
3. POSIX вправе расширять семантику функций, описанную в ISO C, явно оговорив такое расширение.

Я что-то упустил?

Цитата Flex Ferrum @ 21.07.06, 11:07

Замечательный список. Какой из этих документов описывает язык С? Просто его номер. С фразой: "вот это - стандарт на язык С". А то, что в

http://www.kuzbass.ru:8086/docs/sus2/functions/contents.html -- я уже просто устал приводить тебе ссылки. Я полагал, что в случае наличия Сети есть возможность проверить именно по ссылке.

Открываем и смотрим в глубь:

Цитата

The Open Group Base Specifications Issue 6
IEEE Std 1003.1-2001
Copyright © 2001 The IEEE and The Open Group
System Interfaces: Table of Contents

* Introduction
o Scope
o Conformance
o Normative References
o Change History
o Terminology
+ can
+ implementation-defined
+ legacy
+ may
+ shall
+ should
+ undefined
+ unspecified
o Definitions
o Relationship to Other Formal Standards
o Portability
+ Codes
o Format of Entries
* General Information
o Use and Implementation of Functions
o The Compilation Environment
+ POSIX.1 Symbols
# The _POSIX_C_SOURCE Feature Test Macro
# The _XOPEN_SOURCE Feature Test Macro
+ The Name Space
o Error Numbers
+ Additional Error Numbers
o Signal Concepts
+ Signal Generation and Delivery
+ Realtime Signal Generation and Delivery
+ Signal Actions
+ Signal Effects on Other Functions
o Standard I/O Streams
+ Interaction of File Descriptors and Standard I/O Streams
+ Stream Orientation and Encoding Rules
o STREAMS
+ Priority
+ Message Parts
+ Accessing STREAMS
o XSI Interprocess Communication
+ IPC General Description
o Realtime
+ Realtime Signals
+ Asynchronous I/O
+ Memory Management
# Memory Locking
# Memory Mapped Files
# Memory Protection
# Typed Memory Objects
+ Process Scheduling
# Scheduling Policies
# SCHED_FIFO
# SCHED_RR
# SCHED_SPORADIC
# SCHED_OTHER
+ Clocks and Timers
# Time Value Specification Structures
# Timer Event Notification Control Block
# Manifest Constants
# Execution Time Monitoring
o Threads
+ Thread-Safety
+ Thread IDs
+ Thread Mutexes
+ Thread Scheduling
# Thread Scheduling Attributes
# Thread Scheduling Contention Scope
# Scheduling Allocation Domain
# Scheduling Documentation
+ Thread Cancelation
# Cancelability States
# Cancelation Points
# Thread Cancelation Cleanup Handlers
# Async-Cancel Safety
+ Thread Read-Write Locks
+ Thread Interactions with Regular File Operations
+ Footnotes
o Sockets
+ Address Families
+ Addressing
+ Protocols
+ Routing
+ Interfaces
+ Socket Types
+ Socket I/O Mode
+ Socket Owner
+ Socket Queue Limits
+ Pending Error
+ Socket Receive Queue
+ Socket Out-of-Band Data State
+ Connection Indication Queue
+ Signals
+ Asynchronous Errors
+ Use of Options
+ Use of Sockets for Local UNIX Connections
# Headers
+ Use of Sockets over Internet Protocols
+ Use of Sockets over Internet Protocols Based on IPv4
# Headers
+ Use of Sockets over Internet Protocols Based on IPv6
# Addressing
# Compatibility with IPv4
# Interface Identification
# Options
# Headers
o Tracing
+ Tracing Data Definitions
# Structures
# posix_trace_status_info Structure
# posix_trace_event_info Structure
# Trace Stream Attributes
+ Trace Event Type Definitions
# System Trace Event Type Definitions
# User Trace Event Type Definitions
+ Trace Functions
o Data Types
* System Interfaces
o FD_CLR
o _Exit
o _longjmp
o _tolower
o _toupper
o a64l
o abort
o abs
o accept
o access
o acos
o acosh
o acosl
o aio_cancel
o aio_error
o aio_fsync
o aio_read
o aio_return
o aio_suspend
o aio_write
o alarm
o asctime
o asin
o asinh
o asinl
o assert
o atan
o atan2
o atanf
o atanh
o atanl
o atexit
o atof
o atoi
o atol
o basename
o bcmp
o bcopy
o bind
o bsd_signal
o bsearch
o btowc
o bzero
o cabs
o cacos
o cacosh
o cacosl
o calloc
o carg
o casin
o casinh
o casinl
o catan
o catanh
o catanl
o catclose
o catgets
o catopen
o cbrt
o ccos
o ccosh
o ccosl
o ceil
o cexp
o cfgetispeed
o cfgetospeed
o cfsetispeed
o cfsetospeed
o chdir
o chmod
o chown
o cimag
o clearerr
o clock
o clock_getcpuclockid
o clock_getres
o clock_nanosleep
o clock_settime
o clog
o close
o closedir
o closelog
o confstr
o conj
o connect
o copysign
o cos
o cosh
o cosl
o cpow
o cproj
o creal
o creat
o crypt
o csin
o csinh
o csinl
o csqrt
o ctan
o ctanh
o ctanl
o ctermid
o ctime
o daylight
o dbm_clearerr
o difftime
o dirname
o div
o dlclose
o dlerror
o dlopen
o dlsym
o drand48
o dup
o ecvt
o encrypt
o endgrent
o endhostent
o endnetent
o endprotoent
o endpwent
o endservent
o endutxent
o environ
o erand48
o erf
o erfc
o erff
o errno
o exec
o exit
o exp
o exp2
o expm1
o fabs
o fattach
o fchdir
o fchmod
o fchown
o fclose
o fcntl
o fcvt
o fdatasync
o fdetach
o fdim
o fdopen
o feclearexcept
o fegetenv
o fegetexceptflag
o fegetround
o feholdexcept
o feof
o feraiseexcept
o ferror
o fesetenv
o fesetexceptflag
o fesetround
o fetestexcept
o feupdateenv
o fflush
o ffs
o fgetc
o fgetpos
o fgets
o fgetwc
o fgetws
o fileno
o flockfile
o floor
o fma
o fmax
o fmin
o fmod
o fmtmsg
o fnmatch
o fopen
o fork
o fpathconf
o fpclassify
o fprintf
o fputc
o fputs
o fputwc
o fputws
o fread
o free
o freeaddrinfo
o freopen
o frexp
o fscanf
o fseek
o fsetpos
o fstat
o fstatvfs
o fsync
o ftell
o ftime
o ftok
o ftruncate
o ftrylockfile
o ftw
o funlockfile
o fwide
o fwprintf
o fwrite
o fwscanf
o gai_strerror
o gcvt
o getaddrinfo
o getc
o getc_unlocked
o getchar
o getchar_unlocked
o getcontext
o getcwd
o getdate
o getegid
o getenv
o geteuid
o getgid
o getgrent
o getgrgid
o getgrnam
o getgroups
o gethostbyaddr
o gethostent
o gethostid
o gethostname
o getitimer
o getlogin
o getmsg
o getnameinfo
o getnetbyaddr
o getopt
o getpeername
o getpgid
o getpgrp
o getpid
o getpmsg
o getppid
o getpriority
o getprotobyname
o getpwent
o getpwnam
o getpwuid
o getrlimit
o getrusage
o gets
o getservbyname
o getsid
o getsockname
o getsockopt
o getsubopt
o gettimeofday
o getuid
o getutxent
o getwc
o getwchar
o getwd
o glob
o gmtime
o grantpt
o h_errno
o hcreate
o htonl
o hypot
o iconv
o iconv_close
o iconv_open
o if_freenameindex
o if_indextoname
o if_nameindex
o if_nametoindex
o ilogb
o imaxabs
o imaxdiv
o index
o inet_addr
o inet_ntop
o initstate
o insque
o ioctl
o isalnum
o isalpha
o isascii
o isastream
o isatty
o isblank
o iscntrl
o isdigit
o isfinite
o isgraph
o isgreater
o isgreaterequal
o isinf
o isless
o islessequal
o islessgreater
o islower
o isnan
o isnormal
o isprint
o ispunct
o isspace
o isunordered
o isupper
o iswalnum
o iswalpha
o iswblank
o iswcntrl
o iswctype
o iswdigit
o iswgraph
o iswlower
o iswprint
o iswpunct
o iswspace
o iswupper
o iswxdigit
o isxdigit
o j0
o jrand48
o kill
o killpg
o l64a
o labs
o lchown
o lcong48
o ldexp
o ldiv
o lfind
o lgamma
o link
o lio_listio
o listen
o llabs
o lldiv
o llrint
o llround
o localeconv
o localtime
o lockf
o log
o log10
o log1p
o log2
o logb
o logf
o longjmp
o lrand48
o lrint
o lround
o lsearch
o lseek
o lstat
o makecontext
o malloc
o mblen
o mbrlen
o mbrtowc
o mbsinit
o mbsrtowcs
o mbstowcs
o mbtowc
o memccpy
o memchr
o memcmp
o memcpy
o memmove
o memset
o mkdir
o mkfifo
o mknod
o mkstemp
o mktemp
o mktime
o mlock
o mlockall
o mmap
o modf
o mprotect
o mq_close
o mq_getattr
o mq_notify
o mq_open
o mq_receive
o mq_send
o mq_setattr
o mq_timedreceive
o mq_timedsend
o mq_unlink
o mrand48
o msgctl
o msgget
o msgrcv
o msgsnd
o msync
o munlock
o munlockall
o munmap
o nan
o nanosleep
o nearbyint
o nextafter
o nftw
o nice
o nl_langinfo
o nrand48
o ntohl
o open
o opendir
o openlog
o optarg
o pathconf
o pause
o pclose
o perror
o pipe
o poll
o popen
o posix_fadvise
o posix_fallocate
o posix_madvise
o posix_mem_offset
o posix_memalign
o posix_openpt
o posix_spawn
o posix_spawn_file_actions_addclose
o posix_spawn_file_actions_adddup2
o posix_spawn_file_actions_addopen
o posix_spawn_file_actions_destroy
o posix_spawnattr_destroy
o posix_spawnattr_getflags
o posix_spawnattr_getpgroup
o posix_spawnattr_getschedparam
o posix_spawnattr_getschedpolicy
o posix_spawnattr_getsigdefault
o posix_spawnattr_getsigmask
o posix_spawnattr_init
o posix_spawnattr_setflags
o posix_spawnattr_setpgroup
o posix_spawnattr_setschedparam
o posix_spawnattr_setschedpolicy
o posix_spawnattr_setsigdefault
o posix_spawnattr_setsigmask
o posix_spawnp
o posix_trace_attr_destroy
o posix_trace_attr_getclockres
o posix_trace_attr_getinherited
o posix_trace_attr_getlogsize
o posix_trace_attr_getname
o posix_trace_attr_getstreamfullpolicy
o posix_trace_attr_getstreamsize
o posix_trace_attr_init
o posix_trace_attr_setinherited
o posix_trace_attr_setlogsize
o posix_trace_attr_setname
o posix_trace_attr_setstreamfullpolicy
o posix_trace_attr_setstreamsize
o posix_trace_clear
o posix_trace_close
o posix_trace_create
o posix_trace_event
o posix_trace_eventid_equal
o posix_trace_eventid_open
o posix_trace_eventset_add
o posix_trace_eventtypelist_getnext_id
o posix_trace_flush
o posix_trace_get_attr
o posix_trace_get_filter
o posix_trace_get_status
o posix_trace_getnext_event
o posix_trace_open
o posix_trace_set_filter
o posix_trace_shutdown
o posix_trace_start
o posix_trace_timedgetnext_event
o posix_trace_trid_eventid_open
o posix_trace_trygetnext_event
o posix_typed_mem_get_info
o posix_typed_mem_open
o pow
o pread
o printf
o pselect
o pthread_atfork
o pthread_attr_destroy
o pthread_attr_getdetachstate
o pthread_attr_getguardsize
o pthread_attr_getinheritsched
o pthread_attr_getschedparam
o pthread_attr_getschedpolicy
o pthread_attr_getscope
o pthread_attr_getstack
o pthread_attr_getstackaddr
o pthread_attr_getstacksize
o pthread_attr_init
o pthread_attr_setdetachstate
o pthread_attr_setguardsize
o pthread_attr_setinheritsched
o pthread_attr_setschedparam
o pthread_attr_setschedpolicy
o pthread_attr_setscope
o pthread_attr_setstack
o pthread_attr_setstackaddr
o pthread_attr_setstacksize
o pthread_barrier_destroy
o pthread_barrier_wait
o pthread_barrierattr_destroy
o pthread_barrierattr_getpshared
o pthread_barrierattr_init
o pthread_barrierattr_setpshared
o pthread_cancel
o pthread_cleanup_pop
o pthread_cond_broadcast
o pthread_cond_destroy
o pthread_cond_signal
o pthread_cond_timedwait
o pthread_condattr_destroy
o pthread_condattr_getclock
o pthread_condattr_getpshared
o pthread_condattr_init
o pthread_condattr_setclock
o pthread_condattr_setpshared
o pthread_create
o pthread_detach
o pthread_equal
o pthread_exit
o pthread_getconcurrency
o pthread_getcpuclockid
o pthread_getschedparam
o pthread_getspecific
o pthread_join
o pthread_key_create
o pthread_key_delete
o pthread_kill
o pthread_mutex_destroy
o pthread_mutex_getprioceiling
o pthread_mutex_init
o pthread_mutex_lock
o pthread_mutex_setprioceiling
o pthread_mutex_timedlock
o pthread_mutex_trylock
o pthread_mutexattr_destroy
o pthread_mutexattr_getprioceiling
o pthread_mutexattr_getprotocol
o pthread_mutexattr_getpshared
o pthread_mutexattr_gettype
o pthread_mutexattr_init
o pthread_mutexattr_setprioceiling
o pthread_mutexattr_setprotocol
o pthread_mutexattr_setpshared
o pthread_mutexattr_settype
o pthread_once
o pthread_rwlock_destroy
o pthread_rwlock_rdlock
o pthread_rwlock_timedrdlock
o pthread_rwlock_timedwrlock
o pthread_rwlock_tryrdlock
o pthread_rwlock_trywrlock
o pthread_rwlock_unlock
o pthread_rwlock_wrlock
o pthread_rwlockattr_destroy
o pthread_rwlockattr_getpshared
o pthread_rwlockattr_init
o pthread_rwlockattr_setpshared
o pthread_self
o pthread_setcancelstate
o pthread_setconcurrency
o pthread_setschedparam
o pthread_setschedprio
o pthread_setspecific
o pthread_sigmask
o pthread_spin_destroy
o pthread_spin_lock
o pthread_spin_unlock
o pthread_testcancel
o ptsname
o putc
o putc_unlocked
o putchar
o putchar_unlocked
o putenv
o putmsg
o puts
o pututxline
o putwc
o putwchar
o pwrite
o qsort
o raise
o rand
o random
o read
o readdir
o readlink
o readv
o realloc
o realpath
o recv
o recvfrom
o recvmsg
o regcomp
o remainder
o remove
o remque
o remquo
o rename
o rewind
o rewinddir
o rindex
o rint
o rmdir
o round
o scalb
o scalbln
o scanf
o sched_get_priority_max
o sched_getparam
o sched_getscheduler
o sched_rr_get_interval
o sched_setparam
o sched_setscheduler
o sched_yield
o seed48
o seekdir
o select
o sem_close
o sem_destroy
o sem_getvalue
o sem_init
o sem_open
o sem_post
o sem_timedwait
o sem_trywait
o sem_unlink
o sem_wait
o semctl
o semget
o semop
o send
o sendmsg
o sendto
o setbuf
o setcontext
o setegid
o setenv
o seteuid
o setgid
o setgrent
o sethostent
o setitimer
o setjmp
o setkey
o setlocale
o setlogmask
o setnetent
o setpgid
o setpgrp
o setpriority
o setprotoent
o setpwent
o setregid
o setreuid
o setrlimit
o setservent
o setsid
o setsockopt
o setstate
o setuid
o setutxent
o setvbuf
o shm_open
o shm_unlink
o shmat
o shmctl
o shmdt
o shmget
o shutdown
o sigaction
o sigaddset
o sigaltstack
o sigdelset
o sigemptyset
o sigfillset
o sighold
o siginterrupt
o sigismember
o siglongjmp
o signal
o signbit
o sigpause
o sigpending
o sigprocmask
o sigqueue
o sigrelse
o sigsetjmp
o sigsuspend
o sigtimedwait
o sigwait
o sigwaitinfo
o sin
o sinh
o sinl
o sleep
o snprintf
o sockatmark
o socket
o socketpair
o sprintf
o sqrt
o srand
o srand48
o srandom
o sscanf
o stat
o statvfs
o stdin
o strcasecmp
o strcat
o strchr
o strcmp
o strcoll
o strcpy
o strcspn
o strdup
o strerror
o strfmon
o strftime
o strlen
o strncasecmp
o strncat
o strncmp
o strncpy
o strpbrk
o strptime
o strrchr
o strspn
o strstr
o strtod
o strtoimax
o strtok
o strtol
o strtold
o strtoll
o strtoul
o strtoumax
o strxfrm
o swab
o swapcontext
o swprintf
o swscanf
o symlink
o sync
o sysconf
o syslog
o system
o tan
o tanh
o tanl
o tcdrain
o tcflow
o tcflush
o tcgetattr
o tcgetpgrp
o tcgetsid
o tcsendbreak
o tcsetattr
o tcsetpgrp
o tdelete
o telldir
o tempnam
o tfind
o tgamma
o time
o timer_create
o timer_delete
o timer_getoverrun
o times
o timezone
o tmpfile
o tmpnam
o toascii
o tolower
o toupper
o towctrans
o towlower
o towupper
o trunc
o truncate
o truncf
o tsearch
o ttyname
o twalk
o tzset
o ualarm
o ulimit
o umask
o uname
o ungetc
o ungetwc
o unlink
o unlockpt
o unsetenv
o usleep
o utime
o utimes
o va_arg
o vfork
o vfprintf
o vfscanf
o vfwprintf
o vfwscanf
o vprintf
o vscanf
o vsnprintf
o vsscanf
o vswprintf
o vswscanf
o vwprintf
o vwscanf
o wait
o waitid
o waitpid
o wcrtomb
o wcscat
o wcschr
o wcscmp
o wcscoll
o wcscpy
o wcscspn
o wcsftime
o wcslen
o wcsncat
o wcsncmp
o wcsncpy
o wcspbrk
o wcsrchr
o wcsrtombs
o wcsspn
o wcsstr
o wcstod
o wcstoimax
o wcstok
o wcstol
o wcstold
o wcstoll
o wcstombs
o wcstoul
o wcstoumax
o wcswcs
o wcswidth
o wcsxfrm
o wctob
o wctomb
o wctrans
o wctype
o wcwidth
o wmemchr
o wmemcmp
o wmemcpy
o wmemmove
o wmemset
o wordexp
o wprintf
o write
o writev
o wscanf
o y0

UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
[ Main Index | XBD | XCU | XSH | XRAT ]

Я устал привоидть эту ссылку. Где здесь асм, где Java? Где здесь что-то иное, кроме С???
Flex, извини, но мне твои попытки оспорить просто этот документ и все мои ссылки на него надоели.

Добавлено 21.07.06, 12:49

Цитата Flex Ferrum @ 21.07.06, 12:31

Вплоть до 6-го релиза часть раздела System Interface содержала лишь ссылки на соответствующие функции, описанные в ISO С 9899:1999.

Пляяяяяяяяяяяяяяять! Flex! Хорош прикалываться! Я уже тебе писал о 4-х уровнях соответствия стандарту POSIX. Заметь -- не стандарта POSIX, а стандарту POSIX. Это было здесь:

Цитата the_Shadow @ 20.07.06, 21:34

Всё здорово. Но сам по себе С основан на POSIX 1.x ("x" -- по причине того, что комитет меняет "номер версии"). Стандарт ISO 1003.1 описывает тот же POSIX 1.x, но на уровне международных организаций. Стандарт ANSI находится по уровню стандартов "чуть ниже", т.к. это не международный, а внутри-американский институт стандартизации. Хотя, ими принимается POSIX/ISO как основа, но они разрабатывают внутринациональные вещи.

Замечу, что четвёртым уровнем соответствия стандарту POSIX является сам стандарт + бибилиотеки расширения от коммерческих организаций и/или частных лиц.
Таким образом, ты будешь удивлён, но даже Win32 API в своей С-ипостаси под действие стандарта попадает в части синтаксиса.

Цитата

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи.

Здесь недурно было бы заметить, что ты брякнул бред.

Цитата the_Shadow @ 21.07.06, 12:43

Я устал привоидть эту ссылку. Где здесь асм, где Java? Где здесь что-то иное, кроме С???

Мда. Действительно, где тут С? Где описание синтаксиса языка, где описание операторов, их семантики? Где? В приведенном документе (он у меня открыт в соседнем окне) я вижу лишь описание кучи методов, которые стандартизирует POSIX. Так (исторически) сложилось, что описаны они на языке С. Потому что некоторая их часть (не скажу, что большая) пришла из CRTL (C Runtime Library). Аналогично, если мы откроем MSDN, мы увидем описание методов WinAPI на том же самом великом и могучем С. После чего с радостью возмемся утверждать, что документация на WinAPI описывает язык С (только на том основании, что других языков мы в этой документации не найдем).
Но читаем все в том же документе, ссылку на который ты мне

Цитата the_Shadow @ 21.07.06, 12:43

уже просто устал приводить

следующее:

Цитата Flex Ferrum @ 21.07.06, 12:20

The environment also supports a rich set of tools for application development.

Т. е. также (как и в случае с WinAPI) я могу разрабатывать приложения на любом удобном для меня языке. И это не будет противоречить никакому стандарту.

Цитата Flex Ferrum @ 21.07.06, 12:31

Я что-то упустил?

Ты мешаешь правду и собственные домыслы. Не более того. Следовательно... Коль скоро домыслы имеют место быть, в данном конкретном вопросе это -- не более чем домыслы.

Цитата linuxfan @ 21.07.06, 12:29

Что тебе больше нравится: namespace или static void do_something?

Привожу пример:

typedef int dumper_t(
    void *priv,     /* Private to the driver. */
    void *virtual,      /* Virtual (mapped) address. */
    vm_offset_t physical,   /* Physical address of virtual. */
    off_t offset,       /* Byte-offset to write at. */
    size_t length);     /* Number of bytes to dump. */
 
struct dumperinfo {
    dumper_t *dumper;   /* Dumping function. */
    void    *priv;      /* Private parts. */
    u_int   blocksize;  /* Size of block in bytes. */
    off_t   mediaoffset;    /* Initial offset in bytes. */
    off_t   mediasize;  /* Space available in bytes. */
};
 
void
dumpsys(struct dumperinfo *di)
{
  // Здесь мы сливаем потихонечку системную память в дампер
  // Дампер - типично функция, пишущая в своп корку
  //
  // Но можно переопределить, к примеру сделать запись в файл или
  // переслать через посл. шланг на другой комп
 
  // ...
  // да, передается di->priv (в C++ замест него будет this), но это только лишь неудачный пример:)
  error = di->dumper(di->priv, &kdh, 0, dumplo, sizeof(kdh));
  // ...
}

Ок, представь, что этот код надо немного усложнить. В di передается не один, а два и более указателей на функции.
При этом, эти указатели (в зависимости от ситуации) могут быть разными. Представим, что и в di->priv нет необходимости. Тогда мы получаем структуру для передачи данных в dumpsys и "статические виртуальные методы" - статические - т.к им не нужен this (внутри метода), и виртуальные, т.к указатели всё ж нам надо варьировать в зависимости от того, что мы хотим от dumpsys (дамп в своп, файл, посл. порт). Как отобразить это в C++? М.б темплиты подойдут?

Цитата linuxfan @ 21.07.06, 12:29

Да где два mov'а? По-любому надо указатель на instance для начала куда-нибудь положить и в результате имеем оверхед из одного mov'а для загрузки адреса vtbl.

this не нужен если, то 2 mov излишни.

Сообщение отредактировано: e-yes - 21.07.06, 12:55