powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
25 сообщений из 262, страница 8 из 11
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800184
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RWolfSashaMercury,

Всё, что начинается с двух подчёркиваний, зарезервировано стандартом под компилятороспецифичные идентификаторы.


Наконец-то я прочитал что-то про эти подчёркивания в литературе.

Diomidis SpinellisCode Reading: The Open Source Perspective 9.3.2 Namespaces
An important concept of a module is the principle of information hiding, prescribing that all information
related to a module should be private to it unless it is specifically declared to be public. In C modules
implemented as a single file you will find that global identifiers are declared with the static keyword to limit
their visibility to a single compilation unit (file).

Код: plaintext
1.
2.
3.
static int zlast = -1;
static void islogin(void);
static void reexecute(struct command *);



However, this technique does not prevent identifiers used in header files from leaking to the files that include them. As an example, in the
C and C++ language a typedef or a preprocessor macro definition in a header file may result in a clash when another file defines a global
function or variable with the same name. Although some cases can be solved by renaming the offending identifier in the program being
developed, others, where two different existing modules clash with each other, can be difficult to solve since they may not fall under the
developer's control. Consider the (contrived) example of compiling the following code.

Код: plaintext
1.
2.
#include "libz/zutil.h"
#include "libc/regex/utils.h"



The two header files included both define a uch identifier, thus creating the following error.

libc/regex/utils.h:46: redefinition of `uch'
libz/zutil.h:36: `uch' previously declared here


This problem of namespace pollution is solved in a number of ad hoc ways in the C language; other
languages like Ada, C++, Eiffel, Java, Perl, and the Modula family provide specific constructs for
combatting this problem. A common solution for curbing the namespace pollution, without the need for
additional language-provided facilities, involves prefixing identifiers with a certain unique prefix. Notice how
in the example below all type, function, and macro identifiers of the rnd.h header file are prefixed with
an rnd prefix.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
void rnd_attach_source(rndsource_element_t *,char*,u_int32_t);
void rnd_detach_source(rndsource_element_t *);
[...]
#define RND_MAXSTATCOUNT 10 /* 10 sources at once max */
[...]
typedef struct {
u_int32_t start;
u_int32_t count;
rndsource_t source[RND_MAXSTATCOUNT];
}rndstat_t;




In fact, the prefix method of identifier isolation is officially sanctioned by the ANSI C standard by reserving
all identifiers starting with an underscore character (_) for use by the language implementation. When
reading a library header you will notice that all identifiers start with an underscore, thus being kept
separated from any identifiers a user might define.


Код: plaintext
1.
2.
3.
4.
struct –––sbuf {
unsigned char *_base;
int _size;
};



Although in the above example the _base and _size structure tags belong—according to ANSI C—in a separate namespace (that of the
__sbuf structure tags), they still need to be prefixed with an underscore since they might clash with macro definitions.
To avoid the problems we described above you will find that modern C++ programs often make use of the namespace functionality.

Таким образом, это искусственный элемент. Используете ли вы префиксы в своей работе ?
(провёл аналогию с БД, мне например не нравится когда к атрибутам отношения добавляют префикс, не вижу в этом смыла, хотя возможно просто чего-то не знаю)

Хотя, в данном случае, дело не в нравится/не нравится, а в необходимости связанной с ODR(One Definiton Rule).
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800185
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Последний участок кода неккоректен


Код: plaintext
1.
2.
3.
4.
struct __sbuf {
unsigned char *_base;
int _size;
};
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800188
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryТаким образом, это искусственный элемент. Используете ли вы префиксы в своей работе ?
Вы все не так поняли.
Программистам запрещено объявлять имена с префиксом из "_".
Только создатели компилятора имеют право это делать при реализации стандартных библиотек.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800189
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskySashaMercuryТаким образом, это искусственный элемент. Используете ли вы префиксы в своей работе ?
Вы все не так поняли.
Программистам запрещено объявлять имена с префиксом из "_".
Только создатели компилятора имеют право это делать при реализации стандартных библиотек.

сейчас я выполнил вот такой код

Код: plaintext
1.
2.
3.
4.
5.
6.
int _c = 100;

int main(int argc, char** argv)
{
		printf("%i", _c);
}



Хотя то, о чём вы говорите, я прочитал
DSIn fact, the prefix method of identifier isolation is officially sanctioned by the ANSI C standard by reserving
all identifiers starting with an underscore character (_) for use by the language implementation.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800196
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryсейчас я выполнил вот такой код

Код: plaintext
1.
2.
3.
4.
5.
6.
int _c = 100;

int main(int argc, char** argv)
{
		printf("%i", _c);
}


Вы должны уже понимать разницу между юридическими законами и законами физики.
Здесь речь про первые :)
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800198
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

понял что это юридические правила. Спасибо :)

Об этом действительно написано в стандарте? Поищу. Вы используете префиксы ради ODR в своих программах ?
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800203
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskySashaMercuryТаким образом, это искусственный элемент. Используете ли вы префиксы в своей работе ?
Вы все не так поняли.
Программистам запрещено объявлять имена с префиксом из "_".
Только создатели компилятора имеют право это делать при реализации стандартных библиотек.

Теперь я полностью понял вашу мысль.

Вот как я понял, то что там написано. "Для того чтобы ограничить область видимости некоторых идентификаторов(для исключения конфликтов в части ODR) существует квалификатор static. Однако, он не помогает, когда программист использует директиву препроцессора #include и включает один файл в другой. По этой причине был искусственно введена префиксная система к идентификаторам каждого конкретного файла. Для встроенных библиотек, например, используется префикс _ или __(для структур). Для других файлов, префикс устанавливается на усмотрение программиста(желательно не использовать _ и __)".


Вы, как мне теперь понятно, говорите что я всё не так понял, и нужно лишь знать то, что _ и __ префиксы идентификаторов во встроенных библиотеках языка. И про проблему ODR (т.е. то для чего нужны эти префиксы), вы не говорите. Т.е. вы не связываете эти префиксы с ODR. Раз у вас различное мнение с автором книги, то с большой долей вероятности, у меня есть ошибка в рассуждениях и понимании вас и автора, где она ? Объясните пожалуйста
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800204
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Поискал в стандарте, и не нашёл где было бы написано о каких-либо соглашениях касаемо имён. Плохо искал ?
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800206
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryПоискал в стандарте, и не нашёл где было бы написано о каких-либо соглашениях касаемо имён. Плохо искал ?

соглашения то есть конечно, а вот конкретно про _ и __ ничего не нашёл.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800207
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury,

По стандартам С и С++ в юзерской программе не может быть двойных подчеркиваний и одиночных подчеркиваний перед заглавными буквами. Других ограничений на подчеркивания нет.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800209
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Про другие ограничения я поторопился.

С117.1.3 Reserved identifiers
...
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.
— All identifiers that begin with an underscore are always reserved for use as identifiers
with file scope in both the ordinary and tag name spaces.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800210
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В вот в С++
С++1117.6.4.3.3
Global names
Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.175
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800211
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В С и С++ хоть по разному записано, но означает одно и то же.
Префиксы "_" и "__" - зарезервированы для компилятора, и не дозволяются в юзерских именах.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800212
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyПро другие ограничения я поторопился.

С117.1.3 Reserved identifiers
...
— All identifiers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.
— All identifiers that begin with an underscore are always reserved for use as identifiers
with file scope in both the ordinary and tag name spaces.


нашёл. Значит это не юридические правила, а физические правила. Просто VS их не выполняет(реализовал компилятор Си, не выполнив все требования стандарта), правильно ?
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800213
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryЗначит это не юридические правила, а физические правила
Физические законы не требуют формулирования, они выполняются в любом случае.
А тут именно юридически запрещено.
Как например запрещено воровство законами УК, и даже если сейф закрыт на замок и воровство из него невозможно, то это не значит что воровать запрещено физическими законами. Просто пока не удалось взломать сейф :)
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800215
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

вот смотрите , я напишу такой код

Код: plaintext
1.
2.
char* a;
int* a;



у нас будет redefinition, и это написано в стандарте. Программа не запустится. Стандарт это свод законов описывающих язык. Значит это невозможно физически. Аналогично и с underscore.

А вот законы негласные, касаемо читабельности кода, именованию переменных, организации полуоткрытых справа интервалов,etc это уже юридические законы грамотного Си-программиста. Вот как я больше понимаю разницу между физическими и юридическими законами в части программирования на Си. Потому, мне кажется, тут недоработка разработчиков VS. Они не до конца реализовали естественную физическую среду Си.


Хотя ваш подход, также уместен, и я его принимаю. Можно рассуждать что это свод законов, юридических. А то что VS их не выполняет, это наши проблемы. Мы всё равно не должны брать деньги из открытого сейфа. А физическими законами тогда что будет ? Или будут только юридические
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800217
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryИли будут только юридические
Конечно. Ведь стандарт - это юридический документ.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800218
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

хорошо. Это я тоже принимаю
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800219
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury,

То что компилятор пропускает _ в юзерской программе имеет вполне разумное объяснение.
Для компилятора нет четкой грани между кодом программы, где запрещено, и кодом стандартной библиотеки, где разрешено.
Поэтому проконтролировать выполнение правила нельзя.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800222
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

Си имеет фиксированное стандартом количество встроенных библиотек с фиксированными именами?
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800269
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SSAnatoly Moskovsky,

Си имеет фиксированное стандартом количество встроенных библиотек с фиксированными именами?

Думаю, да. Однако вывод который я хотел ранее сказать-"почему бы не проверять имена компилируемых файлов, и исходя из этого либо разрешать либо запрещать префиксы _ и __ ".
Но этот вывод будет неправильным, ибо задача компилятора не проверять имена компилируемых файлов, а компилировать исходный код.
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800270
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskySashaMercury,

То что компилятор пропускает _ в юзерской программе имеет вполне разумное объяснение.
Для компилятора нет четкой грани между кодом программы, где запрещено, и кодом стандартной библиотеки, где разрешено.
Поэтому проконтролировать выполнение правила нельзя.

а это значит, что данный вывод правильный. Спасибо :)
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38800654
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercurySSAnatoly Moskovsky,
Си имеет фиксированное стандартом количество встроенных библиотек с фиксированными именами?Думаю, да.Не надо думать. Надо смотреть вокруг, а не просто втыкать текст стандарта:
Windows SDK
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
/*++ BUILD Version: 0001    // Increment this if a change has global effects

Copyright (c) 1993-1999, Microsoft Corporation

Module Name:

    aclapi.h

Abstract:

    Public
    Structure/constant definitions and typedefines for the Win32 Access
    Control APIs

--*/
#ifndef __ACCESS_CONTROL_API__
#define __ACCESS_CONTROL_API__

#include <windows.h>
#include <accctrl.h>

#ifdef __cplusplus
extern "C" {
#endif

//
// Progress Function:
// Caller of tree operation implements this Progress function, then
// passes its function pointer to tree operation.
// Tree operation invokes Progress function to provide progress and error
// information to the caller during the potentially long execution
// of the tree operation.  Tree operation provides the name of the object
// last processed and the error status of the operation on that object.
// Tree operation also passes the current InvokeSetting value.
// Caller may change the InvokeSetting value, for example, from "Always"
// to "Only On Error."
//

typedef VOID (*FN_PROGRESS) (
    __in LPWSTR                     pObjectName,    // name of object just processed
    __in DWORD                      Status,         // status of operation on object
    __inout PPROG_INVOKE_SETTING    pInvokeSetting, // Never, always,
    __in PVOID                      Args,           // Caller specific data
    __in BOOL                       SecuritySet     // Whether security was set
    );


llvm clang
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
/*===---- cpuid.h - X86 cpu model detection --------------------------------===
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 *
 *===-----------------------------------------------------------------------===
 */

#if !(__x86_64__ || __i386__)
#error this header is for x86 only
#endif

/* Features in %ecx for level 1 */
#define bit_SSE3        0x00000001
#define bit_PCLMULQDQ   0x00000002
#define bit_DTES64      0x00000004
#define bit_MONITOR     0x00000008
#define bit_DSCPL       0x00000010
#define bit_VMX         0x00000020
#define bit_SMX         0x00000040
#define bit_EIST        0x00000080
#define bit_TM2         0x00000100
#define bit_SSSE3       0x00000200
#define bit_CNXTID      0x00000400
#define bit_FMA         0x00001000
#define bit_CMPXCHG16B  0x00002000
#define bit_xTPR        0x00004000
#define bit_PDCM        0x00008000
#define bit_PCID        0x00020000
#define bit_DCA         0x00040000
#define bit_SSE41       0x00080000
#define bit_SSE42       0x00100000
#define bit_x2APIC      0x00200000
#define bit_MOVBE       0x00400000
#define bit_POPCNT      0x00800000
#define bit_TSCDeadline 0x01000000
#define bit_AESNI       0x02000000
#define bit_XSAVE       0x04000000
#define bit_OSXSAVE     0x08000000
#define bit_AVX         0x10000000
#define bit_RDRAND      0x40000000

/* Features in %edx for level 1 */
#define bit_FPU         0x00000001
#define bit_VME         0x00000002
#define bit_DE          0x00000004
#define bit_PSE         0x00000008
#define bit_TSC         0x00000010
#define bit_MSR         0x00000020
#define bit_PAE         0x00000040
#define bit_MCE         0x00000080
#define bit_CX8         0x00000100
#define bit_APIC        0x00000200
#define bit_SEP         0x00000800
#define bit_MTRR        0x00001000
#define bit_PGE         0x00002000
#define bit_MCA         0x00004000
#define bit_CMOV        0x00008000
#define bit_PAT         0x00010000
#define bit_PSE36       0x00020000
#define bit_PSN         0x00040000
#define bit_CLFSH       0x00080000
#define bit_DS          0x00200000
#define bit_ACPI        0x00400000
#define bit_MMX         0x00800000
#define bit_FXSR        0x01000000
#define bit_FXSAVE      bit_FXSR    /* for gcc compat */
#define bit_SSE         0x02000000
#define bit_SSE2        0x04000000
#define bit_SS          0x08000000
#define bit_HTT         0x10000000
#define bit_TM          0x20000000
#define bit_PBE         0x80000000

/* Features in %ebx for level 7 sub-leaf 0 */
#define bit_FSGSBASE    0x00000001
#define bit_SMEP        0x00000080
#define bit_ENH_MOVSB   0x00000200

/* PIC on i386 uses %ebx, so preserve it. */
#if __i386__
#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \
    __asm("  pushl  %%ebx\n" \
          "  cpuid\n" \
          "  mov    %%ebx,%1\n" \
          "  popl   %%ebx" \
        : "=a"(__eax), "=r" (__ebx), "=c"(__ecx), "=d"(__edx) \
        : "0"(__level))

#define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \
    __asm("  pushl  %%ebx\n" \
          "  cpuid\n" \
          "  mov    %%ebx,%1\n" \
          "  popl   %%ebx" \
        : "=a"(__eax), "=r" (__ebx), "=c"(__ecx), "=d"(__edx) \
        : "0"(__level), "2"(__count))
#else
#define __cpuid(__level, __eax, __ebx, __ecx, __edx) \
    __asm("cpuid" : "=a"(__eax), "=b" (__ebx), "=c"(__ecx), "=d"(__edx) \
                  : "0"(__level))

#define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \
    __asm("cpuid" : "=a"(__eax), "=b" (__ebx), "=c"(__ecx), "=d"(__edx) \
                  : "0"(__level), "2"(__count))
#endif

static __inline int __get_cpuid (unsigned int __level, unsigned int *__eax,
                                 unsigned int *__ebx, unsigned int *__ecx,
                                 unsigned int *__edx) {
    __cpuid(__level, *__eax, *__ebx, *__ecx, *__edx);
    return 1;
}

static __inline int __get_cpuid_max (unsigned int __level, unsigned int *__sig)
{
    unsigned int __eax, __ebx, __ecx, __edx;
#if __i386__
    int __cpuid_supported;

    __asm("  pushfl\n"
          "  popl   %%eax\n"
          "  movl   %%eax,%%ecx\n"
          "  xorl   $0x00200000,%%eax\n"
          "  pushl  %%eax\n"
          "  popfl\n"
          "  pushfl\n"
          "  popl   %%eax\n"
          "  movl   $0,%0\n"
          "  cmpl   %%eax,%%ecx\n"
          "  je     1f\n"
          "  movl   $1,%0\n"
          "1:"
        : "=r" (__cpuid_supported) : : "eax", "ecx");
    if (!__cpuid_supported)
        return 0;
#endif

    __cpuid(__level, __eax, __ebx, __ecx, __edx);
    if (__sig)
        *__sig = __ebx;
    return __eax;
}

...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38801032
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,

не могли бы вы объяснить, что вы хотите сказать, для "особо одарённых"
...
Рейтинг: 0 / 0
INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
    #38801054
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryBasil A. Sidorov,

не могли бы вы объяснить, что вы хотите сказатьон хочет сказать, что, хотя WinSDK и не является частью стандартной библиотеки С, там всё же используются идентификаторы, начинающиеся с __ и с _Большая-буква. Равно, как и в некоторых других библиотеках.
Вывод: в прикладном коде лучше не использовать такие идентификаторы в глобальном пространстве имён, а вот в общеупотребительных библиотеках - это наоборот, вполне допустимая практика, и более того, желательная
...
Рейтинг: 0 / 0
25 сообщений из 262, страница 8 из 11
Форумы / C++ [игнор отключен] [закрыт для гостей] / INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:201x Вопросы и комментарии
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]