Re: [OT] opaque pointer
yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Wed, 8 Oct 2014
01:25:38 +0400 (MSK):
>> Впрочем, по сути это тот же самый хак, который позволяет
>>
>> void f (int n) {
>>something var[n];
>> }
y> Почему же хак? Variable length array входят в стандарт С99.
Потому что работает в ограниченных условиях.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnpmalty@wizzle.ran.pp.ru
Re: [OT] opaque pointer
On Wed, 8 Oct 2014, Artem Chuprina wrote:
Впрочем, по сути это тот же самый хак, который позволяет
void f (int n) {
something var[n];
}
Почему же хак? Variable length array входят в стандарт С99.
Ю.
Re: [OT] opaque pointer
Ivan Shmakov -> debian-russian@lists.debian.org @ Tue, 07 Oct 2014 19:05:53 +: IS>> Недокументированные типы, функции, переменные, etc. — возможны IS>> совершенно в любой среде программирования. В отличие от IS>> «непрозрачных». AC>> Начнем с того, что функции, типы и переменные, как AC>> недокументированные, так и документированные, возможны не в любой AC>> среде программирования :) AC>> А среди тех, где они возможны, я что-то не соображу ни одной, где AC>> невозможны "непрозрачные". Не подскажете? IS>ISTR, что отдельные «простые» интерпретаторы диалектов Lisp IS>позволяли интроспекцию «любых данных и в любую сторону». Ок, убедил. IS>Да, BCP в отношении передачи «непрозрачных» указателей «в Perl и IS>обратно» в свое время мне также найти не удалось. В перле как языке указателей нет. А вот если начать интроспектировать, скажем, ссылки, с которыми работает DBI, то подозреваю, что очень быстро наткнешься на непрозрачный указатель, через который работают с нижележащей сишной библиотекой. P.S. Кстати, в голову пришел хороший пример непрозрачного int: file descriptor функций ввода-вывода нижнего уровня (интерфейс к ядру). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iojvab68@wizzle.ran.pp.ru
Re: [OT] opaque pointer
yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Tue, 7 Oct 2014 23:03:24 +0400 (MSK): >> Смысл в том, что «непрозрачные указатели» C плохо совмещаются с >> такими средствами языка, как inline и #define. y> Вроде бы для inline должно все работать при правильном описании [1]. y> При вызова из другого файла будет работать как обычная функция. y> (Stand-alone object code is emitted (just like a normal function) y> and can be called from other translation units in your program.) y> Я что-то упускаю? Ты упускаешь то, для чего вообще придумали inline. just like a normal function - это со всеми накладными расходами на function call. То есть работать-то будет, но в скорости проиграет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw97abk7@wizzle.ran.pp.ru
Re: [OT] opaque pointer
yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Tue, 7 Oct 2014
22:24:02 +0400 (MSK):
>> y> Что-то я вас не понимаю (с).
>> y> Сами же написали: «sizeof(int[n]) преобразуется в нечто
>> y> вроде n*sizeof(int)». Это n* и выполняется в run time.
>>
>> n* - да, а sizeof - нет. С чем ты споришь?
>>
y> Еще раз:
y> int temp[n];
y> sizeof(temp);
y> sizeof(temp) вычисляется как n*4 в run time,
y> и n я могу задавать из командной строки.
y> Следовательно sizeof() преобразуется в выражение
y> которое вычисляется во время исполнения.
Ну, ок. Хотя это все-таки обман трудящихся. В смысле, не честное
вычисление памяти, занимаемой данными, в рантайме (что в модели C
невозможно), а хак, который может сработать, а может и нет. Правда,
расскажут об этом уже во время компиляции.
Впрочем, по сути это тот же самый хак, который позволяет
void f (int n) {
something var[n];
}
а этот хак - в стандарте.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3yjabns@wizzle.ran.pp.ru
Re: [OT] opaque pointer
> "AC" == Artem Chuprina writes: > Ivan Shmakov -> debian-russian@lists.debian.org: […] AC> Но тем не менее, в _API_ libc определения FILE нет. IS> Да, но это свойство документации, — не языка. AC> Не библиотеки, скажем так. Это, гм, намек: если вы раскопали в AC> хедерах определение FILE и начали им пользоваться - вы подложили AC> грабли. Себе или тому, кто после вас будет это поддерживать. … При этом, если конкретный тип действительно является incomplete, то на этапе сборки получим диагностируемую реализацией языка ошибку. Что и происходит при использовании отдельных типов отдельных библиотек. Но именно FILE из именно GNU Libc — не из их числа. […] IS> Недокументированные типы, функции, переменные, etc. — возможны IS> совершенно в любой среде программирования. В отличие от IS> «непрозрачных». AC> Начнем с того, что функции, типы и переменные, как AC> недокументированные, так и документированные, возможны не в любой AC> среде программирования :) AC> А среди тех, где они возможны, я что-то не соображу ни одной, где AC> невозможны "непрозрачные". Не подскажете? ISTR, что отдельные «простые» интерпретаторы диалектов Lisp позволяли интроспекцию «любых данных и в любую сторону». Да, BCP в отношении передачи «непрозрачных» указателей «в Perl и обратно» в свое время мне также найти не удалось. […] -- FSF associate member #7257 np. Вселенская большая любовь — Гражданская Оборона -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw974s4u@violet.siamics.net
Re: [OT] opaque pointer
On Tue, 7 Oct 2014, Ivan Shmakov wrote: Смысл в том, что «непрозрачные указатели» C плохо совмещаются с такими средствами языка, как inline и #define. Вроде бы для inline должно все работать при правильном описании [1]. При вызова из другого файла будет работать как обычная функция. (Stand-alone object code is emitted (just like a normal function) and can be called from other translation units in your program.) Я что-то упускаю? Ю. [1] http://www.greenend.org.uk/rjk/tech/inline.html
Re: [OT] opaque pointer
On Tue, 7 Oct 2014, Artem Chuprina wrote: y> Что-то я вас не понимаю (с). y> Сами же написали: «sizeof(int[n]) преобразуется в нечто y> вроде n*sizeof(int)». Это n* и выполняется в run time. n* - да, а sizeof - нет. С чем ты споришь? Еще раз: int temp[n]; sizeof(temp); sizeof(temp) вычисляется как n*4 в run time, и n я могу задавать из командной строки. Следовательно sizeof() преобразуется в выражение которое вычисляется во время исполнения. Ю.
Re: [OT] opaque pointer
yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Tue, 7 Oct 2014 21:13:08 +0400 (MSK): Коллеги, sizeof вычисляется во время компиляции. Всегда. Денис >>> >>> Почему? В любом компиляторе? >> >> Ну, как тебе сказать... Эта штука принимает в качестве параметра >> _тип_. Поскольку с символами язык Си работать не умеет, единственное, >> что разумно предположить - это то, что sizeof есть некая особая >> конструкция, которая раскрывается на этапе свёртывания АСД компилятором. y> Что-то я вас не понимаю (с). y> Сами же написали: «sizeof(int[n]) преобразуется в нечто y> вроде n*sizeof(int)». Это n* и выполняется в run time. n* - да, а sizeof - нет. С чем ты споришь? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mvfbw58@wizzle.ran.pp.ru
Re: [OT] opaque pointer
Ivan Shmakov -> debian-russian@lists.debian.org @ Tue, 07 Oct 2014 17:15:44 +: 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 debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878ukrbw7a@wizzle.ran.pp.ru
Re: [OT] opaque pointer
> "AC" == Artem Chuprina writes: > Ivan Shmakov -> debian-russian@lists.debian.org: […] IS> Что как бы намекает на то, что FILE отнюдь не opaque. AC> Как минимум, используется он как opaque. Хотя на практике он, AC> скорее всего, тоже уже устоялся, не менялся дцать лет, и может быть AC> доступен открыто. Смысл в том, что «непрозрачные указатели» C плохо совмещаются с такими средствами языка, как inline и #define. AC> Но тем не менее, в _API_ libc определения FILE нет. Да, но это свойство документации, — не языка. Недокументированные типы, функции, переменные, etc. — возможны совершенно в любой среде программирования. В отличие от «непрозрачных». -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbnv4x8f@violet.siamics.net
Re: [OT] opaque pointer
On Tue, 7 Oct 2014, Dmitrii Kashin wrote: yuri.nefe...@gmail.com writes: On Tue, 7 Oct 2014, Денис Ильин wrote: Коллеги, sizeof вычисляется во время компиляции. Всегда. Денис Почему? В любом компиляторе? Ну, как тебе сказать... Эта штука принимает в качестве параметра _тип_. Поскольку с символами язык Си работать не умеет, единственное, что разумно предположить - это то, что sizeof есть некая особая конструкция, которая раскрывается на этапе свёртывания АСД компилятором. Что-то я вас не понимаю (с). Сами же написали: «sizeof(int[n]) преобразуется в нечто вроде n*sizeof(int)». Это n* и выполняется в run time. Мое понимание, на настоящий момент, что компилятор вместо sizeof подставляет либо константу, либо, в случае типа содержащего массивы переменной длинны, простое выражение зависящее от размеров массивов. Ю.
Re: [OT] opaque pointer
Денис Ильин -> Artem Chuprina @ Tue, 07 Oct 2014 18:01:30 +0400: ДИ> Коллеги, sizeof вычисляется во время компиляции. Всегда. Коллега, а никак нельзя сделать так, чтобы Ваши письма НЕ приходили 1) в ответ на то письмо, к которому они не относятся (хотя и относятся к той же теме дискуссии); 2) плюс еще и автору в личную почту, помимо рассылки; 3) в двух и более экземплярах? Я уж молчу про топ-квотинг... ДИ> Денис ДИ> ДИ> 07.10.2014, 17:45, "Artem Chuprina" : ДИ> Ivan Shmakov -> debian-russian@lists.debian.org @ Tue, 07 Oct 2014 12:47:49 +: ДИ> ДИ> AC>> Называется этот прием "непрозрачный указатель" (opaque pointer), ДИ> AC>> иногда говорят "непрозрачная структура" (opaque structure) и ДИ> AC>> используется в хвост и в гриву, начиная с libc (FILE *). ДИ> ДИ> IS> Зависит. Вот, к примеру, в [1] находим: ДИ> ДИ> Function: int putc (int c, FILE *stream) ДИ> This is just like fputc, except that most systems implement it as a ДИ> macro, making it faster. […] ДИ> ДИ> IS> Что как бы намекает на то, что FILE отнюдь не opaque. ДИ> ДИ> Как минимум, используется он как opaque. Хотя на практике он, скорее ДИ> всего, тоже уже устоялся, не менялся дцать лет, и может быть доступен ДИ> открыто. ДИ> ДИ> Но тем не менее, в _API_ libc определения FILE нет. ДИ> -- ДИ> To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org ДИ> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org ДИ> Archive: https://lists.debian.org/87sij0at97@wizzle.ran.pp.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k34bc1pc@wizzle.ran.pp.ru
Re: [OT] opaque pointer
yuri.nefe...@gmail.com writes: > On Tue, 7 Oct 2014, Денис Ильин wrote: > >> Коллеги, sizeof вычисляется во время компиляции. Всегда. >> >> Денис > > Почему? В любом компиляторе? Ну, как тебе сказать... Эта штука принимает в качестве параметра _тип_. Поскольку с символами язык Си работать не умеет, единственное, что разумно предположить - это то, что sizeof есть некая особая конструкция, которая раскрывается на этапе свёртывания АСД компилятором. pgpLiAGpzvhfn.pgp Description: PGP signature
Re: [OT] opaque pointer
On Tue, 7 Oct 2014, Денис Ильин wrote: Коллеги, sizeof вычисляется во время компиляции. Всегда. Денис Почему? В любом компиляторе? Факт состоит в том, что стандарт языка С не определяет этого => это просто практические наблюдения. Ю.
Re: [OT] opaque pointer
Коллеги, sizeof вычисляется во время компиляции. Всегда.Денис 07.10.2014, 17:45, "Artem Chuprina" :Ivan Shmakov -> debian-russian@lists.debian.org @ Tue, 07 Oct 2014 12:47:49 +: AC>> Называется этот прием "непрозрачный указатель" (opaque pointer), AC>> иногда говорят "непрозрачная структура" (opaque structure) и AC>> используется в хвост и в гриву, начиная с libc (FILE *). IS> Зависит. Вот, к примеру, в [1] находим: Function: int putc (int c, FILE *stream) This is just like fputc, except that most systems implement it as a macro, making it faster. […] IS> Что как бы намекает на то, что FILE отнюдь не opaque.Как минимум, используется он как opaque. Хотя на практике он, скореевсего, тоже уже устоялся, не менялся дцать лет, и может быть доступеноткрыто.Но тем не менее, в _API_ libc определения FILE нет.-- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.orgwith a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.orgArchive: https://lists.debian.org/87sij0at97@wizzle.ran.pp.ru
Re: [OT] opaque pointer
Коллеги, sizeof вычисляется во время компиляции. Всегда.Денис 07.10.2014, 17:45, "Artem Chuprina" :Ivan Shmakov -> debian-russian@lists.debian.org @ Tue, 07 Oct 2014 12:47:49 +: AC>> Называется этот прием "непрозрачный указатель" (opaque pointer), AC>> иногда говорят "непрозрачная структура" (opaque structure) и AC>> используется в хвост и в гриву, начиная с libc (FILE *). IS> Зависит. Вот, к примеру, в [1] находим: Function: int putc (int c, FILE *stream) This is just like fputc, except that most systems implement it as a macro, making it faster. […] IS> Что как бы намекает на то, что FILE отнюдь не opaque.Как минимум, используется он как opaque. Хотя на практике он, скореевсего, тоже уже устоялся, не менялся дцать лет, и может быть доступеноткрыто.Но тем не менее, в _API_ libc определения FILE нет.-- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.orgwith a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.orgArchive: https://lists.debian.org/87sij0at97@wizzle.ran.pp.ru
Re: [OT] opaque pointer
Ivan Shmakov -> debian-russian@lists.debian.org @ Tue, 07 Oct 2014 12:47:49 +: AC>> Называется этот прием "непрозрачный указатель" (opaque pointer), AC>> иногда говорят "непрозрачная структура" (opaque structure) и AC>> используется в хвост и в гриву, начиная с libc (FILE *). IS>Зависит. Вот, к примеру, в [1] находим: >> Function: int putc (int c, FILE *stream) >> This is just like fputc, except that most systems implement it as a >> macro, making it faster. […] IS>Что как бы намекает на то, что FILE отнюдь не opaque. Как минимум, используется он как opaque. Хотя на практике он, скорее всего, тоже уже устоялся, не менялся дцать лет, и может быть доступен открыто. Но тем не менее, в _API_ libc определения FILE нет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87sij0at97@wizzle.ran.pp.ru
[OT] opaque pointer
> "AC" == Artem Chuprina writes: […] AC> Называется этот прием "непрозрачный указатель" (opaque pointer), AC> иногда говорят "непрозрачная структура" (opaque structure) и AC> используется в хвост и в гриву, начиная с libc (FILE *). Зависит. Вот, к примеру, в [1] находим: > Function: int putc (int c, FILE *stream) > This is just like fputc, except that most systems implement it as a > macro, making it faster. […] Что как бы намекает на то, что FILE отнюдь не opaque. [1] https://gnu.org/software/libc/manual/html_node/Simple-Output.html […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uks59my.fsf...@violet.siamics.net
