On Thursday, July 02, 2015 23:31:19 Maxim Sakharov wrote:
> Здравствуйте!
>
> Есть ли специалисты по Си? Сын изучает язык, я ему помогаю. Вопрос
Рекомендую ознакомится со следующим:
http://lurkmore.to/Выстрелить_себе_в_ногу
--
ivan
On Thursday, July 02, 2015 23:31:19 Maxim Sakharov wrote:
> Здравствуйте!
>
> Есть ли специалисты по Си? Сын изучает язык, я ему помогаю. Вопрос
Это че за (странный код)?
PS. C таким знанием не надо помогать сыну, надо уйти и спрятатся ))
или компилятор должен ловить такие ситуации? У меня Debian
GNU/Linux 7, компилятор gcc 4.7.2.
Лучше такие вопросы хотя бы с псевдо-примерами обсуждать.
Скажем так:
void fun() {
char txt[20] = "abcdef";
printf("txt[22] = %c\n",txt[22]);
}
В стандарте языка C вызов
этой строки, начинающейся с 22-го символа. Это
MS> нормально или компилятор должен ловить такие ситуации? У меня Debian
GNU/Linux
MS> 7, компилятор gcc 4.7.2.
С точки зрения стандарта C, это нормально. В C по стандарту обращение к
элементу массива - это всего лишь адресная арифмети
То, о чём вы пишете, называется 'неопределённое поведение'.В интернете на тему достаточно информации. Ищите.19:32, 2 июля 2015 г., Maxim Sakharov :Здравствуйте!Есть ли специалисты по Си? Сын изучает язык, я ему помогаю. Вопрос такой: во вложенной программе строка s2 описана как массив символов длин
Для отлова таких ошибок есть статические анализаторы кода. С точки зрения
языкового синтаксиса - всё ок. С точки зрения стандарта, поведение такой
программы не определено.
А вот зачем вы пишете &s1 - в printf, это вопрос )
2 июля 2015 г., 19:31 пользователь Maxim Sakharov
написал:
> Здравствуйт
Здравствуйте!
Есть ли специалисты по Си? Сын изучает язык, я ему помогаю. Вопрос
такой: во вложенной программе строка s2 описана как массив символов
длиной 20, а я могу обратиться к подстроке этой строки, начинающейся с
22-го символа. Это нормально или компилятор должен ловить такие
ситуации?
formatoptions+=t
Само собою, если длинные строки переносятся жестко, то наблюдать
проблему мягкого переноса длинных строк возможностей немного. Хотя от
самой опции-то она не зависит — можно ‘t’ отключить, вставить длинную
строку, включить обратно и прекрасно наблюсти проблему.
Ладно, допуст
В сообщении от [Птн 2015-01-02 08:32 +0300]
Dmitry Alexandrov <321...@gmail.com> пишет:
> Обнаружил, кажется, пренеприяную ошибку в Vim’е: при установленной
> опции 'linebreak' (визуальный перенос строк только по пробелам, а не
> посередь слова) ее эффект на время обнуляется командой изменения
> "с
u should think of “free” as in “free speech,” not as in “free beer”.
Если теперь выйти из режима вставки и продолжить редактирование файла,
то по мере перерисовки буфера он вернется к должному виду с переносом по
словам до следующей команды "c".
Проявляется это как в терминале, та
тно. Тогда я уже ничему не удивляюсь, раз вы даже встроенную
документацию в процессе "правки" не нашли...
Впрочем, c религиозными фанатиками дело я стараюсь не иметь, простите,
если более не отвечу.
> SBK>Есть на CPAN сопоставимый аналог theano?
>
> Поиск пока
On Wed, 12 Feb 2014, Sergey B Kirpichev wrote:
SBK>> SBK>http://pdl.perl.org/?page=reference
SBK>> SBK>http://docs.scipy.org/doc/
SBK>> Э, и что это должно иллюстрировать?
SBK>
SBK>Что больше "доделано".
SBK>
SBK>> Что у питона нет встроенной документации?
SBK>
SBK>С чего вы взялись утверждать
On Wed, Feb 12, 2014 at 03:26:26PM +0400, Dmitrii Kashin wrote:
> Sergey B Kirpichev writes:
>
> >(Ну а другая статистика - показывает что проект скорее мертв чем
> >жив...)
> >
> > Ерунда, конечно, но и финансируются проекты scipy ощутимее, и
> > ссылаются на них чаще в публикациях... В общем,
Sergey B Kirpichev writes:
>(Ну а другая статистика - показывает что проект скорее мертв чем
>жив...)
>
> Ерунда, конечно, но и финансируются проекты scipy ощутимее, и
> ссылаются на них чаще в публикациях... В общем, я вряд-ли навру если
> скажу что это решение - популярнее.
Эдак Wolfram Math
On Wed, Feb 12, 2014 at 03:55:04PM +0900, Fedor Zuev wrote:
> On Wed, 12 Feb 2014, Sergey B Kirpichev wrote:
>
> SBK>On Mon, Feb 10, 2014 at 11:26:05PM +0900, Fedor Zuev wrote:
> SBK>> Ну так я вроде же указал на PDL, подражанием которому
> SBK>
> SBK>Из машины времени что-ли? ;)
> SBK>
>
On Wed, 12 Feb 2014, Sergey B Kirpichev wrote:
SBK>On Mon, Feb 10, 2014 at 11:26:05PM +0900, Fedor Zuev wrote:
SBK>> Ну так я вроде же указал на PDL, подражанием которому
SBK>
SBK>Из машины времени что-ли? ;)
SBK>
SBK>> (не доделанным и наполовину, если я правильно помню) является numpy.
SBK>
SB
On Mon, Feb 10, 2014 at 11:39:30PM +0200, Dmitry Statyvka wrote:
> Если зависимость того же толка, что и между современным linux и linux
> образца 91-го года, то я бы смело ее игнорировал :-)
Напрасно игнорируете. Есть вещи "оттуда", от которых некоторые
до сих пор плюются. Напр., вот:
http://ww
On Mon, Feb 10, 2014 at 11:26:05PM +0900, Fedor Zuev wrote:
> Ну так я вроде же указал на PDL, подражанием которому
Из машины времени что-ли? ;)
> (не доделанным и наполовину, если я правильно помню) является numpy.
Мягко говоря, недоделанным выглядит больше PDL. Достаточно
сравнить
http:
On 2014-02-08, Victor Wagner wrote:
> On 2014.02.08 at 18:10:07 +0200, Oleksandr Gavenko wrote:
>
>> Emacs этому учить даже не надо. Не в курсе последних изменений, но раньше Vim
>> внутри работал с 8-bit строками и ничего не знал о Unicode в своих "ядерных"
>> примитивах.
>
> Вим тоже уже давно в
> Sergey B Kirpichev writes:
[...]
>> Что же тогда вы имели сказать словами «одной из первых в мире CAS» и
>> «первый блин» при обсуждении maxima?
SBK> То что maxima и macsyma не настолько разные и независимые вещи,
SBK> чтобы это игнорировать.
Если зависимость того же толка, что и межд
On Mon, 10 Feb 2014, Sergey B Kirpichev wrote:
SBK>On Mon, Feb 10, 2014 at 09:52:44PM +0900, Fedor Zuev wrote:
SBK>> вводе-выводе). А также набором библиотек, в том числе
SBK>> научно-вычислительных.
SBK>
SBK>Как оно с фортраном, умеет дружить?
SBK>
SBK>Можно пример библиотек, которые вы считаете
On Sat, 8 Feb 2014, Artem Chuprina wrote:
AC>Перл, конечно, сильно развился со времен изначальной своей задачи
AC>"сложная обработка человекочитаемых текстов", но разработан он был
AC>именно под это, как более универсальный awk, и это в нем осталось. Его
AC>научили работать с базами данных, с гуе
On Mon, Feb 10, 2014 at 03:08:47AM +0400, Иван Лох wrote:
> Ядро и frontend написаны на С++
Ядро там написано на местном диалекте C, так клянутся
в документации 9-й Mathematica.
> > язык никому трогать не нужно.
>
> Кому не нужно? Разработчикам из Wolfram?
Ну да. Нет, и фрон
м из Wolfram?
> Много вы видели расширений к Mathematica на C? Например?
Сейчас это менее актуально, но кода такого множество. И на
C++ и на Java. Другое дело, что это не символические вычисления.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsub
так Mathematica тоже написана на двух языках ))
Mathematica написана на Mathematica. А второй
язык никому трогать не нужно. Много вы видели расширений
к Mathematica на C? Например?
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe&
On Mon, Feb 10, 2014 at 02:06:59AM +0400, Sergey B Kirpichev wrote:
> Плюс, максима написана на *двух* языках. Для современных
> CAS - это, мягко говоря, необычная ситуация (см. Maple, Mathematica).
Ну так Mathematica тоже написана на двух языках ))
--
To UNSUBSCRIBE, email to debian-russian-r
On Sun, Feb 09, 2014 at 11:27:09PM +0200, Dmitry Statyvka wrote:
> > Sergey B Kirpichev writes:
>
> SBK> On Sun, Feb 09, 2014 at 02:27:36AM +0200, Dmitry Statyvka wrote:
> >> «Дезинформируете, Туз.» Во-первых, вы спутали maxima с macsyma.
>
> SBK> Да нет.
>
> Что же тогда вы имели сказать
> Sergey B Kirpichev writes:
SBK> On Sun, Feb 09, 2014 at 02:27:36AM +0200, Dmitry Statyvka wrote:
>> «Дезинформируете, Туз.» Во-первых, вы спутали maxima с macsyma.
SBK> Да нет.
Что же тогда вы имели сказать словами «одной из первых в мире CAS» и
«первый блин» при обсуждении maxima?
>>
On Sun, Feb 09, 2014 at 02:27:36AM +0200, Dmitry Statyvka wrote:
> «Дезинформируете, Туз.» Во-первых, вы спутали maxima с macsyma.
Да нет.
> Во-вторых, людей, понимающих Common Lisp, на котором написана maxima,
> существенно больше десятка
Не в языке дело.
> не говоря уже о том, что maxima имее
> Sergey B Kirpichev writes:
[...]
SBK> "Недостаток" максимы в том, что когда вы захотите чего-то
SBK> нетривиального и попробуете залезть в ее потроха - вы получите
SBK> древний лисп-код (одной из первых в мире CAS, напомнить про первый
SBK> блин?), который в мире понимает десяток (хорош
ться, а почитать небольшой summary, что это в целом
> такое. Есть разница.
Нет. Для summary - есть страница проекта.
> > C++ там нету)
> > sk@darkstar:~/src/julia $ find . -name '*.c'|wc -l
> > 64
> > sk@darkstar:~/src/julia $ find . -name '*.C' -o -nam
On 2014.02.08 at 18:10:07 +0200, Oleksandr Gavenko wrote:
> On 2014-02-08, Victor Wagner wrote:
>
> >> Стандарт поддерживает; не поддерживают, AFAIK, компиляторы. А
> >> оно вам сильно надо? Клавиатура-то не резиновая, а под APL поди
> >> вовсе уж не выпускают... С полным греческим алфавитом -
On 08/02/14 22:59, Artem Chuprina wrote:
> >> Да, покуда вы не научитесь использовать эффективные алгоритмы. Разруха -
> >> она помним где? ;)
>
> DK> Не знаю где. Это поговорка?
>
> Типа да. Цитата. "Разруха не в сортирах. Разруха в головах."
> Советская классика, а какая - не вспомню.
Соб
Dmitrii Kashin -> debian-russian@lists.debian.org @ Sat, 08 Feb 2014 22:10:50
+0400:
>>> Ну, учитывая, что Python славится своей нерасторопностью (хотя может я
>>> неправ, fixme), у меня есть подозрения, что проблемы с
>>> производительностью всё же будут.
>>
>> Да, покуда вы не научитесь и
Alexander Galanin writes:
> On Sat, 08 Feb 2014 19:46:03 +0400
> Dmitrii Kashin wrote:
>
>> Кстати, надо бы сделать небольшое отступление о Maxima, раз уж поднялась
>> эта тема в разговоре. Вот есть у меня выражение из независимых
>> переменных. Допустим, я хочу задать некоторую новую переменную
On Sat, 08 Feb 2014 19:46:03 +0400
Dmitrii Kashin wrote:
> Кстати, надо бы сделать небольшое отступление о Maxima, раз уж поднялась
> эта тема в разговоре. Вот есть у меня выражение из независимых
> переменных. Допустим, я хочу задать некоторую новую переменную,
> зависимую от данных, а потом ско
алгоритмы. Разруха -
> она помним где? ;)
Не знаю где. Это поговорка?
>> Ну, про Julia я слышу впервые. Опять же, связка C++ и LLVM вызывает
>> недоверие. В википедии употреблена фраза "sophisticated types system", я
>> вот сижу и думаю, это хорошо или плохо?
Dmitrii Kashin -> debian-russian@lists.debian.org @ Sat, 08 Feb 2014 19:57:16
+0400:
DK> Вы были убедительны, на хаскель посмотрю. Но всё-таки хотелось бы вновь
DK> поднять вопрос о литературе. Вот Alexander Danilov в сообщении
DK> <52eb5a40.8050...@gmail.com> предложил список литературы.
D
ожет я
> неправ, fixme), у меня есть подозрения, что проблемы с
> производительностью всё же будут.
Да, покуда вы не научитесь использовать эффективные алгоритмы. Разруха -
она помним где? ;)
> Ну, про Julia я слышу впервые. Опять же, связка C++ и LLVM вызывает
> недоверие. В
08.02.2014 19:57, Dmitrii Kashin пишет:
Artem Chuprina writes:
Dmitrii Kashin -> debian-russian@lists.debian.org @ Fri, 07 Feb 2014 14:11:40
+0400:
>> gcc тоже поддерживает, но в сильно извращенной форме:
>>
http://gcc.gnu.org/wiki/FAQ#What_is_the_status_of_adding_the_UTF-8_support
(eq arg 2)
(activate-input-method my-russian-input-method))
((eq arg 3)
(activate-input-method my-ukranian-input-method))
((eq arg 4)
(activate-input-method my-ipa-input-method)) )
(toggle-input-method arg)) )
(global-set-key (kbd "C-\\") 'my-
Artem Chuprina writes:
> Dmitrii Kashin -> debian-russian@lists.debian.org @ Fri, 07 Feb 2014
> 14:11:40 +0400:
>
> >> gcc тоже поддерживает, но в сильно извращенной форме:
> >>
> http://gcc.gnu.org/wiki/FAQ#What_is_the_status_of_adding_the_UTF-8_support_for_identifier_names_in_GCC.3F
>
Кстати, надо бы сделать небольшое отступление о Maxima, раз уж поднялась
эта тема в разговоре. Вот есть у меня выражение из независимых
переменных. Допустим, я хочу задать некоторую новую переменную,
зависимую от данных, а потом скомандовать Maxima, чтобы везде в этом
выражении она попыталась выде
потому что обычно от аналитической
> постановки задачи до численного кода куча промежуточных шагов.
>
> Элементарный пример: пусть у вас есть задача Коши для
> системы ОДУ. Вы можете в C стартовать из аналитического описания
> задачи, преобразовать функции в форму, удобную для численног
On Sat, Feb 08, 2014 at 06:48:49PM +0400, Victor Wagner wrote:
> On 2014.02.08 at 14:45:58 +0400, Иван Лох wrote:
>
> > On Sat, Feb 08, 2014 at 12:09:31PM +0400, Victor Wagner wrote:
> > > Ну почему? Есть же продвинутые текстовые редакторы. Вот, к примеру в vim
> > > научиться вводить греческие б
On 2014.02.08 at 14:45:58 +0400, Иван Лох wrote:
> On Sat, Feb 08, 2014 at 12:09:31PM +0400, Victor Wagner wrote:
> > Ну почему? Есть же продвинутые текстовые редакторы. Вот, к примеру в vim
> > научиться вводить греческие буквы через диграфы - дело пары часов.
> > (:help digraph, :help digraphs
On 2014.02.08 at 13:53:56 +0400, yuri.nefe...@gmail.com wrote:
> >Ну почему? Есть же продвинутые текстовые редакторы. Вот, к примеру в vim
> >научиться вводить греческие буквы через диграфы - дело пары часов.
> >(:help digraph, :help digraphs-default). Я этому не поленился научиться
> >исключител
ачи до численного кода куча промежуточных шагов.
Элементарный пример: пусть у вас есть задача Коши для
системы ОДУ. Вы можете в C стартовать из аналитического описания
задачи, преобразовать функции в форму, удобную для численного счета,
сгенерировать эффективный численный метод интегрирования именно
On Sat, Feb 08, 2014 at 12:09:31PM +0400, Victor Wagner wrote:
> On 2014.02.07 at 02:20:11 +0400, Sergey B Kirpichev wrote:
>
> > > Появилась мысль, что чем писать нечто вроде density_liquid, было бы
> > > неплохо записать нормальными греческими буквами, как в LaTeX \(\rho_l\),
> > > и читалось бы
On Sat, 8 Feb 2014, Victor Wagner wrote:
On 2014.02.07 at 02:20:11 +0400, Sergey B Kirpichev wrote:
Появилась мысль, что чем писать нечто вроде density_liquid, было бы
неплохо записать нормальными греческими буквами, как в LaTeX \(\rho_l\),
и читалось бы это просто замечательно.
Стандарт под
On 2014.02.07 at 02:20:11 +0400, Sergey B Kirpichev wrote:
> > Появилась мысль, что чем писать нечто вроде density_liquid, было бы
> > неплохо записать нормальными греческими буквами, как в LaTeX \(\rho_l\),
> > и читалось бы это просто замечательно.
> >
> Стандарт поддерживает; не поддерживают, A
уется лазить туда в GDB, еще раз
>> скажу: ВОЗЬМИ ХАСКЕЛЬ! Ну, или ocaml (он вроде более принят в научных
>> кругах), но хаскель вроде строже, что в данном случае плюс.
ИЛ> Ну не знаю ))) FORTRAN и C столь любимы в научных кругах IMHO за то, что
ИЛ> там понятно как оценить время
для написания расчетов требуется лазить туда в GDB, еще раз
> скажу: ВОЗЬМИ ХАСКЕЛЬ! Ну, или ocaml (он вроде более принят в научных
> кругах), но хаскель вроде строже, что в данном случае плюс.
Ну не знаю ))) FORTRAN и C столь любимы в научных кругах IMHO за то, что
там понятно как оценить в
Dmitrii Kashin -> debian-russian@lists.debian.org @ Fri, 07 Feb 2014 14:11:40
+0400:
>> gcc тоже поддерживает, но в сильно извращенной форме:
>>
>> http://gcc.gnu.org/wiki/FAQ#What_is_the_status_of_adding_the_UTF-8_support_for_identifier_names_in_GCC.3F
DK> Жесть. И этот UCN'овский "\U
андарт поддерживает; не поддерживают, AFAIK, компиляторы. А
> оно вам сильно надо? Клавиатура-то не резиновая, а под APL поди
> вовсе уж не выпускают... С полным греческим алфавитом - намаетесь, однако.
>
> Да и зачем вам, пардон, в XXI веке писать вручную код на C, который
> я
yuri.nefe...@gmail.com writes:
> clang поддерживает UTF-8:
Меня как-то не прельщает мысль менять проверенный временем хороший
компилятор, на какую-то новомодную поделку.
> gcc тоже поддерживает, но в сильно извращенной форме:
>
> http://gcc.gnu.org/wiki/FAQ#What_is_the_status_of_adding_th
On Fri, 7 Feb 2014, Sergey B Kirpichev wrote:
Так как стандарт C99 не поддерживает юникода в качестве имён, я подумал,
что возможно можно использовать LaTeX только для отображения в редакторе
(в моём случае Emacs), а перед компиляцией прогонять программу через
дополнительный парсер, заменяющий L
ьно надо? Клавиатура-то не резиновая, а под APL поди
вовсе уж не выпускают... С полным греческим алфавитом - намаетесь, однако.
Да и зачем вам, пардон, в XXI веке писать вручную код на C, который
явно просится быть автогенерированным? Или даже написанным
на языке более высокого уровня.
Посмо
31.01.2014 03:10, yuri.nefe...@gmail.com пишет:
On Fri, 31 Jan 2014, Artem Chuprina wrote:
Dmitrii Kashin -> debian-russian@lists.debian.org @ Thu, 30 Jan 2014 22:41:05
+0400:
DK> Кстати говоря, Хаскель действительно чисто функциональный язык
DK> программирования? А то мне так и про scheme
31 января 2014 г., 4:17 пользователь Oleksandr Gavenko
> On 2014-01-30, yuri.nefedov wrote:
>
>> Есть такая концепция - literate programming.
>
> Вот живой пример на Си:
>
> http://en.literateprograms.org/Hash_table_%28C%29
Однако в этом примере кода больше чем пояняющего текста,
а, насколько я п
On Fri, 31 Jan 2014, Artem Chuprina wrote:
Dmitrii Kashin -> debian-russian@lists.debian.org @ Thu, 30 Jan 2014 22:41:05
+0400:
DK> Кстати говоря, Хаскель действительно чисто функциональный язык
DK> программирования? А то мне так и про scheme когда-то говорили, а
DK> оказалось всё куда сложн
, заменяющий LaTeX на имена, соответствующие
> стандарту C99.
>
> Впрочем, я так и не нашёл minor-режима для отображения формул в окне
> Emacs. auctex и preview-latex лишь модифицируют поведение latex-mode, а
> я бы хотел видеть формулы в c-mode.
>
> О LaTeX речь неспроста. Мож
On 2014-01-30, yuri.nefe...@gmail.com wrote:
> Есть такая концепция - literate programming.
> Некоторые говорят, что парадигма, но мне то кажется, что концепция :)
> Возможно, что там что-то полезное для себя и найдете.
>
> https://en.wikipedia.org/wiki/Literate_programming
Вот живой пример н
Dmitrii Kashin -> debian-russian@lists.debian.org @ Thu, 30 Jan 2014 22:41:05
+0400:
>> Немного не в тему, на мой взгляд, математические программы лучше всего
>> писать на Haskell.
DK> Было б у меня больше времени. Я тут всё силюсь lisp освоить, хоть в
DK> каком-то виде. Прогресс небольшой
Есть такая концепция - literate programming.
Некоторые говорят, что парадигма, но мне то кажется, что концепция :)
Возможно, что там что-то полезное для себя и найдете.
Ю.
https://en.wikipedia.org/wiki/Literate_programming
30.01.2014 22:41, Dmitrii Kashin пишет:
Alexander Danilov writes:
Немного не в тему, на мой взгляд, математические программы лучше всего
писать на Haskell.
Было б у меня больше времени. Я тут всё силюсь lisp освоить, хоть в
каком-то виде. Прогресс небольшой пока: сайт себе сделал.
Именно м
Alexander Danilov writes:
> Немного не в тему, на мой взгляд, математические программы лучше всего
> писать на Haskell.
Было б у меня больше времени. Я тут всё силюсь lisp освоить, хоть в
каком-то виде. Прогресс небольшой пока: сайт себе сделал.
> Именно математические - для этого в Haskell ест
minor-режима для отображения формул в окне
Emacs. auctex и preview-latex лишь модифицируют поведение latex-mode, а
я бы хотел видеть формулы в c-mode.
О LaTeX речь неспроста. Можно, конечно, использовать близкую
транслитерацию, и заменить \rho_l на r_l, однако вопрос актуален ещё и в
том плане, что
30 января 2014 г., 23:21 пользователь Alex Kuklin написал:
>>> Чем же это лучше?
>>
>> 1. Понятнее
>> 2. Глаза не ломаются на закорючках
>
> http://grammar.ccc.commnet.edu/grammar/twain.htm
Не о том.
On 30.01.2014 18:18, dm.fedorov wrote:
30 января 2014 г., 23:15 пользователь Dmitrii Kashin
написал:
Лучше наоборот, убрать из физики и математики все эти иностранные алфавиты
и писать простыми английскими (русскими) словами, чтобы было понятно народу,
а то глаза сломаешь.
Чем же это лучше?
1
"dm.fedorov" writes:
> 30 января 2014 г., 22:00 пользователь Dmitrii Kashin
> написал:
>
>> Появилась мысль, что чем писать нечто вроде density_liquid, было бы
>> неплохо записать нормальными греческими буквами, как в LaTeX \(\rho_l\),
>
> Лучше наоборот, убрать из физики и математики все эти ин
30 января 2014 г., 23:15 пользователь Dmitrii Kashin
написал:
>>
>> Лучше наоборот, убрать из физики и математики все эти иностранные алфавиты
>> и писать простыми английскими (русскими) словами, чтобы было понятно народу,
>> а то глаза сломаешь.
>
> Чем же это лучше?
1. Понятнее
2. Глаза не лома
30 января 2014 г., 22:00 пользователь Dmitrii Kashin
написал:
> Так как стандарт C99 не поддерживает юникода в качестве имён, я подумал,
Переключайтесь на Go, там UTF-8 можно в именах.
> Появилась мысль, что чем писать нечто вроде density_liquid, было бы
> неплохо записать нормальными греческим
Да уж. Программирование программ. Это я, конечно, дал маху.
Всё вычитал, кроме заголовка. :)
pgpJg7CrKc5pq.pgp
Description: PGP signature
Emacs. auctex и preview-latex лишь модифицируют поведение latex-mode, а
я бы хотел видеть формулы в c-mode.
О LaTeX речь неспроста. Можно, конечно, использовать близкую
транслитерацию, и заменить \rho_l на r_l, однако вопрос актуален ещё и в
том плане, что для научных программ разумно было бы
/C99RationaleV5.10.pdf
>>
>> и далее поиск по документы...
>>
>
> Это для мазохистов.
> Стандарты очень полезны, но для чтения не пригодны.
> Да и структуру языка они вряд ли позволят понять.
>
> Ю.
>
> p.s. Для любителей есть книга:
> Jones_Derek.M &q
мазохистов.
Стандарты очень полезны, но для чтения не пригодны.
Да и структуру языка они вряд ли позволят понять.
Ю.
p.s. Для любителей есть книга:
Jones_Derek.M "The New C Standard: An Economic and Cultural Commentary"
Это стандарт С99 с оргинальными комментариями автора.
Причем к
On 2012-10-09, yuri.nefe...@gmail.com wrote:
> On Tue, 9 Oct 2012, Oleksandr Gavenko wrote:
>
>> по ключевым словам:
>>
>> flexible array member
>>
>
> Речь шла не о flexible arrays, а о использовании structure/unit
> и о том, что поля в них могут хранится разрежено. По стандарту.
> И разме
On Tue, Oct 09, 2012 at 04:32:17PM +0300, Oleksandr Gavenko wrote:
> У меня возник встречный вопрос, POSIX определяет 4 функции в вариантах
> 16-/32-бит:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/htonl.html
> htonl, htons, ntohl, ntohs - convert values bet
comp.std.c
alt.comp.lang.c
comp.lang.c++
comp.lang.c++.moderated
alt.comp.lang.learn.c-c++
rsdn.cpp
sqlru.c++
comp.unix.programmer
rsdn.unix
sqlru.linux
Еще щас популярен:
http://stackoverflow.com/
и его братья/сестры.
--
Best regards!
--
To UNSUBSCRIBE, email to debi
ер Линдена "Expert C programming".
Там, насколько я помню, было очень доходчиво написано, какими граблями
чревато использование подобных трюков.
Читаем стандарт и
http://www.knosof.co.uk/cbook/cbook.html
C Language Book Material
по ключевым словам:
flexible array membe
On 2012-10-08, Victor Wagner wrote:
>> Замечу, что в книге Кернигана и Ритчи "Язык программирования Си"
>> подобных фишек не описывалось. Виктор, Вы не подскажете, где можно
>> почитать о подобных трюках?
>
> Есть очень хорошая книга Питера ван дер Линдена "
On 2012-10-07, yuri.nefe...@gmail.com wrote:
> On Sun, 7 Oct 2012, Dmitrii Kashin wrote:
>
>> Я слышал, что существуют типы, однозначно определяющие количество бит в
>> объявляемой сущности (типа uint32), но не смог найти, где они
>> определяются.
>
> stdint.h
>
> А вообще очень полезный ресурс
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Mon, 8 Oct 2012
18:26:09 +0400:
>> Э.. Насколько я знаю С, уже тут нехорошая вещь.
>> То чем вы пользуетесь есть расширение gcc
>> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
>> и как всякое расширение лучше им без необходимости
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Mon, 8 Oct 2012
12:41:05 +0400:
DEO> имеется некая структурка
DEO> struct something {
DEO> ...
DEO> unsigned count;
DEO> unsigned element[0];
DEO> };
DEO> то есть в поле count сказано сколько элементов будет после стру
08.10.2012 23:39, yuri.nefe...@gmail.com пишет:
> On Mon, 8 Oct 2012, "Артём Н." wrote:
>
А вообще очень полезный ресурс - wikipedia )
https://en.wikipedia.org/wiki/C_data_types
>>
>> У меня похожий вопрос. Только по функциям.
>> Мне требуется преобразовывать 32-х битное время в строко
On Mon, 8 Oct 2012, Dmitry E. Oboukhov wrote:
#define SOMETING(__name, __size)\
struct {\
struct something s; \
unsigned items[__size]; \
} __attribute__((packed)) __name = {\
.s = {
On Mon, 8 Oct 2012, "Артём Н." wrote:
А вообще очень полезный ресурс - wikipedia )
https://en.wikipedia.org/wiki/C_data_types
У меня похожий вопрос. Только по функциям.
Мне требуется преобразовывать 32-х битное время в строковый формат.
Какой функцией это возможно сделать на 64-х битной маши
08.10.2012 00:24, Eugene Berdnikov пишет:
> On Sun, Oct 07, 2012 at 11:48:31PM +0400, yuri.nefe...@gmail.com wrote:
>>> Я слышал, что существуют типы, однозначно определяющие количество бит в
>>> объявляемой сущности (типа uint32), но не смог найти, где они
>>> определяются.
>>>
>>> Собственно, не
08.10.2012 15:33, Dmitrii Kashin пишет:
> --- trick.c ---
> 1
> 2#include
> 3
> 4struct base
> 5{
> 6 int count;
> 7 int str[0];
> 8};
> 9
> 10int main(int argc, char** argv)
> 11
ах?
> >
> > Есть очень хорошая книга Питера ван дер Линдена "Expert C programming".
> > Там, насколько я помню, было очень доходчиво написано, какими граблями
> > чревато использование подобных трюков.
>
> Нашел книгу и уже погрепал по слову union. К сожале
Web-форумы.
Я бы предложил воспользоваться конференциями Usenet (e. g.,
news:relcom.comp.lang.c-c++ †), но, боюсь, чтобы в них кто-то
появился, нужно сначала туда этого кого-то позвать.
† nntp://aioe.org/relcom.comp.lang.c-c++
http://www.eternal-september.org/Regis
Victor Wagner writes:
>> Замечу, что в книге Кернигана и Ритчи "Язык программирования Си"
>> подобных фишек не описывалось. Виктор, Вы не подскажете, где можно
>> почитать о подобных трюках?
>
> Есть очень хорошая книга Питера ван дер Линдена "Expert C
необходимости не пользоваться.
ну бОльшая часть линукс кернела в этом стиле написана, так что имхо
пользоваться можно :)
Ядро и не стремится поддерживать не-гцц :)
Вроде бы пробовали компилировать c clang?
http://llvm.org/bugs/show_bug.cgi?id=4068
http://lwn.net/Articles/441018/
Так что
а вот если появилась необходимость саллоцировать такой объект
статически, как быть?
>>>
>>> Завести union. С первым вариантом struct something и вторым - массивом
>>> требуемой длины. (учитывая sizeof(struct something).
>>
>> Элегантность этого решения настолько впечатлила меня, что я
> 16 union
> 17 {
> 18struct base body;
> 19int str[sizeof(struct base)+c];
> 20 } object;
тут может быть просто struct и тогда не надо будет sizeof(struct base)
вопрос как это в макрос засунть, чтобы потом функции которые хотят
указатель на str
On Mon, Oct 08, 2012 at 06:26:09PM +0400, Dmitry E. Oboukhov wrote:
> > Э.. Насколько я знаю С, уже тут нехорошая вещь.
> > То чем вы пользуетесь есть расширение gcc
> > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> > и как всякое расширение лучше им без необходимости не пользоваться.
>
> н
> Вообще говоря вопрос к Диме Обухову: какая цель
> в возможности задать размер массива во время компиляции?
> Меньше цпу? Сомнительно. Без профайлера не поверю.
> Экономия памяти? Ну совсем копейки.
> На большее фантазии у меня не хватает.
вообще это объекты которые правда аллоцируются динамичес
> Э.. Насколько я знаю С, уже тут нехорошая вещь.
> То чем вы пользуетесь есть расширение gcc
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> и как всякое расширение лучше им без необходимости не пользоваться.
ну бОльшая часть линукс кернела в этом стиле написана, так что имхо
пользоваться
On Mon, Oct 08, 2012 at 05:36:40PM +0400, Victor Wagner wrote:
> Кстати, тут пришло в голову еще одно решение - использовать alloca.
> Это не совсем статическая структура, а явное выделение памяти в стеке.
> Но тем не менее.
Человек просил портабельно, у alloca() с этим проблемы.
--
Eugene Berd
Результаты 1 - 100 из 483 matches
Mail list logo
