2009-03-15 1 views

ответ

19

Предполагается, что функции, не указанные в стандарте, должны иметь префикс подчеркивания как указание на то, что они являются расширениями, специфичными для поставщика, или придерживаются стандарта, отличного от ISO. Таким образом, «соблюдение» здесь означало, что Microsoft добавляет символ подчеркивания к названию этой конкретной функции, поскольку она не входит в стандарт ISO.

+1

У них есть своя работа, конвертирующая Windows API :-) – 2009-03-15 12:21:40

+4

Я не думаю, что кто-либо утверждал, что Win32 API был совместим с чем угодно. windows.h даже не компилируется, если вы отключите языковые расширения в VC++. :) – jalf

+1

Путаница заключается в том, что они сделали это для создания функций, которые не были также в стандартных заголовках C. –

3

Насколько я знаю, getcwd() никогда не был частью стандарта ISO C++. _getcwd() определенно нет, поскольку стандартные имена не начинаются с подчеркивания.

На самом деле статья MSDN ссылается на страницу руководства, в которой говорится, что она объявлена ​​в direct.h, которая не является стандартным файлом заголовка C++. Статья кажется мне фиктивной.

3

Чтобы добавить к сообщению Dan Олсона: Смотрите ANSI C Compliance страницу на MSDN

Названия Microsoft специфические функции и глобальные переменные начинаются с одного подчеркивания. Эти имена могут быть переопределены только локально, в пределах вашего кода. Например, когда вы включаете файлы заголовков времени выполнения Microsoft, вы все равно можете локально переопределить определенную Microsoft функцию с именем _open, объявив локальную переменную с тем же именем. Однако вы не можете использовать это имя для своей собственной глобальной функции или глобальной переменной.

4

Как и другие уже указывали, getcwd не включен в ISO C++, но является частью POSIX/IEEE Std 1003.1.

Корпорация Майкрософт решила включить некоторые из наиболее часто используемых функций POSIX в свою стандартную библиотеку C (но префикс этих функций подчеркивает, что в основном препятствует их использованию).

23

Об этом есть good discussion. P.J. Plauger ответы на этот

Я парень, который настаивал в 1983 году, что пространство имен, доступных в программе C можно разбить на:

а), определенные реализации для выгода от программиста (такие, как Printf)
б) тех, которые зарезервированы для программиста (такие, как Foo)
с) тех, которые зарезервированы для реализации (например, как _unlink)

Мы знали, что даже тогда, что «реализация» была слишком монолитна - часто более одного источника поставляет биты реализации - , но это было лучшее, что мы могли бы сделать в то время. Стандарт C++ ввел пространства имен, чтобы помочь, но они достигли лишь доли заявленных целей. (Это то, что происходит, когда вы стандартизировать бумажный тигр.)

В данном конкретном случае, Posix предоставляет список категории (а) имена (например, ссылки на), что вы должны получить определенные тогда и только тогда, когда вы включаете некоторые заголовки.Поскольку C-стандарт украл свои заголовки от Unix, который является тем же источником, что и для Posix, некоторые из этих заголовков исторически перекрываются. Тем не менее, предупреждения компилятора должны иметь какой-либо способ учета того, поддерживается ли поддерживаемая среда «чистым» стандартным C++ (идеалом Платона) или смешанной средой C/C++/Posix . Нынешняя попытка Microsoft помочь нам бедным программистам не учитывает это. Он настаивает на лечении unlink как категории (b), которое является близоруким.

Ну, GCC не будет объявлять имена POSIX в строгом режиме C, по крайней мере (хотя, это все еще происходит в режиме С ++):

#include <stdio.h> 

int main() { 
    &fdopen; 
    return 0; 
} 

Выход с использованием -std=c99

test.c: In function 'main': 
test.c:4: error: 'fdopen' undeclared (first use in this function) 

You должен будет прямо сказать, что вы работаете в смешанном C/Posix, используя макросы для тестирования функций или не передавая какой-либо конкретный стандарт. Затем он будет по умолчанию равен gnu89, который предполагает смешанную среду (man feature_test_macros). По-видимому, у MSVC нет такой возможности.

+3

GCC не объявляет POSIX или даже стандартные имена C. Это задача glibc. – Potatoswatter

2

Для записи getcwd() не устарел от ISO. Microsoft «устарела». Microsoft переписала множество функций C - часто с учетом немного лучшей безопасности (скажем, строковых функций, которые также принимают параметр max_length). Затем у них был компилятор, который выдал эти предупреждения, которые я считаю фиктивными, потому что ни одна из групп стандартов не осуждала какую-либо из функций, объявленных устаревшими.

+8

_CRT_SECURE_NO_WARNINGS и забыть :) –

+0

Вопрос: «Почему getcwd() не соответствует ISO?/В этой статье MSDN указано, что getcwd() устарел ...» Ответ: «getcwd() не устарел, Microsoft плюет из-за странного определения «устарело». Как это не отвечает на вопрос? Каким образом я просил разъяснений? –

+0

'getcwd()' тоже устарел от GNU.См. Справочную страницу «Для удобства переноски и безопасности использование getwd() устарело». –

3

Статья MSDN несколько сбивает с толку то, что нормальный человек сделал бы из просто быстрого чтения (если они не читают его с очень осторожным глазом адвоката).

Что говорится в статье MSDN: getcwd() не соответствует стандарту ISO C++. Чтобы соответствовать этому стандарту ISO C++ для именования функций (что является нарушением getcwd), Microsoft правильно помещает _ на фронт функции, поэтому одна и та же функция становится _getcwd(). Это ISO-совместимый способ именования функции, потому что getcwd() и _getcwd() не являются стандартной функцией стандарта ISO C++, а специфичной для Microsoft (поставщика) или специфичной для реализации.

В статье не указано, какой стандартный вызов C++ ISO для получения рабочего каталога будет ... хотя это то, что люди, как правило, читают с быстрым взглядом.

 Смежные вопросы

  • Нет связанных вопросов^_^