Ivan Shmakov -> [email protected] @ Tue, 07 Oct 2014 17:15:44 +0000:
IS>> Что как бы намекает на то, что FILE отнюдь не opaque. AC>> Как минимум, используется он как opaque. Хотя на практике он, AC>> скорее всего, тоже уже устоялся, не менялся дцать лет, и может быть AC>> доступен открыто. IS> Смысл в том, что «непрозрачные указатели» C плохо совмещаются с IS> такими средствами языка, как inline и #define. Да. Реализация в _отдельной_ (в частности, отдельно заменяемой) библиотеке с такими средствами вообще не совмещается. AC>> Но тем не менее, в _API_ libc определения FILE нет. IS> Да, но это свойство документации, — не языка. Не библиотеки, скажем так. Это, гм, намек: если вы раскопали в хедерах определение FILE и начали им пользоваться - вы подложили грабли. Себе или тому, кто после вас будет это поддерживать. Повторюсь, FILE еще куда ни шло, это давно устоявшийся тип, не менявшийся дцать лет. И то, в общем, в man putc написано достаточно, чтобы без крайней необходимости им не пользоваться :) IS> Недокументированные типы, функции, переменные, etc. — возможны IS> совершенно в любой среде программирования. В отличие от IS> «непрозрачных». Начнем с того, что функции, типы и переменные, как недокументированные, так и документированные, возможны не в любой среде программирования :) А среди тех, где они возможны, я что-то не соображу ни одной, где невозможны "непрозрачные". Не подскажете? Да, существуют, возможно, конкретные библиотеки, в т.ч. довольно большие, построенные по прозрачной схеме. Особенно - шаблонные для C++, так уж там устроено это место в языке. Но, кажется, в той же STL тот же ввод-вывод все равно имеет непрозрачную часть. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
