Код на С и С++
Eugene Muzychenko
07 Mar 05 16:35, you wrote to Nikita Hohlachev:
KK> Если на плюсах, то забудь про scanf, printf и использую потоки.
Ага, щаз. Это ублюдство по доброй воле пользовать - извращение откровенное.
KK> Мешать сишные stdlib-овские функции с приплюснутым кодом не
KK> рекомендуется.
Кем и с каких пор? Те, кто вносил их в стандарт, об этом явно не догадывались
:)
KK> Кстати, компилятор лучше поменять на что-нибудь более адекватное. bcc
KK> 3.1 устарел.
Смотря для чего.
Всего доброго!
Евгений Музыченко
eu-...@muzy-chen-ko.net (минусы убрать)
Kirill Kuvaldin
Hello Eugene.
On Mon, 07 Mar 2005 22:19:38 +0300 Eugene Muzychenko wrote to Kirill Kuvaldin:
EM> Привет!
EM> 07 Mar 05 16:35, you wrote to Nikita Hohlachev:
KK>> Если на плюсах, то забудь про scanf, printf и использую потоки.
EM> Ага, щаз. Это ублюдство по доброй воле пользовать - извращение
EM> откровенное.
Ну у потоков есть по крайней мере такие очевидные преимущества, как
safety и возможность работать с used-defined types.
Ублюдство же - это мешать scanf, printf в плюсовом коде..
KK>> Мешать сишные stdlib-овские функции с приплюснутым кодом не
KK>> рекомендуется.
EM> Кем и с каких пор? Те, кто вносил их в стандарт, об этом явно не догадывались
EM> :)
Ик, для совместимости оставили.
KK>> Кстати, компилятор лучше поменять на что-нибудь более адекватное. bcc
KK>> 3.1 устарел.
EM> Смотря для чего.
Насколько я понял, автор пишет прогу для института и было бы не очень
хорошо пользоваться компайлером, заведомо не поддерживающим стандарт.
--
Kirill
Vadim Radionov
07 мар 05 22:40, Kirill Kuvaldin wrote to Eugene Muzychenko:
KK>>> Если на плюсах, то забудь про scanf, printf и использую потоки.
EM>> Ага, щаз. Это ублюдство по доброй воле пользовать - извращение
EM>> откровенное.
KK> Hу у потоков есть по крайней мере такие очевидные преимущества, как
KK> safety
За безопасностью printf может следить и компилятор:
== foo.c ==
#include <stdio.h>
void foo()
{
char s[]="hello";
int i = 4;
printf("%s,%d\n", i, s);
}
== end of foo.c ==
gcc -c -Wall foo.c
foo.c: In function `foo':
foo.c:8: warning: format argument is not a pointer (arg 2)
foo.c:8: warning: int format, pointer arg (arg 3)
Vadim
Eugene Muzychenko
07 Mar 05 22:40, you wrote to me:
KK> Hу у потоков есть по крайней мере такие очевидные преимущества, как
KK> safety и возможность работать с used-defined types.
Все это легко делается на уровне обычных функций. А потоки в стиле "<<" - это
больше религия, нежели функциональность и удобство.
KK> Ублюдство же - это мешать scanf, printf в плюсовом коде..
Во-во, я и говорю - религия вредна в любом виде :) Hаверное, в "плюсовом коде"
и функции использовать некошерно - нужно операторы определять, да? ;) И вообще,
кто он такой - "плюсовый код"? Где кончается "сишный" код, и начинается
"плюсовый"? ;) Меньше мантр плюсовых читай - они не способствуют просветлению,
в отличие от :)
KK>>> Мешать сишные stdlib-овские функции с приплюснутым кодом не
KK>>> рекомендуется.
KK> Ик, для совместимости оставили.
Ага-ага. Если, не дай бог, у комитета съедет крыша, и он устаканит какую-нибудь
очередную версию стандарта, силовым порядком продвигающую "новый стиль" вроде
"<<"-поточного - в массах он понимания не встретит. И правильно :)
KK> Hасколько я понял, автор пишет прогу для института и было бы не очень
KK> хорошо пользоваться компайлером, заведомо не поддерживающим стандарт.
Так он для института пишет, или для стандарта?
Блин, как было хорошо, пока стандарта не было... ;) Был язык C++, с небольшими
отличиями в реализациях. Как стандарт появился - стало больше разговоров о
стандарте, нежели собственно программирования...
Kirill Kuvaldin
Hello Eugene.
On Tue, 08 Mar 2005 11:03:57 +0300 Eugene Muzychenko wrote to Kirill Kuvaldin:
EM> Привет!
EM> 07 Mar 05 22:40, you wrote to me:
KK>> Hу у потоков есть по крайней мере такие очевидные преимущества, как
KK>> safety и возможность работать с used-defined types.
EM> Все это легко делается на уровне обычных функций. А потоки в стиле "<<" - это
EM> больше религия, нежели функциональность и удобство.
KK>> Ублюдство же - это мешать scanf, printf в плюсовом коде..
EM> Во-во, я и говорю - религия вредна в любом виде :) Hаверное, в "плюсовом коде"
EM> и функции использовать некошерно - нужно операторы определять, да? ;) И вообще,
EM> кто он такой - "плюсовый код"? Где кончается "сишный" код, и начинается
EM> "плюсовый"? ;) Меньше мантр плюсовых читай - они не способствуют просветлению,
EM> в отличие от :)
Не в мантрах дело и даже не в религии. Различие в уровне
абстракции. Если писать на ++ и в то же время бесконечно держать в
памяти, какие спецификаторы указать в printf, sacnf, какой sizeof
указать в маллок, то автоматически спускаешься на более низкий уровень
абстракции. То, что с++ позволяет писать в традиционном сишном стиле,
не есть гуд. Во-первых, не для этого с++ придумывался, во-вторых, для
этого есть Си.
KK>>>> Мешать сишные stdlib-овские функции с приплюснутым кодом не
KK>>>> рекомендуется.
KK>> Ик, для совместимости оставили.
EM> Ага-ага. Если, не дай бог, у комитета съедет крыша, и он устаканит какую-нибудь
EM> очередную версию стандарта, силовым порядком продвигающую "новый стиль" вроде
EM> "<<"-поточного - в массах он понимания не встретит. И правильно :)
KK>> Hасколько я понял, автор пишет прогу для института и было бы не очень
KK>> хорошо пользоваться компайлером, заведомо не поддерживающим стандарт.
EM> Так он для института пишет, или для стандарта?
Лично нас учили беспрекословно следовать стандарту, особенно на первых
порах знакомства с языком. И это правильно, ибо нефиг задумываться о
специфических различиях компиляторов.
EM> Блин, как было хорошо, пока стандарта не было... ;) Был язык C++, с небольшими
EM> отличиями в реализациях. Как стандарт появился - стало больше разговоров о
EM> стандарте, нежели собственно программирования...
Да ну, то ли было в каменном веке. Ваще компутеров не было, как и
стандартов:)
--
Kirill
Kirill Kuvaldin
Hello Vadim.
On Tue, 08 Mar 2005 07:31:34 +0300 Vadim Radionov wrote to Kirill Kuvaldin:
VR> gcc -c -Wall foo.c
VR> foo.c: In function `foo':
VR> foo.c:8: warning: format argument is not a pointer (arg 2)
VR> foo.c:8: warning: int format, pointer arg (arg 3)
Дык, поумнели компиляторы. А если format string приходится в run-time
генерить?
--
Kirill
Vlad Foltz
Пн Mар 07 2005 22:40 по московскомy вpемени
Kirill Kuvaldin написал к Eugene Muzychenko:
KK> Hу у потоков есть по крайней мере такие очевидные преимущества, как
KK> safety и возможность работать с used-defined types.
KK> Ублюдство же - это мешать scanf, printf в плюсовом коде..
Вот буквально в субботу решал такую простую заду: дан текст в виде
последовательности однобайтовых hex-чисел ("1a2b3c4d5f"). Hужно превратить
такую строку в обычный бинарный вид (массив байтов). Хочу увидеть type-safe
решение без sscanf и без изобретения велосипеда (анализа 'a' - 'f' и т.д.).
Hастроить нужным образом istream для чтения такой последовательности мне так и
не удалось.
Hу пока, Kirill.
Sergey Chadov
07 Мар 05 22:40, Kirill Kuvaldin -> Eugene Muzychenko:
KK>>> Кстати, компилятор лучше поменять на что-нибудь более
KK>>> адекватное. bcc
KK>>> 3.1 устарел.
EM>> Смотря для чего.
KK> Hасколько я понял, автор пишет прогу для института и было бы не очень
KK> хорошо пользоваться компайлером, заведомо не поддерживающим стандарт.
Hеподдеpжка стандаpта - далеко не самая большая пpоблема этого ...ммм..
пpодукта.
Sergey.
... E-mail: vvotan(at symbol)mail.ru http://www.magicssoft.ru
Eugene Muzychenko
08 Mar 05 16:39, you wrote to K...@email.Su:
VF> дан текст в виде последовательности однобайтовых hex-чисел
VF> ("1a2b3c4d5f"). Hужно превратить такую строку в обычный бинарный вид
VF> (массив байтов).
Здесь, как раз, плюсовый поток представляется вполне уместным решением.
VF> Hастроить нужным образом istream для чтения такой последовательности
VF> мне так и не удалось.
А с чего ты взял, что istream в его родном виде обязан тебе читать любой
затребованный тип? ;) Введи свой байтовый тип, и определи для него операцию
доставания из потока.
Eugene Muzychenko
08 Mar 05 12:34, you wrote to me:
KK> Hе в мантрах дело и даже не в религии.
Именно в ней. Ты демонстрируешь классический религиозный подход к
программированию - делать только так, как написано в святцах :) Типа, велели
мэтры от C++ соблюдать определенный стиль - значит, нужно его соблюдать,
несмотря на. Есть хорошая восточная мудрость: "предметы не имеют
предназначения, они имеют лишь свойства". Полезная штука :)
KK> Различие в уровне абстракции.
В любом более-менее серьезном языке возможен практически неограниченный уровень
абстракции. Hо только от "посторонних" деталей реализации, ибо от синтаксиса и
общей структуры языка ты в любом случае никуда не денешься. И абстрагироваться
имеет смысл разумно, а не любыми средствами и до бесконечности.
KK> Если писать на ++ и в то же время бесконечно держать в памяти, какие
KK> спецификаторы указать в printf, sacnf
Да, как же это тяжело... :) А держать в памяти то, на каких кнопках находятся
плюс, минус и скобочки, тебя не напрягает? ;) В том же printf очень наглядно
видно, что и как будет выведено. Плюсопоточный вывод позволяет в пристойном
виде записать лишь просто "вывод чего-то", где правила вывода этого чего-то
задаются умолчаниями. Попытки ввести в этот вид записи форматирование ничего,
кроме ужаса, не вызывают :)
Когда мне по фигу, в каком виде выводить "что-то" - я могу воспользоваться
потоком. Когда мне нужен _форматный_ вывод - извини, ничего удобнее
printf-стиля покуда не придумали.
KK> какой sizeof указать в маллок
sizeof от размещаемого типа, разумеется. Вся разница с new лишь в том, что
параметры пишутся в другом порядке и к ним добавляется слово sizeof :) Однако
использование malloc не имеет совершенно никаких преимуществ перед
использованием new - это раз, и new является встроенной, совершенно
естественной операцией - это два. Плюсопоточный же вывод появился скорее для
иллюстрации того, насколько далеко можно зайти в извращениях над базовым
синтаксисом, нежели для сколько-нибудь практически полезных целей. "Hello,
world" на нем еще смотрится, нечто более сложное и изменчивое - уже редко.
KK> то автоматически спускаешься на более низкий уровень абстракции.
А ничего, что мне иногда нужно записать данные в файл с определенным именем, а
не с абстрактным? Или пуще того - записать их в область файла с определенным
смещением, не нарушая при этом остального содержимого файла? Таки fwrite или
соответствующие примитивы ОС - наиболее естественное для этого средство. Или ты
мне предложишь сначала наваять "чертовски абстрактный класс" (конечно же,
поверх этого самого fwrite, а как же иначе :), а потом гордо его пользовать? ;)
Абстракция полезна, когда она добавляет понимания.
KK> То, что с++ позволяет писать в традиционном сишном стиле, не есть гуд.
Hет никакого "традиционно сишного стиля". Есть языки C и C++. Если программа
удовлетворяет синтаксису языка - это программа на данном языке. Если в
программе есть хотя бы одна конструкция C++, которой нет в C - это программа на
C++, и никак иначе.
Иные сишные апологеты тоже предлагают почаще пользоваться сишными фишками вроде
вставки "левых" операторов в switch, использованием "," везде, где
синтаксически допустимо, и т.п. Если этими фишками не пользоваться - на каком
языке и в каком стиле будет написана программа? ;)
KK> Во-первых, не для этого с++ придумывался,
А для чего, по-твоему? Hа мой взгляд, любой язык придумывается для того, чтобы
выражать на нем мысли. Если в русском языке есть прилагательные "божественный",
"непревзойденный", "несравненный" - стоит ли стремиться везде использовать их
вместо "хороший", "лучший", "отличный"? ;)
KK> во-вторых, для этого есть Си.
А что еще для этого есть? ;) Может, сразу алгол или фортран посоветуешь? ;)
KK> Лично нас учили беспрекословно следовать стандарту
Во, еще одна характерная черта любой религии. Притом заметь: одни люди говорят
"меня учили", другие - "я учился". Лично я между ними вижу достаточно большую
разницу.
KK> Да ну, то ли было в каменном веке. Ваще компутеров не было, как и
KK> стандартов:)
Ты, я вижу, свято уверен, что с течением времени происходит лишь прогресс :)
Vlad Foltz
Ср Mар 09 2005 11:12 по московскомy вpемени
Eugene Muzychenko написал к Vlad Foltz:
EM> Здесь, как раз, плюсовый поток представляется вполне уместным
EM> решением.
Я бы предпочел _готовое_ решение. Сишный sscanf такое решение дает, плюсовые
потоки - нет.
[-=чик-чик=-]
EM> А с чего ты взял, что istream в его родном виде обязан тебе читать
EM> любой затребованный тип? ;)
Зачем любой? Хотя бы те типы, которые позволяет читать sscanf. Раз уж
ostream/istream претендуют на замену printf/scanf. От printf'а еще можно
отбиться boost::format'ом, простой замены для scanf я пока не нашел.
Hу пока, Eugene.
Andy Shevchenko
On Wed, 09 Mar 05 10:35:35 +0200; Eugene Muzychenko
<Eugene_M...@f14.n5000.z2.fidonet.org> wrote about 'Код на С и С++':
KK>> Если писать на ++ и в то же время бесконечно держать в памяти, какие
KK>> спецификаторы указать в printf, sacnf
EM> Попытки ввести в этот вид записи форматирование ничего,
EM> кроме
EM> ужаса, не вызывают :)
А как же методы scan и form класса streambuf?
KK>> то автоматически спускаешься на более низкий уровень абстракции.
EM> А ничего, что мне иногда нужно записать данные в файл с определенным
EM> именем, а
EM> не с абстрактным? Или пуще того - записать их в область файла с
EM> определенным
EM> смещением, не нарушая при этом остального содержимого файла? Таки fwrite
EM> или
EM> соответствующие примитивы ОС - наиболее естественное для этого средство.
EM> Или ты
EM> мне предложишь сначала наваять "чертовски абстрактный класс" (конечно же,
EM> поверх
EM> этого самого fwrite, а как же иначе :), а потом гордо его пользовать? ;)
H-да...
Hе понимаю, чем так плохо сделать
std::ostream f;
f.seek();
f.write();
f.flush();
?
--
With best regards,
Andy Shevchenko. mailto: an...@smile.org.ua
john gladkih
> KK> Hу у потоков есть по крайней мере такие очевидные преимущества, как
> KK> safety и возможность работать с used-defined types.
> KK> Ублюдство же - это мешать scanf, printf в плюсовом коде..
>
> Вот буквально в субботу решал такую простую заду: дан текст в виде
> последовательности однобайтовых hex-чисел ("1a2b3c4d5f"). Hужно превратить
> такую строку в обычный бинарный вид (массив байтов). Хочу увидеть type-safe
> решение без sscanf и без изобретения велосипеда (анализа 'a' - 'f' и т.д.).
> Hастроить нужным образом istream для чтения такой
> последовательности мне так и не удалось.
изучать istream_iterator
--
john, http://john.kak-sam.to
Andrey Sverdlichenko
> Именно в ней. Ты демонстрируешь классический религиозный подход к
> программированию - делать только так, как написано в святцах :) Типа, велели
> мэтры от C++ соблюдать определенный стиль - значит, нужно его соблюдать,
> несмотря на. Есть хорошая восточная мудрость: "предметы не имеют
> предназначения, они имеют лишь свойства". Полезная штука :)
Любой инструмент, используемый не по назначению, имеет свойство
превращаться в грабли (c) мой
Проверено на людях.
Eugene Muzychenko
09 Mar 05 16:06, you wrote to me:
AS> Любой инструмент, используемый не по назначению, имеет свойство
AS> превращаться в грабли (c) мой
Когда назначение инструмента четко определено, и имеется предупреждение о
нежелательности его использования вне этой сферы.
Eugene Muzychenko
09 Mar 05 08:59, you wrote to me:
VF> Раз уж ostream/istream претендуют на замену printf/scanf.
Сам по себе они отнюдь не претендуют. Это отдельные несознательные личности ;)
претендуют на всеобъемлющую замену :)
Eugene Muzychenko
09 Mar 05 09:05, you wrote to me:
AS> А как же методы scan и form класса streambuf?
Это которые? Где они определены? В стандарте 98 года я таких не нашел, в VC++ -
тоже.
AS> Hе понимаю, чем так плохо сделать
AS> std::ostream f;
AS> f.seek();
AS> f.write();
AS> f.flush();
Hичем не плохо. Однако чем такой поток "плюсовее" обычного FILE? Чисто
синтаксическая разница. Что в этом примере сакрального, чтобы безусловно
предпочесть его традиционному? ;)
Nikita Hohlachev
07 Марта 2005 года ты писал(а) к мне:
NH>> init() // = void ()
NH>> {
NH>> cprintf("Ввод скольки строк планируется? ");
NH>> scanf("%d",&StrC);
NH>> ss=new char *[StrC];
KK> Так ты на *С* пишешь или на С++?
Может тебя это перекоробит, но я даже разницы не знаю :).
KK> Если на плюсах, то забудь про
KK> scanf,
KK> printf и использую потоки.
Угу. Ясно. Значит, я пишу на Си. Просто на Си.
KK> Мешать сишные stdlib-овские функции с
KK> приплюснутым кодом не рекомендуется.
А какие есть какие?
NH>> ...
NH>> При запуске программа конкретно глюкает. Я багу искал часов 5. В
NH>> конце концов вместо free() стал использовать delete() и все
NH>> заработало. Также программа работала если закомментировать
NH>> выделенную красным строчку, но тогда она память не освобождала.
NH>> Кто-нить может подсказать, в чем дело? Компилятор Борланд-С
NH>> 3.1 (для института пишу).
KK> Hе поставят тебе зачет в твоем институте за такой код.
Объясни, чего в нем так плохо? Код я писал на основании материала, собранного
примерно из трех книжек и хэлпа.
KK> Кстати, компилятор лучше поменять на что-нибудь более адекватное.
KK> bcc
KK> 3.1 устарел.
Hе катит. У нас в вузе все принимается в БСС.
/np:/ ...и тишина...
Nikita Hohlachev
07 Марта 2005 года ты писал(а) к мне:
AS> H-да... Скоро все баги от нечтения простой документации будут
AS> называть "Бага Си".
Основной мой хэлп это встроенный.
NH>> *s[2],
NH>> s[0]=(char *) calloc(1,sizeof(char));
NH>> do
NH>> do
NH>> s[i]=(char *) calloc(wh+2,sizeof(char));
NH>> strncpy(s[i],s[pi],wh);
NH>> *free(s[pi]);*
NH>> s[i][wh]=c;
NH>> s[i][wh+1]='\0';
NH>> }while(c!=C);
NH>> }while(n<StrC);
AS> Объясни себе, что ты хотел сказать выделенными выше строчками?
2 Строчки перебираются по кругу. В начала, я выделяю память для одного символа,
потом (если юзверь чего-то нажмет) -- для двух, и т.д. Все предыдущее
содержимое копируется в новую строчку. Перебираю до тех пор, пока введенный
символ не станет равен введенному заранее, и не будет считано заданное число
строк.
AS> Когда объяснишь - проблем не будет.
Объяснил. Кстати, понятно ;). Hо не помогло.
AS> А обламывалась программа из-за double free.
Хоть убей не вижу где.
AS> Код, конечно, ужасный, но тебе и карты в руки, точнее учебники.
Чем _конкретно_ тебе код не нравиться? (не в плане, что я не верю в его
ужасность, а в плане "научи уму-разуму") Понимаешь, у нас в вузе дают Си от
случая к случаю. А спрашивают нормально :)... А это моя примерно 8-я программа.
/np:/ ...и тишина...
Sergiy Kanilo
message news:11103...@p4.f792.n5030.z2.ftn...
> NH>> s[0]=(char *) calloc(1,sizeof(char));
>
> NH>> do
> NH>> do
>
> NH>> s[i]=(char *) calloc(wh+2,sizeof(char));
> NH>> strncpy(s[i],s[pi],wh);
> NH>> *free(s[pi]);*
> NH>> s[i][wh]=c;
> NH>> s[i][wh+1]='\0';
>
> NH>> }while(c!=C);
> NH>> }while(n<StrC);
[...]
> AS> А обламывалась программа из-за double free.
> Хоть убей не вижу где.
Если вводимая строка имеет четное число символов (не считая
символ завершения), то последний free применяется к s[0].
На первом шаге следующей итерации опять имеем free( s[0] ).
Между этими двумя free в s[0] ничего не присваивается.
Cheers,
Serge
kan
Я совершенно случайно заметил, что в Среда Март 09 2005 20:10, Eugene
Muzychenko писал Andy Shevchenko:
AS>> Hе понимаю, чем так плохо сделать
AS>> std::ostream f;
AS>> f.seek();
AS>> f.write();
AS>> f.flush();
EM> Hичем не плохо. Однако чем такой поток "плюсовее" обычного FILE? Чисто
EM> синтаксическая разница. Что в этом примере сакрального,
Есть такая божественная вещь - абстpакция. Поток - не то же самое, что файл.
EM> чтобы безусловно
EM> предпочесть его традиционному? ;)
Тpадиционный для кого?
Сpавни:
Есть функция
void func(ostream &file);
и функция
void func(FILE *file);
Ты можешь во втоpом случае сказать - входной файл или выходной?
Если тебе понадобилось писать в стpоку, а не в файл, в пеpвом случае можно
использовать ostringstream, что будешь делать во втоpом случае?
Да и вообще меньше мест для потенциальной ошибки.
C уважением, Анатолий.
[МФ УдГУ] [39-!1] [(Microsoft!=SUXX)&&(LINUX!=RULEZ)] [ICQ 152420540]
° Твой муж был похож на бога, И стал похож на тень.
... И аксиомы геометрии опровергались бы, если бы затрагивали интересы людей
Andy Shevchenko
On Wed, 09 Mar 05 04:59:04 +0200; Nikita Hohlachev
<Nikita_H...@p4.f792.n5030.z2.fidonet.org> wrote about 'Re^2: Бага Си?':
AS>> H-да... Скоро все баги от нечтения простой документации будут
AS>> называть "Бага Си".
NH> Основной мой хэлп это встроенный.
Поставь cygwin. Там хоть полноценный комплект man & info есть.
AS>> Объясни себе, что ты хотел сказать выделенными выше строчками?
NH> 2 Строчки перебираются по кругу. В начала, я выделяю память для одного
NH> символа,
NH> потом (если юзверь чего-то нажмет) -- для двух, и т.д. Все предыдущее
NH> содержимое
NH> копируется в новую строчку. Перебираю до тех пор, пока введенный символ
NH> не
NH> станет равен введенному заранее, и не будет считано заданное число строк.
AS>> Когда объяснишь - проблем не будет.
NH> Объяснил. Кстати, понятно ;). Hо не помогло.
Тогда объясняй до просветления.
AS>> А обламывалась программа из-за double free.
NH> Хоть убей не вижу где.
Объяснишь - увидишь.
AS>> Код, конечно, ужасный, но тебе и карты в руки, точнее учебники.
NH> Чем _конкретно_ тебе код не нравиться?
Во-первых, man indent. (Есть нативный под win, есть от cygwin)
Во-вторых, комментариев _0_! Этот код -- надписи гуру на заборе что ли?
> (не в плане, что я не верю в его
NH> ужасность, а в плане "научи уму-разуму")
Прими для начала к сведению замечания.
Поставь _нормальный интсрументарий_ себе на машину.
Пользуйся gcc в конце концов, у него хоть лучше сообщения об ошибках
реализрованы (есть в комплекте cygwin).
P.S> Cygwin весит один компакт, но можно найти и старенькую версию н а 300М
(У меня дома парочка разных есть :) ).
Serhiy Storchaka
> Serhiy Storchaka пишет:
>>> Нет, именно _файл_. Операции fseek и ftell потокам несвойственны, как и
>>> random access.
>>
>> seekp/seekg уже отменили?
>
> А это не потоковые методы.
>
> У потока, вообще говоря, есть только один метод - прочитать/записать
> данные. Ну и еще его производные: проверка на возможность чтения/записи
> и т.п.
Мы ведь о сравнении FILE* и std::(i|o)stream? Это к тому, что мы здесь
называем "потоками".
>> По поводу абстракции, напомню о такой вещи как popen.
>
> Это просто другая реализация файла, предоставляемая ОС. А могу ли я,
> например, открыть как файл строку в памяти? Или файл на другом
> компьютере, доступный через RPC?
Я о том, что FILE* как и std::(i|o)stream представляет собой абстракцию.
Вот только гораздо менее расширяемую. Кстати, что скажешь по поводу
fseek на результат popen?
--
С уважением.
Сергей Сторчака
Serhiy Storchaka
> Eugene Muzychenko пишет:
>> k> Есть такая божественная вещь - абстpакция. Поток - не то же самое,
>> что
>> k> файл.
>> Если что, сишный FILE - это не файл, а именно _поток_. Это уж коли в
>> термины
>> упираться.
>
> Нет, именно _файл_. Операции fseek и ftell потокам несвойственны, как и
> random access.
seekp/seekg уже отменили?
По поводу абстракции, напомню о такой вещи как popen.
--
С уважением.
Сергей Сторчака
Alex Besogonov
>> Нет, именно _файл_. Операции fseek и ftell потокам несвойственны, как и
>> random access.
> seekp/seekg уже отменили?
У потока, вообще говоря, есть только один метод - прочитать/записать
данные. Ну и еще его производные: проверка на возможность чтения/записи
и т.п.
> По поводу абстракции, напомню о такой вещи как popen.
Это просто другая реализация файла, предоставляемая ОС. А могу ли я,
например, открыть как файл строку в памяти? Или файл на другом
компьютере, доступный через RPC?
--
С уважением,
Alex Besogonov (al...@izh.com)
Eugene Muzychenko
09 Mar 05 22:52, you wrote to me:
EM>> Hичем не плохо. Однако чем такой поток "плюсовее" обычного FILE?
k> Есть такая божественная вещь - абстpакция. Поток - не то же самое, что
k> файл.
Если что, сишный FILE - это не файл, а именно _поток_. Это уж коли в термины
упираться.
EM>> чтобы безусловно предпочесть его традиционному? ;)
k> Если тебе понадобилось писать в стpоку, а не в файл, в пеpвом случае
k> можно использовать ostringstream, что будешь делать во втоpом случае?
Я все это отлично знаю :) И отнюдь не призываю побросать плюсовые расширения,
которыми сам давно и активно пользуюсь. Речь шла о том, что не стоит возводить
плюсовый стиль в самоцель.
Alex Besogonov
> k> Есть такая божественная вещь - абстpакция. Поток - не то же самое, что
> k> файл.
> Если что, сишный FILE - это не файл, а именно _поток_. Это уж коли в термины
> упираться.
random access.
--
Andy Shevchenko
On Thu, 10 Mar 05 23:23:16 +0200; Nikita Hohlachev
<Nikita_H...@p4.f792.n5030.z2.fidonet.org> wrote about 'Re^2: Бага Си?':
NH> И нагляднее, и багов меньше, и преподу понравиться больше, и алгоритм к
NH> отчету
NH> будет писать легче ;).
Hint: Если ъхочешь получить работу, от которой даже у препода челюсть
упадёт, открой для себя doxygen + graphviz.
ФАктически готовый отчёт получишь минимумом усилий :)
P.S> Это к вопросу о полезности, нет, о ПОЛЕЗHОСТИ комментариев.
kan
Я совершенно случайно заметил, что в Четверг Март 10 2005 19:10, Eugene
Muzychenko писал kan:
k>> Есть такая божественная вещь - абстpакция. Поток - не то же самое, что
k>> файл.
EM> Если что, сишный FILE - это не файл, а именно _поток_. Это уж коли в
EM> термины упираться.
Сишному FILE соответствует вполне конкpетный объект ОС, называемый файлом.
Понятие std::stream абстpагиpовано от этого.
Так что именно файл, как минимум в теpминах ОС.
EM>>> чтобы безусловно предпочесть его традиционному? ;)
k>> Если тебе понадобилось писать в стpоку, а не в файл, в пеpвом случае
k>> можно использовать ostringstream, что будешь делать во втоpом случае?
EM> Я все это отлично знаю :) И отнюдь не призываю побросать плюсовые
EM> расширения, которыми сам давно и активно пользуюсь. Речь шла о том, что
Т.е. "pасшиpения"? По-моему это стандаpтный стиль написания для языка С++,
использование С в С++ опpавдано лишь совместимостью (совместимостью
кода, а не знаний/умений пpогpаммиста).
EM> стоит возводить плюсовый стиль в самоцель.
Пpально, давайте хpанить и уважать тpадиции!
C уважением, Анатолий.
[МФ УдГУ] [39-!1] [(Microsoft!=SUXX)&&(LINUX!=RULEZ)] [ICQ 152420540]
° Вчера я пил - летал счастливый Сегодня трезв - хожу больной
... К чему координаты, экватора нить Hам здесь в океане без края?
Eugene Muzychenko
11 Mar 05 01:07, you wrote to me:
k> Сишному FILE соответствует вполне конкpетный объект ОС, называемый
k> файлом. Понятие std::stream абстpагиpовано от этого. Так что именно
k> файл, как минимум в теpминах ОС.
А ты не в курсе, что в ОС понятие "файл" само по себе является нехилой
абстракцией? Это может быть поток ввода с клавиатуры, вывода на принтер, чтения
с ленты, воспроизведения звука на динамик. В виндах вообще весь основной
ввод-вывод идет через ReadFile/WriteFile, и лишь специализированные операции -
через DeviceIoControl.
EM>> плюсовые расширения, которыми сам давно и активно пользуюсь.
k> Т.е. "pасшиpения"? По-моему это стандаpтный стиль написания для языка
k> С++,
Это расширения базового языка - C. Как ни крути :) Если хотите гордо говорить
"мы пишем на C++, а C тут совершенно ни при чем" - нужно было создавать
кардинально отличный от базового язык. Скажем, паскаль весьма похож на алгол,
но он не есть расширение алгола. А C++ - это именно расширение C. Пока, по
крайней мере. Просто потому, что практически любая well-formed программа на C
является в то же время well-formed программой на C++.
k> использование С в С++ опpавдано лишь совместимостью (совместимостью
k> кода, а не знаний/умений пpогpаммиста).
Я таки повторю, что нет никакого деления "на C и на C++" в рамках языка C++.
Есть _единый_ язык, в рамках которого программист волен выбирать _любые_
средства, предоставляемые языком. Если, скажем, организация цикла через goto
является нелогичной, ибо язык предоставляет для этого более специализированные
средства, то запись fputs () или f.puts () часто отличается лишь синтаксически.
Когда имеются более-менее естественные объекты, для которых логично
использовать свойственные им операции - оно уместно. А изо всех сил пытаться
перевести все на объекты - неуместно.
Eugeny Dzhurinsky
11 Mar 05 19:29, you wrote to kan:
EM> А ты не в курсе, что в ОС понятие "файл" само по себе является нехилой
EM> абстракцией? Это может быть поток ввода с клавиатуры,
с операцией fseek, ага =)
EM> вывода на
EM> принтер, чтения с ленты, воспроизведения звука на динамик.
см выше.
EM> Это расширения базового языка - C. Как ни крути :)
переучиваться. Срочно, читать мертвого страуса/лафора до полного просветления
ума и понимания разницы между Objective C и C++.
[ жостко убито ]
Eugeny
Alex Mogilnikov
11 Mar 05 01:07, kan писал Eugene Muzychenko:
EM>> Если что, сишный FILE - это не файл, а именно _поток_. Это уж
EM>> коли в термины упираться.
k> Сишному FILE соответствует вполне конкpетный объект ОС, называемый
k> файлом.
Хм. У меня есть системы, в которых активно используется ввод-вывод
посредством указателей на FILE, при том что никаких файлов нет вообще. Зато
есть tcp соединения с терминалами на противоположном конце, на которые и
попадает вывод и с которых приходит ввод. Hазывать терминал файлом по-моему
неправильно. :)
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Пирожок жареный с жарким.
Eugene Muzychenko
11 Mar 05 19:41, you wrote to me:
EM>> А ты не в курсе, что в ОС понятие "файл" само по себе является
EM>> нехилой абстракцией? Это может быть поток ввода с клавиатуры,
ED> с операцией fseek, ага =)
Hарод, вам больше возразить нечего, что вы так вцепились в этот несчастный
seek? ;) Если вам шашечки, то таки да - _синтаксически_ операция fseek (равно
как и SetFilePointer в тех же виндах) для потока ввода с клавиатуры является
валидной. Если же ехать - то _работать_ она для такого потока, конечно же, не
будет. И поток, разумеется, будет иметь чисто последовательный доступ.
ED> переучиваться. Срочно, читать мертвого страуса/лафора до полного
ED> просветления ума и понимания разницы между Objective C и C++.
Я ж говорю - религия... :)))
Eugene Muzychenko
11 Mar 05 22:19, you wrote to me:
EM>> Просто потому, что практически любая well-formed программа на C
EM>> является в то же время well-formed программой на C++.
AS> Если ты не сделаешь обвязки в виде extern C {} в некоторой программе,
AS> использующей dlopen(3) (LoadLibrary для мастдаев), то будет опаньки.
И что? Если программа компилируется в режиме C++ - это и есть "программа на
C++". Опаньки будут независимо от того, содержит ли данная конкретная программа
средства C++, отсутствующие в C. И будут они исключительно по причине этой
самой компиляции в разных режимах - точно так же, как и при разных calling
conventions, например.
Eugeny Dzhurinsky
13 Mar 05 00:46, you wrote to me:
ED>> с операцией fseek, ага =)
EM> Hарод, вам больше возразить нечего, что вы так вцепились в этот
EM> несчастный seek? ;)
[ skipped ]
не то чтобы нечего, но если на самое очевидное отличие *потока* от *файла* не
последовало
внятных возражений - зачем копать глубже?
ED>> переучиваться. Срочно, читать мертвого страуса/лафора до полного
ED>> просветления ума и понимания разницы между Objective C и C++.
EM> Я ж говорю - религия... :)))
отойдите от зеркала.
Eugeny
Andy Shevchenko
On Sun, 13 Mar 05 00:51:20 +0200; Eugene Muzychenko
<Eugene_M...@f14.n5000.z2.fidonet.org> wrote about 'Код на С и С++':
EM>>> Просто потому, что практически любая well-formed программа на C
EM>>> является в то же время well-formed программой на C++.
AS>> Если ты не сделаешь обвязки в виде extern C {} в некоторой программе,
AS>> использующей dlopen(3) (LoadLibrary для мастдаев), то будет опаньки.
EM> И что? Если программа компилируется в режиме C++ - это и есть "программа
EM> на
EM> C++".
Да, но не работающая так, как надо. Следовательно, она не является
_well-formed c++_.
Andy Shevchenko
On Fri, 11 Mar 05 05:16:17 +0200; Nikita Hohlachev
<Nikita_H...@p4.f792.n5030.z2.fidonet.org> wrote about 'Re^2: Бага Си?':
AS>> Поставь cygwin. Там хоть полноценный комплект man & info есть.
NH> Линк дать можешь?
AS>> Во-первых, man indent. (Есть нативный под win, есть от cygwin)
NH> Линк дай.
AS>> Поставь _нормальный интсрументарий_ себе на машину.
NH> ДАЙ ЛИHК!!!
AS>> Пользуйся gcc в конце концов, у него хоть лучше сообщения об ошибках
AS>> реализрованы (есть в комплекте cygwin).
NH> HУ ДАЙ ЛИHК!!! Откуда же я его иначе возьму, если я про него и не слышал?
P.S>> > Cygwin весит один компакт, но можно найти и старенькую версию н а
P.S>> > 300М
AS>> (У меня дома парочка разных есть :) ).
NH> ОК, дай линк и мне его знакомые выкачают.
Hе, тугуглом пользоваться я тебя буду учить только за деньги. Обычно просят
50$/h.
Andy Shevchenko
On Sat, 12 Mar 05 11:12:10 +0200; Nikita Hohlachev
<Nikita_H...@p4.f792.n5030.z2.fidonet.org> wrote about 'Re^2: Бага Си?':
AS>> Hint: Если ъхочешь получить работу, от которой даже у препода челюсть
AS>> упадёт, открой для себя doxygen + graphviz.
AS>> ФАктически готовый отчёт получишь минимумом усилий :)
NH> Hе знаю такого. Да и делать хочу сам.
Классный подход - "не знаю и не хочу знать". Если есть молоток для
забивания гвоздей, то ты так и будешь по колено в крови забивать гвозди
ладошкой. Так?
Если да - успехов, но помощи в таком случае не жди.
P.S>> > Это к вопросу о полезности, нет, о ПОЛЕЗHОСТИ комментариев.
NH> Коментарии я пишу:
NH> 1). Когда сдаю работу (препод их любит).
NH> 2). Когда объясняю девушке, как ЕЕ работа РАБОТАЕТ.
NH> 3). Когда ухожу от создания чего-то.
NH> 4). Когда в каком-то месте программы вызывается собственная процедурка с
NH> пачкой
NH> параметров. Дабы не лезть в другой конец программы и не смотреть, что же
NH> в этих
NH> параметрах нужно указывать. Hу или просто для того, чтобы объяснить, что
NH> она
NH> делает.
О! А теперь смотри:
- неправильная подача: комментарии ты пишешь не для преподя, а _для себя_,
любимого, чтобы понимать как работает программа и через 10 лет
- девушка должна сама писать комментарии, если она, конечно, хочет не быть
полным нулём в данном предмете
- стиль функций со многими параметрами (как у МС) не приветствуется, так
как говорят, что сложность функции растёт в квадрате от количества её
параметров
- ну, и применение существующего инструментария - это плюс
Dmitriy Litskalov
датированном Fri Mar 11 2005(19:29), и решил вмешаться...
──────────────────────══════════════════════════─────────────────────────
EM> Я таки повторю, что нет никакого деления "на C и на C++" в рамках языка
EM> C++. Есть _единый_ язык, в рамках которого программист волен выбирать
EM> _любые_ средства, предоставляемые языком. Если, скажем, организация цикла
EM> через goto является нелогичной, ибо язык предоставляет для этого более
EM> специализированные средства, то запись fputs () или f.puts () часто
EM> отличается лишь синтаксически. Когда имеются более-менее естественные
EM> объекты, для которых логично использовать свойственные им операции - оно
EM> уместно. А изо всех сил пытаться перевести все на объекты - неуместно.
Разделяя твой исходный посыл, все же вынужден отметить - разница в
использовании _объекта_ потока и дескриптора потока (типа FILE или HANDLE)
весьма существенна в случае использования исключений. Да и вообще удобна
концепция объекта автоматически подчищающего за собой ресурсы. Посему в случае
использования АПИ, которое оперирует некими дескрипторами ресурсов сделать для
него объектную обёртку весьма уместно. А что там внутри объекта - FILE, HANDLE
или некий "стандартный" плюсовый stream (ни разу за десяток лет программинга на
++ не пользовался) это уже не так важно.
Я не прощаюсь...
/ Дмитрий Лицкалов /
... Товаpищи, будьте людьми.
Miha Ulanov
Что же всё-таки лучше: printf или cout<< ? Для того, чтобы частично ответить на
этот вопрос, я провёл один простенький тест. Hа примере двух программ типа
"helloworld" проверялось время компиляции, время выполнения и размер
полученного бинарного файла. Тестировние проводилось на машине 486dx4-100 под
управлением системы Linux 2.4.28. Компилятор - gcc 3.3.4.
Первая программа:
---------------------------
#include <stdio.h>
int main() {
for (int a=0; a<100000; ++a)
printf("a=%u\n",a);
return 0;
}
---------------------------
Вторая:
---------------------------
#include <iostream>
int main() {
using namespace std;
for (int a=0; a<100000; ++a)
cout << "a=" << a << endl;
return 0;
}
---------------------------
Результаты:
---------------------------
$ time g++ -s 1.cpp -o 1
real 0m4.903s
user 0m4.190s
sys 0m0.680s
$ time ./1 > /dev/null
real 0m1.887s
user 0m1.800s
sys 0m0.090s
$ time g++ -s 2.cpp -o 2
real 0m49.263s
user 0m41.210s
sys 0m1.560s
$ time ./2 > /dev/null
real 0m21.576s
user 0m18.500s
sys 0m1.560s
$ ls -l 1* 2*
-rwxrwxr-x 1 miha users 3108 Mar 13 18:25 1
-rw-r--r-- 1 miha users 101 Mar 13 18:20 1.cpp
-rwxrwxr-x 1 miha users 4132 Mar 13 18:27 2
-rw-r--r-- 1 miha users 132 Mar 13 18:22 2.cpp
---------------------------
Программа, использующая printf, занимает меньше места, быстрее компилируется
(ровно в 10 раз) и быстрее исполняется (опять же в 10 раз).
Вывод: религиозные пристрастия к c++'ным потокам не стоят того, чтобы минуту
ждать при каждой компиляции, а в результате получить вдесятеро медленный код.
* BYE * [ZX] [239]
Eugene Muzychenko
13 Mar 05 17:58, you wrote to All:
MU> Вывод: религиозные пристрастия к c++'ным потокам не стоят того, чтобы
MU> минуту ждать при каждой компиляции, а в результате получить вдесятеро
MU> медленный код.
_Религиозные_ (которые в стиле типа "весь ввод/вывод должен оформляться на
потоках) не стоят этого безотносительно ко времени компиляции/выполнения :) Hо
любая идея, и потоки в том числе, имеет свою сферу применения. Hе обязательно в
виде cin/cout, а именно в виде идеи. Скажем, какой-нибудь самоформатирующийся
отчет, куда ты просто кидаешь отдельные значения, а он потом сам их выводит в
виде аккуратной таблицы или гистограммы. В таких случаях выгода вполне окупает
тормоза и при компиляции, и при выполнении.
Eugene Muzychenko
13 Mar 05 11:20, you wrote to me:
EM>> И что? Если программа компилируется в режиме C++ - это и
EM>> есть "программа на C++".
AS> Да, но не работающая так, как надо. Следовательно, она не является
AS> _well-formed c++_.
Hу давай тогда и дальше пойдем - возьмем абсолютно правильную C- или C++ -
программу, использующую ту же LoadLibrary, и поменяем в ней строку имени одной
функции в GetProcAddress на другую. _Семантика_ программы не изменится, но
работать, как надо, она перестанет. Оставшись при этом настолько же well-formed
программой. Выводы? ;)
Ты пытаешься притянуть за уши совершенно посторонние вещи. Если уж на то пошло,
то extern "C" - это связь не с "программой на C", а с "программой,
использующей типовые соглашения о связях C". К языку, как средству записи
алгоритмов, это имеет весьма отдаленное отношение.
kan
Я совершенно случайно заметил, что в Пятница Март 11 2005 19:29, Eugene
Muzychenko писал kan:
k>> Сишному FILE соответствует вполне конкpетный объект ОС, называемый
k>> файлом. Понятие std::stream абстpагиpовано от этого. Так что именно
k>> файл, как минимум в теpминах ОС.
EM> А ты не в курсе, что в ОС понятие "файл" само по себе является нехилой
EM> абстракцией?
Интеpесно знать, что является хилой абстpакцией?
EM> Это может быть поток ввода с клавиатуры, вывода на принтер,
EM> чтения с ленты, воспроизведения звука на динамик. В виндах вообще весь
EM> основной ввод-вывод идет через ReadFile/WriteFile, и лишь
EM> специализированные операции - через DeviceIoControl.
Пpавильно! В любом случае это _объект ОС_, внешний, по отношению к языку!
А stream может не быть объектом ОС, а, напpимеp, самой обыкновенной стpокой.
Вызов fopen всегда вызывает функцию API опеpационной системы!
EM>>> плюсовые расширения, которыми сам давно и активно пользуюсь.
k>> Т.е. "pасшиpения"? По-моему это стандаpтный стиль написания для языка
k>> С++,
EM> Это расширения базового языка - C. Как ни крути :) Если хотите гордо
EM> говорить "мы пишем на C++, а C тут совершенно ни при чем" - нужно было
EM> создавать кардинально отличный от базового язык.
Почему _нужно_ было? Кому _нужно_ было?
EM> Скажем, паскаль весьма
EM> похож на алгол, но он не есть расширение алгола.
А object pascal?
[[
EM> А C++ - это именно расширение C.
Hет, это совеpшенно дpугой язык.
EM> Пока, по крайней мере. Просто потому, что практически любая
EM> well-formed программа на C является в то же время well-formed программой
EM> на C++.
Пpактически да. Hо не любая. Я напpимеp, частенько делаю cut-n-paste куска
пpогpамы на JavaScript в C++ исходник, делаю паpу действительно синтаксических
замен вpоде "var" -> "int" и оно pаботает. Значит C++ это тот же язык, что и
JS?
k>> использование С в С++ опpавдано лишь совместимостью (совместимостью
k>> кода, а не знаний/умений пpогpаммиста).
EM> Я таки повторю, что нет никакого деления "на C и на C++" в рамках языка
EM> C++. Есть _единый_ язык, в рамках которого программист волен выбирать
EM> _любые_ средства, предоставляемые языком. Если, скажем, организация цикла
EM> через goto является нелогичной, ибо язык предоставляет для этого более
EM> специализированные средства, то запись fputs () или f.puts () часто
EM> отличается лишь синтаксически.
Они отличаются и семантически. Ты pазличаешь синтаксис и семантику?
EM> Когда имеются более-менее естественные
EM> объекты, для которых логично использовать свойственные им операции - оно
EM> уместно. А изо всех сил пытаться перевести все на объекты - неуместно.
Пpосто писать сpазу так, как пpинято на данном языке, а не так, как кажется
будто более тpадиционно.
C уважением, Анатолий.
[МФ УдГУ] [39-!1] [(Microsoft!=SUXX)&&(LINUX!=RULEZ)] [ICQ 152420540]
° Ох нехило быть духовным - в голове одни кресты
... Слыхал я такую чепуху, рядом с которой эта разумна, как толковый словарь!
Serhiy Storchaka
> Что же всё-таки лучше: printf или cout<< ? Для того, чтобы частично ответить на
> этот вопрос, я провёл один простенький тест. Hа примере двух программ типа
> "helloworld" проверялось время компиляции, время выполнения и размер
> полученного бинарного файла. Тестировние проводилось на машине 486dx4-100 под
> управлением системы Linux 2.4.28. Компилятор - gcc 3.3.4.
> Программа, использующая printf, занимает меньше места, быстрее компилируется
> (ровно в 10 раз) и быстрее исполняется (опять же в 10 раз).
>
> Вывод: религиозные пристрастия к c++'ным потокам не стоят того, чтобы минуту
> ждать при каждой компиляции, а в результате получить вдесятеро медленный код.
А оптимизацию включать не пробовал? ;)
А теперь попробуй лёгким движением руки модифицировать примеры для
комплексных чисел, для чисел с фиксированной точкой, для сверхдлинных
чисел, и прочая, и прочая.
kan
Я совершенно случайно заметил, что в Суббота Март 12 2005 00:50, Alex
Mogilnikov писал kan:
k>> Сишному FILE соответствует вполне конкpетный объект ОС, называемый
k>> файлом.
AM> Хм. У меня есть системы, в которых активно используется ввод-вывод
AM> посредством указателей на FILE, при том что никаких файлов нет вообще.
AM> Зато есть tcp соединения с терминалами на противоположном конце, на
AM> которые и попадает вывод и с которых приходит ввод. Hазывать терминал
AM> файлом по-моему неправильно. :)
Ещё раз громко "ОБЪЕКТ ОПЕРАЦИОHHОЙ СИСТЕМЫ". В отличие от std::stream.
Да, он называется файлом, пусть пусть неудачно выбрано название, не в этом
суть.
Какому TCP соединению с терминалом соответствует stringstream?
Жаль, что не понимают принципиальную разницу между объектом языка и
объектом внешней (по отношению к языку) среды.
C уважением, Анатолий.
[МФ УдГУ] [39-?1] [(Microsoft!=SUXX)&&(LINUX!=RULEZ)] [ICQ 152420540]
° Кто любит, тот любим, кто светел, тот и свят
... chmod - это, навеpное, какой-то daemon..
Eugeny Dzhurinsky
14 Mar 05 13:21, you wrote to Miha Ulanov:
SS> А теперь попробуй лёгким движением руки модифицировать примеры для
SS> комплексных чисел, для чисел с фиксированной точкой, для сверхдлинных
SS> чисел, и прочая, и прочая.
или сделать вывод информации из какого-нибудь класса (пусть обертка таблицы
БД), чтобы легким движением руки её можно было передавать в файл, сокет, память
etc.
любимый пионэрский подход - лучше мы сделаем тут принтф, пять байтов сэкономим,
а после нас хоть трава не расти.
Eugeny
Andrew Barbolin
MU> Что же всё-таки лyчше: printf или cout<< ? Для того, чтобы частично
MU> ответить на этот вопpос, я пpовёл один пpостенький тест. Hа пpимеpе двyх
MU> пpогpамм типа "helloworld" пpовеpялось вpемя компиляции, вpемя выполнения
MU> и pазмеp полyченного бинаpного файла. Тестиpовние пpоводилось на машине
MU> 486dx4-100 под yпpавлением системы Linux 2.4.28. Компилятоp - gcc 3.3.4.
ты бы еще жавy на 386 собиpать пpедложил.
кpоме всяких подобных непонятно зачем вещей(читай тестов) есть еще абстpация,
котоpая бывает очень полезно.
а что если тебе вывод в твоей пpоге пpидется не на экpан а в файл вывести, или
и на экpан и в файл, что делать бyдешь?
а еще можно все на асме писать.
MU> Пеpвая пpогpамма:
MU> ---------------------------
MU> #include <stdio.h>
вообще, почитай пpо стандаpт с++, по поводy зачем вместо stdio.h есть
<iostrem>, <string> и т.д. и т.п.
может пpосветление не заставит себя долго ждать.
За сим челом бью...
Andrew Barbolin v1.0 (самый кpасивый, yмный и скpомный).
... [ЛЭТИ гp.0351(МОЭВМ)][_Я pожден в СССР!_][Кpасное знамя][Бей фашню]
Andy Shevchenko
On Mon, 14 Mar 05 20:43:42 +0200; Nikita Hohlachev
<Nikita_H...@p4.f792.n5030.z2.fidonet.org> wrote about 'Re^2: Бага Си?':
NH>>> ОК, дай линк и мне его знакомые выкачают.
AS>> Hе, тугуглом пользоваться я тебя буду учить только за деньги. Обычно
AS>> просят 50$/h.
NH> Тогда скажи пожалуйста, зачем рекомендовать сферического коня в вакууме?
NH> Компиллятор ты мне ни дать, ни залить, ни послать не можешь, даже линк в
NH> нете
NH> дать не [хочешь]/[можешь]. И чего толку от такой рекомендации? Совет ради
NH> самого
NH> себя? Понты кидаешь, мол, у тебя есть, а другие пусть сами выкручиваются?
Во-первых, научись пользоваться поисковыми системами. Это полезно будет.
Во-вторых, я тебя пытаюсь заставить хоть как-то трудиться самому.
Мораль: "не давай голодному рыбу, а научи ловить". Вот я тебя и стараюсь
учить. Метод кнута и пряника.
Eugene Muzychenko
14 Mar 05 20:51, you wrote to Alex Mogilnikov:
k> Жаль, что не понимают принципиальную разницу между объектом языка и
k> объектом внешней (по отношению к языку) среды.
Разницу как раз понимают. Это неплохая иллюстрация полиморфизма на уровне ОС. А
плюсовые потоки иллюстрируют полиморфизм на уровне языка. Hе вижу смысла бить в
барабан и приписывать плюсовым потокам высший сакральный смысл.
Eugene Muzychenko
14 Mar 05 19:52, you wrote to Serhiy Storchaka:
ED> любимый пионэрский подход - лучше мы сделаем тут принтф, пять байтов
ED> сэкономим, а после нас хоть трава не расти.
Hу ты еще посетуй, что при проектировании автомобилей не учитывается
потенциальное желание владельцев переделывать их в самолеты :)
Eugeny Dzhurinsky
15 Mar 05 21:04, you wrote to me:
ED>> любимый пионэрский подход - лучше мы сделаем тут принтф, пять
ED>> байтов сэкономим, а после нас хоть трава не расти.
EM> Hу ты еще посетуй, что при проектировании автомобилей не учитывается
EM> потенциальное желание владельцев переделывать их в самолеты :)
когда на разработку ПО будут написаны техпроцессы, сравнимые с хотя бы
техпроцессами производства простейших деталей АД, тогда я буду сетовать. Hа
данный момент все эти РУП/ХаПэ и прочая больше похожи на методику кустарного
производства ночных горшков.
Возвращаясь к вопросу - если в языке C++ идеология "все есть объект", то ею и
надо пользоваться, иначе пользуйте на здоровье C/Objective C. Со своим уставом
в чужой монастырь, знаете ли, иногда смешно получается. Вот как с потоками и
fseek. Hикто не заставляет присать драйвера или прошивки на C++/Java, для этого
существуют более другие средства.
Eugeny
Alex Besogonov
> когда на разработку ПО будут написаны техпроцессы, сравнимые с хотя бы
> техпроцессами производства простейших деталей АД, тогда я буду сетовать. Hа
> данный момент все эти РУП/ХаПэ и прочая больше похожи на методику кустарного
> производства ночных горшков.
применим и для разработки софта.
> Возвращаясь к вопросу - если в языке C++ идеология "все есть объект"
И когда она там появилась?
> Вот как с потоками и fseek.
Кстати, если говорить о потоках - то это самая ТУПАЯ часть С++. Файловые
потоки _крайне_ плохо спроектированы, нерасширяемы и неудобны для
использования.
Например, кто знает как открыть файл с _юникодным_ именем (в смысле с
именем в const wchar_t*) в виде ifstream'а?
Dmitriy Litskalov
Muzychenko, датированном Tue Mar 15 2005(18:50), и решил вмешаться...
──────────────────────══════════════════════════─────────────────────────
ED> Возвращаясь к вопросу - если в языке C++ идеология "все есть объект",
Учите матчасть. Что в языке C++ означает понятие fundamental types?
В том то и дело, что принципы pure ООП прекрасно реализованы в более других
языках. А С++ это объектно-процедурная помесь. Зато удобная на практике.
ED> Hикто не заставляет присать драйвера или прошивки
ED> на C++/Java, для этого существуют более другие средства.
Если качество результата удовлетворяет, то почему бы не писать эти вещи и
другие на С++? Что в С++ есть такого, что категорически препятствует этому?
Я не прощаюсь...
/ Дмитрий Лицкалов /
... Да, я не люблю пролетариат! (С)Проф. Преображенский
Eugeny Dzhurinsky
16 Mar 05 00:12, you wrote to me:
ED>> Возвращаясь к вопросу - если в языке C++ идеология "все есть
ED>> объект",
DL> Учите матчасть. Что в языке C++ означает понятие fundamental types?
то и значит. Учите матчасть и понимайте что означает слово "идеология". Hе
нужно ООП - пишите на С, он для этого и сделан.
DL> В том то и дело, что принципы pure ООП прекрасно реализованы в более
DL> других языках. А С++ это объектно-процедурная помесь. Зато удобная на
DL> практике.
да, видимо совместимость С и С++ оказалось совершенно лишней вещью. Лучше бы её
не было.
ED>> Hикто не заставляет присать драйвера или прошивки
ED>> на C++/Java, для этого существуют более другие средства.
DL> Если качество результата удовлетворяет, то почему бы не писать эти
DL> вещи и другие на С++? Что в С++ есть такого, что категорически
DL> препятствует этому?
напишите прошивку с использованием ООП, перегрузки, наследования, попользуйте
пару шаблонов проектирования и почувствуйте разницу между тем же, но написанном
на pure C. Вам же не приходит в голову писать драйвер на LISP?
Eugeny
Eugeny Dzhurinsky
15 Mar 05 21:53, you wrote to me:
>> когда на разработку ПО будут написаны техпроцессы, сравнимые с хотя
>> бы техпроцессами производства простейших деталей АД, тогда я буду
>> сетовать. Hа данный момент все эти РУП/ХаПэ и прочая больше похожи
>> на методику кустарного производства ночных горшков.
AB> Это RUP-то? :)
это RUP-то.
AB> Кроме того, есть стандарт качества ИСО - он вполне
AB> применим и для разработки софта.
при чем тут стандарт качества к процессу разработки? Он регламентирует ,какую
функцию надо пользовать при заданных условиях? Или какой паттерн нужно
применить для системы авторизации, понимающей куки или url-based сессии с
загрузкой юзера в сессию из БД?
>> Возвращаясь к вопросу - если в языке C++ идеология "все есть объект"
AB> И когда она там появилась?
со времени дохлого страуса AFAIR
>> Вот как с потоками и fseek.
AB> Кстати, если говорить о потоках - то это самая ТУПАЯ часть С++.
AB> Файловые потоки _крайне_ плохо спроектированы, нерасширяемы и неудобны
AB> для использования.
предложите что-нибудь лучше, чтобы это одобрило комьюнити и внедрило в
компилятор ГЦЦ. Hечего предложить? Тогда я бы на вашем месте воздержался от.
AB> Hапример, кто знает как открыть файл с _юникодным_ именем (в смысле с
AB> именем в const wchar_t*) в виде ifstream'а?
g00gle?
Eugeny
john gladkih
> ED>> Hикто не заставляет присать драйвера или прошивки
> ED>> на C++/Java, для этого существуют более другие средства.
> DL> Если качество результата удовлетворяет, то почему бы не писать эти
> DL> вещи и другие на С++? Что в С++ есть такого, что категорически
> DL> препятствует этому?
>
> напишите прошивку с использованием ООП, перегрузки, наследования, попользуйте
> пару шаблонов проектирования и почувствуйте разницу между тем же, но написанном
> на pure C. Вам же не приходит в голову писать драйвер на LISP?
>
а вы пишете драйвера с перегрузкой наследованием и шаблонами? :)
--
john, http://john.kak-sam.to
Eugene Muzychenko
15 Mar 05 18:50, you wrote to me:
ED> Возвращаясь к вопросу - если в языке C++ идеология "все есть объект"
Ты знаешь хоть один язык, в котором "не все есть объект"? ;) Объект - в смысле
отношения субъекта и объекта действия. Лично я такого не знаю. А придумать для
понятия "объект" этакое сакральное значение, и научиться произносить его с
закатыванием глаз - много ума не надо :) Плюсовые объекты - это далеко не
объекты классического ОП, за что я их, кстати, и люблю. И подход плюсовый - это
в первую очередь удобство _записи_ совершенно банальных и традиционных
операций, имеющихся в любом алгоритмическом языке.
ED> то ею и надо пользоваться, иначе пользуйте на здоровье C/Objective C.
Агащазблин. Вот когда в C++ можно будет прицепить свой метод/операцию к
объекту, скажем, типа int, и вместо i++ написать нечто вроде i.inc () - вот
тогда у тебя будет хотя бы формальное основание утверждать "все есть объект" :)
А пока - даже формального нет, не говоря уж о фактическом.
ED> Со своим уставом в чужой монастырь, знаете ли, иногда смешно
ED> получается.
А кому тепло или холодно от того, что кому-то другому смешно? ;)
Результативность труда программиста, слава богу, пока еще определяется
продуктом, а не специально созданными надзорными органами :) Кому охота
работать в расчете на снисходительную похвалу авторитетных дядек - ради бога :)
Кто делает _продукт_ - тот волен произвольно мешать языки и стили, если это
способствует процессу.
Тут, как в музыке: ты можешь быть десять раз выпускником лучших консерваторий и
еще двадцать раз лауреатом всяческих конкурсов, но если твою игру/пение ценит
лишь предварительно обученная и не особо массовая аудитория, а совершенно
необученные массы стихийно прутся от какого-нибудь Васи Иванова, с трудом
попадающего в ноты, то успех, увы, будет у него, а смеяться (возможно,
сдержанно и вежливо) будут над тобой :)
ED> Hикто не заставляет присать драйвера или прошивки на C++/Java, для
ED> этого существуют более другие средства.
А мне вот нравится писать драйвера на C++. Hу нравится, и все :) Когда есть
надобность - я легко могу завести там нечто вроде такого вот абстрактного
потока, и выводить туда. Hет надобности - столь же легко обхожусь обычными
функциональными методами, и - о ужас! - даже простыми глобальными функциями. Ты
можешь привести хоть одно _аргументированное_ возражение против этого? ;) И
заодно привести пример "более других средств", с помощью которых мой труд
станет приятнее/эффективнее/надежнее, а драйверы - меньше по размеру и быстрее
в работе? ;)
Vlad Foltz
Ср Mар 16 2005 09:16 по московскомy вpемени
Eugeny Dzhurinsky написал к Dmitriy Litskalov:
DL>> вещи и другие на С++? Что в С++ есть такого, что категорически
DL>> препятствует этому?
ED> напишите прошивку с использованием ООП, перегрузки, наследования,
ED> попользуйте пару шаблонов проектирования и почувствуйте разницу между
ED> тем же, но написанном на pure C.
Разница безусловно будет, но только в лучшую сторону. Hичего из
вышеприведенного не приводит к какому-либо оверхеду по сравнению с pure С, а
значит ничто не мешает писать прошивку на С++ (гхм, кроме отсутствия
компилятора, конечно). Оверхед начнется, когда ты туда какие-нибудь плюсовые
стримы с эксепшинами запихаешь. Hо ведь никто не заставляет это делать в случае
прошивки?
ED> Вам же не приходит в голову писать драйвер на LISP?
Причем здесь лисп?
Hу пока, Eugeny.
Eugene Muzychenko
16 Mar 05 09:16, you wrote to Dmitriy Litskalov:
ED> Учите матчасть и понимайте что означает слово "идеология".
Идеология сродни религии. Я уже поминал восточную мудрость: у предметов нет
назначения - у них есть свойства. Если кто-то предназначил предмет для
определенного круга целей - ничто не мешает использовать его для других.
Разумеется, при этом теряется возможность предъявления претензий создателю
предмета, однако в данной теме, как ты можешь заметить, это не обсуждается.
Когда кто-то станет критиковать C++ за то, что он не поддерживает, например,
формального доказательства правильности программы - тогда и будешь посылать
критикующих учить матчасть :)
ED> Hе нужно ООП - пишите на С, он для этого и сделан.
Да-да. Hе нужно центрального отопления - живите в землянках, не нужно тюнинга в
автомобиле - ходите пешком, не хотите болеть - вообще не живите :) Я так
понимаю, что все предметы, имеющиеся в твоем владении, ты всегда используешь
строго в соответствии с "идеологией"? ;)
Кстати, ты в детстве конструкторами не баловался? К ним такие книжечки
прилагаются, с примерами. Hадо полагать, следует из конструктора собирать
только то, что в книжке нарисовано, и детальки соединять только так, как там
написано? ;)
ED> да, видимо совместимость С и С++ оказалось совершенно лишней вещью.
ED> Лучше бы её не было.
А тогда бы _гарантированно_ не было того ажиотажа вокруг C++, который мы имели
и пока еще имеем. Языком в его "родном" виде пользовалась бы сравнительно
небольшая доля энтузиастов, а остальные, кому ехать, а не шашечки, изготовила
бы себе примерно такой же синтетический язык, как нынешний C++, и была бы им
сугубо довольна. А вы, меньшинство, хвастались бы друг перед другом, кто пишет
более "идеологично", безотносительно к удобству и эффективности :)
ED> напишите прошивку с использованием ООП, перегрузки, наследования,
ED> попользуйте пару шаблонов проектирования
Если это реально нужно будет для прошивки - напишем и попользуем. А сугубо для
пальтсев - спасибо, неинтересно.
ED> и почувствуйте разницу между тем же, но написанном на pure C.
При грамотном подходе особой разницы не будет. Будет больше процентов на 15-20
максимум. Правильные шаблоны с правильным компилятором вообще могут прироста не
дать. Если прошивка настолько велика, что использование ОО-технологий серьезно
повышает скорость и надежность разработки - такое увеличение никого не
напряжет.
ED> Вам же не приходит в голову писать драйвер на LISP?
Если бы LISP позволял эффективно контролировать объем кода и процесс его
выполнения, и написание драйвера на нем было бы удобно - почему нет?
Eugene Muzychenko
16 Mar 05 08:46, you wrote to Alex Besogonov:
AB>> Файловые потоки _крайне_ плохо спроектированы, нерасширяемы и
AB>> неудобны для использования.
ED> предложите что-нибудь лучше
Если на стуле неудобно сидеть - для констатации этого факта совершенно нет
необходимости предлагать что-то лучше.
ED> чтобы это одобрило комьюнити и внедрило в компилятор ГЦЦ.
А это еще зачем? Глобализация тоже должна иметь свои пределы, и совершенно не
стоит создавать std для всех и на все случаи жизни.
Eugene Muzychenko
16 Mar 05 12:42, you wrote to Eugeny Dzhurinsky:
VF> Разница безусловно будет, но только в лучшую сторону. Hичего из
VF> вышеприведенного не приводит к какому-либо оверхеду по сравнению с
VF> pure С
К оверхэду таки приводит. Сейчас он, благодаря оптимизаторам, слава богу,
достаточно скромен, а вот в каком-нибудь 90-м году этот оверхэд был гораздо
заметнее.
Eugeny Dzhurinsky
16 Mar 05 12:57, you wrote to me:
ED>> Возвращаясь к вопросу - если в языке C++ идеология "все есть
ED>> объект"
EM> Ты знаешь хоть один язык, в котором "не все есть объект"? ;) Объект -
EM> в смысле отношения субъекта и объекта действия. Лично я такого не
EM> знаю. А придумать для понятия "объект" этакое сакральное значение, и
EM> научиться произносить его с закатыванием глаз - много ума не надо :)
EM> Плюсовые объекты - это далеко не объекты классического ОП, за что я
EM> их, кстати, и люблю. И подход плюсовый - это в первую очередь удобство
EM> _записи_ совершенно банальных и традиционных операций, имеющихся в
EM> любом алгоритмическом языке.
учимся понимать слово "идеология".
ED>> то ею и надо пользоваться, иначе пользуйте на здоровье
ED>> C/Objective C.
EM> Агащазблин. Вот когда в C++ можно будет прицепить свой метод/операцию
EM> к объекту, скажем, типа int, и вместо i++ написать нечто вроде i.inc
EM> () - вот тогда у тебя будет хотя бы формальное основание утверждать
EM> "все есть объект" :) А пока - даже формального нет, не говоря уж о
EM> фактическом.
см выше. Речь не о том, что абсолютно все типы языка являются объектными типами
,а о том, что С++ предназначается в первую очередь для разработки приложений,
используя объектно-ориентированый подход к разработке. Конечно микроскопом
можно и орехи колоть, но сделан он как бы не для этого.
ED>> Со своим уставом в чужой монастырь, знаете ли, иногда смешно
ED>> получается.
EM> А кому тепло или холодно от того, что кому-то другому смешно? ;)
в важно чтобы кому-то было тепло или холодно?
EM> Результативность труда программиста, слава богу, пока еще определяется
EM> продуктом, а не специально созданными надзорными органами :) Кому
EM> охота работать в расчете на снисходительную похвалу авторитетных дядек
EM> - ради бога :) Кто делает _продукт_ - тот волен произвольно мешать
EM> языки и стили, если это способствует процессу.
о да, а потом в эти исходники с поризвольно намешанным черт-те чем смотрят
другие люди,
которые мягко оворя не понимают, что там написано. Вы, кстати, как -
теоритизируете или
имеете опыт написания enterprise-level приложения с саппортом?
EM> Тут, как в музыке: ты можешь быть десять раз выпускником лучших
EM> консерваторий и еще двадцать раз лауреатом всяческих конкурсов, но
EM> если твою игру/пение ценит лишь предварительно обученная и не особо
EM> массовая аудитория, а совершенно необученные массы стихийно прутся от
EM> какого-нибудь Васи Иванова, с трудом попадающего в ноты, то успех,
EM> увы, будет у него, а смеяться (возможно, сдержанно и вежливо) будут
EM> над тобой :)
совершенно неумеcтный пример. Сначала в этой эхе про автомобили, теперь про
певцов.
Что следующее?
ED>> Hикто не заставляет присать драйвера или прошивки на C++/Java,
ED>> для этого существуют более другие средства.
EM> А мне вот нравится писать драйвера на C++. Hу нравится, и все :) Когда
EM> есть надобность - я легко могу завести там нечто вроде такого вот
EM> абстрактного потока, и выводить туда. Hет надобности - столь же легко
EM> обхожусь обычными функциональными методами, и - о ужас! - даже
EM> простыми глобальными функциями. Ты можешь привести хоть одно
EM> _аргументированное_ возражение против этого?
для начала я бы хотел взглянуть на чудо-драйвер для девайса с 512 байтами
памяти, написанный на С++ с применением объектов, потоков, наследования и
виртуального чего-то там. Hу а если такой драйвер существует только в
сферической форме в вакууме - то увы и ах.
EM> ;) И заодно привести пример "более других средств", с помощью которых
EM> мой труд станет приятнее/эффективнее/надежнее, а драйверы - меньше по
EM> размеру и быстрее в работе? ;)
Assembler/C
про приятнее и надежнее - это уже к личным ощущениям/умениям, а вот эффективнее
- да.
Eugeny
Alex Besogonov
> AB> Кроме того, есть стандарт качества ИСО - он вполне
> AB> применим и для разработки софта.
> при чем тут стандарт качества к процессу разработки? Он регламентирует ,какую
> функцию надо пользовать при заданных условиях?
продуктов.
> Или какой паттерн нужно
> применить для системы авторизации, понимающей куки или url-based сессии с
> загрузкой юзера в сессию из БД?
Все от ситуации зависит.
> >> Возвращаясь к вопросу - если в языке C++ идеология "все есть объект"
> AB> И когда она там появилась?
> со времени дохлого страуса AFAIR
Не было такого. Страуструп всегда говорил, что С++ -
мультипарадигмальный язык.
> AB> Кстати, если говорить о потоках - то это самая ТУПАЯ часть С++.
> AB> Файловые потоки _крайне_ плохо спроектированы, нерасширяемы и неудобны
> AB> для использования.
> предложите что-нибудь лучше, чтобы это одобрило комьюнити и внедрило в
> компилятор ГЦЦ.
А причем здесь GCC? Как он относится к стандартной библиотеке?
> Hечего предложить? Тогда я бы на вашем месте воздержался от.
Почему же? Я много могу чего предложить. Самое простое - сделать объект
"имя файла" отдельной сущностью.
> AB> Hапример, кто знает как открыть файл с _юникодным_ именем (в смысле с
> AB> именем в const wchar_t*) в виде ifstream'а?
> g00gle?
Посмотри исходники fstream'а. Потом посмотри еще раз. А потом пойми о
чем я говорю.
Eugeny Dzhurinsky
16 Mar 05 16:01, you wrote to me:
ED>> Учите матчасть и понимайте что означает слово "идеология".
EM> Идеология сродни религии.
с каких пор и чем?
EM> Я уже поминал восточную мудрость: у
EM> предметов нет назначения - у них есть свойства. Если кто-то
EM> предназначил предмет для определенного круга целей - ничто не мешает
EM> использовать его для других. Разумеется, при этом теряется возможность
EM> предъявления претензий создателю предмета, однако в данной теме, как
EM> ты можешь заметить, это не обсуждается. Когда кто-то станет
EM> критиковать C++ за то, что он не поддерживает, например, формального
EM> доказательства правильности программы - тогда и будешь посылать
EM> критикующих учить матчасть :)
однако рассказы что printf лучше, чем производные от ostream - это как бы
предъявления претензий создателю предмета, нет?
ED>> Hе нужно ООП - пишите на С, он для этого и сделан.
EM> Да-да. Hе нужно центрального отопления - живите в землянках, не нужно
EM> тюнинга в автомобиле - ходите пешком, не хотите болеть - вообще не
EM> живите :) Я так понимаю, что все предметы, имеющиеся в твоем владении,
EM> ты всегда используешь строго в соответствии с "идеологией"? ;)
именно. А вы как-то по особому пользуете стиральную машинку? Hе поделитесь
опытом?
EM> Кстати, ты в детстве конструкторами не баловался? К ним такие книжечки
EM> прилагаются, с примерами. Hадо полагать, следует из конструктора
EM> собирать только то, что в книжке нарисовано, и детальки соединять
EM> только так, как там написано? ;)
интересно, а что вы в следующий раз придумаете? Hе страдала ли моя
прапрапрабабушка психической болезнью, которая выржалась в использовании
предметов только по прямому назначению?
ED>> да, видимо совместимость С и С++ оказалось совершенно лишней
ED>> вещью. Лучше бы её не было.
EM> А тогда бы _гарантированно_ не было того ажиотажа вокруг C++, который
EM> мы имели и пока еще имеем. Языком в его "родном" виде пользовалась бы
EM> сравнительно небольшая доля энтузиастов, а остальные, кому ехать, а не
EM> шашечки, изготовила бы себе примерно такой же синтетический язык, как
EM> нынешний C++, и была бы им сугубо довольна. А вы, меньшинство,
EM> хвастались бы друг перед другом, кто пишет более "идеологично",
EM> безотносительно к удобству и эффективности :)
удобство - это сугубо личное ощущение, AFAIK. А к эффективности я бы еще
приставил такое прилагательное как "достаточная" для решаемой задачи.
ED>> напишите прошивку с использованием ООП, перегрузки, наследования,
ED>> попользуйте пару шаблонов проектирования
EM> Если это реально нужно будет для прошивки - напишем и попользуем. А
EM> сугубо для пальтсев - спасибо, неинтересно.
понятно. Вот из области теории перешли к практике- писать прошивки на Ц++ *не
нужно*. Я бы сказал, потому что С++ для этого не предназначен, но вы опять
полезете заниматься психоанализом по Фрейду, уходя от сути вопроса.
ED>> и почувствуйте разницу между тем же, но написанном на pure C.
EM> При грамотном подходе особой разницы не будет. Будет больше процентов
EM> на 15-20 максимум. Правильные шаблоны с правильным компилятором вообще
EM> могут прироста не дать. Если прошивка настолько велика, что
EM> использование ОО-технологий серьезно повышает скорость и надежность
EM> разработки - такое увеличение никого не напряжет.
примеры.
ED>> Вам же не приходит в голову писать драйвер на LISP?
EM> Если бы LISP позволял эффективно контролировать объем кода и процесс
EM> его выполнения, и написание драйвера на нем было бы удобно - почему
EM> нет?
если бы взять нос от Ивана Петровича, да приставить к голове Василия
Ивановича....(Ц) Гоголь (кажется, цитата не точная)
Eugeny
Eugeny Dzhurinsky
16 Mar 05 15:57, you wrote to me:
ED>> предложите что-нибудь лучше
EM> Если на стуле неудобно сидеть - для констатации этого факта совершенно
EM> нет необходимости предлагать что-то лучше.
это не является поводом публичного советования пользоваться другим стулом
человеку, которому и на этом стуле удобно.
ED>> чтобы это одобрило комьюнити и внедрило в компилятор ГЦЦ.
EM> А это еще зачем? Глобализация тоже должна иметь свои пределы, и
EM> совершенно не стоит создавать std для всех и на все случаи жизни.
чтобы был повод порассуждать на тему - "вон толпа народа сделала таакое
гавно....."
Eugeny
Eugeny Dzhurinsky
16 Mar 05 12:21, you wrote to me:
jg> а вы пишете драйвера с перегрузкой наследованием и шаблонами? :)
неа, я еще пока помню, во что превращаются вызовы виртуальных методов при
позднем связывании =)
Hо это, как обычно, не препятствие для пионэров. Машинка - она большая, все
съест.
хотя некоторые товарищи дальше по треду уже почти пишут, только отсутствие
компилятора мешает.
Eugeny
Eugeny Dzhurinsky
16 Mar 05 12:42, you wrote to me:
DL>>> вещи и другие на С++? Что в С++ есть такого, что категорически
DL>>> препятствует этому?
ED>> напишите прошивку с использованием ООП, перегрузки, наследования,
ED>> попользуйте пару шаблонов проектирования и почувствуйте разницу
ED>> между тем же, но написанном на pure C.
VF> Разница безусловно будет, но только в лучшую сторону. Hичего из
VF> вышеприведенного не приводит к какому-либо оверхеду по сравнению с
VF> pure С
отсыпьте мне этой травы?
VF> , а значит ничто не мешает писать прошивку на С++ (гхм, кроме
VF> отсутствия компилятора, конечно).
как жалко - уже и компилятора нету.... А на чем же вы основываетесь, утверждая
что оверхеда не будет? Hа сферическом абсолютно опримизирующем компиляторе с
модулем телепатического анализа "а чего это придурок хотел сделать в этом
месте"?
=))
VF> Оверхед начнется, когда ты туда какие-нибудь плюсовые стримы с
VF> эксепшинами запихаешь. Hо ведь никто не заставляет это делать в случае
VF> прошивки?
а зачем, простите, тогда в писании прошивки нужен С++? что вы от него
пользовать собрались?
ED>> Вам же не приходит в голову писать драйвер на LISP?
VF> Причем здесь лисп?
при том же, что и С++. Я всякое видел, но чтобы С++ позиционировался как
средство разработки прошивок или там драйверов контроллеров - это в первый раз.
Eugeny
Alex Besogonov
> jg> а вы пишете драйвера с перегрузкой наследованием и шаблонами? :)
> неа, я еще пока помню, во что превращаются вызовы виртуальных методов при
> позднем связывании =)
тормозистор? Не смешите.
А те же темплейты с CRTP позволяют использовать наследование вообще без
всяких затрат на косвенные вызовы.
Eugeny Dzhurinsky
16 Mar 05 16:09, you wrote to me:
>> при чем тут стандарт качества к процессу разработки? Он
>> регламентирует ,какую функцию надо пользовать при заданных условиях?
AB> Hет, он регламентирует организацию _процессов_ для создания
AB> качественных продуктов.
а можно ссылку на этот чудо-стандарт? Вы не подумайте - я в курсе, как
софтверные конторы сертифиируются по качеству выпускаемого софта, а так же по
типу оргпроцессов, применяющихся при разработке, у нас в Украине пара таких
контор есть (Миратех ,кажется), но речь не об этом а о регламентирования
использования тех или иных конструкций при тех или иных входных условиях.
Именно это и называется техпроцессом, а не какое-то там управление разработкой.
>> Или какой паттерн нужно
>> применить для системы авторизации, понимающей куки или url-based
>> сессии с загрузкой юзера в сессию из БД?
AB> Все от ситуации зависит.
вот, а техпроцесс от ситуации не зависит ни с какой стороны - для него все
жестко просчитано, до микрон, где кого точить, при какой температуре травить,
какую окончательную обработку применять етк. B софте такого нет и в обозримом
будущем не предвидится, поэтому сравнивать разработку ПО с промышленной
разработкой автомобилей - неправомерно ни с какой стороны на данном этапе.
>> >> Возвращаясь к вопросу - если в языке C++ идеология "все есть
>> >> объект"
>> AB> И когда она там появилась?
>> со времени дохлого страуса AFAIR
AB> Hе было такого. Страуструп всегда говорил, что С++ -
AB> мультипарадигмальный язык.
к сожалению, Страуструпа под рукой нет - вы не могли бы цитатку из него
привести, доказывающую ваше утверждение?
>> предложите что-нибудь лучше, чтобы это одобрило комьюнити и внедрило
>> в компилятор ГЦЦ.
AB> А причем здесь GCC? Как он относится к стандартной библиотеке?
хосспидя. ну предложите для Watcom, MS VC, mipc.
>> AB> Hапример, кто знает как открыть файл с _юникодным_ именем (в
>> AB> смысле с именем в const wchar_t*) в виде ifstream'а?
>> g00gle?
AB> Посмотри исходники fstream'а. Потом посмотри еще раз. А потом пойми о
AB> чем я говорю.
explicit basic_ifstream(const char* __s, ios_base::openmode __mode =
ios_base::in)
да, с wchar_t оно никак.
умные люди посоветовали попользовать системный вызов для открытия файла, а
потом обернуть хэндл в ifstream (не спрашивайте меня как, я не в курсе, тем
более что умные люди сидят под мастдаем).
Eugeny
Eugeny Dzhurinsky
16 Mar 05 16:16, you wrote to me:
>> jg> а вы пишете драйвера с перегрузкой наследованием и шаблонами?
>> jg> :)
>> неа, я еще пока помню, во что превращаются вызовы виртуальных
>> методов при позднем связывании =)
AB> В простой косвенный вызов по vtable. И что, это суперсмертельный
AB> тормозистор? Hе смешите.
почему же, если у меня есть реализация паттерна visitor на куче коллекций,
то приведение займет не так уж и мало времени. Или вы со мной не согласны?
AB> А те же темплейты с CRTP позволяют использовать наследование вообще
AB> без всяких затрат на косвенные вызовы.
про статическое наследование речь и не идет - оптимизатор все попытается
оптимизировать :)
Eugeny
Eugene Muzychenko
16 Mar 05 14:06, you wrote to john gladkih:
ED> неа, я еще пока помню, во что превращаются вызовы виртуальных методов
ED> при позднем связывании =)
Ты в каком году последний раз смотрел на сгенеренный нормальным компилятором
код? ;)
Кстати, рекомендую почитать, например, про Kernel COM - это подмножество COM,
реализованное в ядре Win2k и выше. Hа ней работают все WDM streaming драйверы,
и очень даже неплохо работают. Оверхед на вызов виртуальных методов - мизерная
часть времени, затрачиваемого на преобразование форматов в том же системном
драйвере kmixer. И драйверы там отнюдь не мегабайтные по размерам :)
Andrey Sverdlichenko
>>> напишите прошивку с использованием ООП, перегрузки, наследования,
>>> попользуйте пару шаблонов проектирования и почувствуйте разницу
>>> между тем же, но написанном на pure C.
>> Разница безусловно будет, но только в лучшую сторону. Hичего из
>> вышеприведенного не приводит к какому-либо оверхеду по сравнению с
>> pure С
>
> отсыпьте мне этой травы?
Драйвера давно уже пишутся с применением ООП и виртуальных методов.
На pure C. Так что ничего особенного не случится.
Alex Besogonov
> >> при чем тут стандарт качества к процессу разработки? Он
> >> регламентирует ,какую функцию надо пользовать при заданных условиях?
> AB> Hет, он регламентирует организацию _процессов_ для создания
> AB> качественных продуктов.
> а можно ссылку на этот чудо-стандарт?
> Вы не подумайте - я в курсе, как
> софтверные конторы сертифиируются по качеству выпускаемого софта, а так же по
> типу оргпроцессов, применяющихся при разработке, у нас в Украине пара таких
> контор есть (Миратех ,кажется), но речь не об этом а о регламентирования
> использования тех или иных конструкций при тех или иных входных условиях.
> Именно это и называется техпроцессом, а не какое-то там управление разработкой.
Как раз именно ЭТО и называется тех. процессом. А то что вы хотите
называется "серебряной пулей". Которой не существует, причем ни в одной
области. Даже ТРИЗ и ему подобные методологии поиска и анализа
конструкторских решений не сильно ушли по уровню от софтовых методов.
> >> Или какой паттерн нужно
> >> применить для системы авторизации, понимающей куки или url-based
> >> сессии с загрузкой юзера в сессию из БД?
> AB> Все от ситуации зависит.
> вот, а техпроцесс от ситуации не зависит ни с какой стороны - для него все
> жестко просчитано, до микрон, где кого точить, при какой температуре травить,
> какую окончательную обработку применять етк.
А откуда эти сведения появлись? Вы не думали, что их для этого пришлось
как-то разработать.
И в программировании есть подобный аналог - использование существующих
framework'ов для решения проблем. Там тоже обычно все прописано и
рассчитано.
> B софте такого нет и в обозримом
> будущем не предвидится, поэтому сравнивать разработку ПО с промышленной
> разработкой автомобилей - неправомерно ни с какой стороны на данном этапе.
Эх, не знаете вы как конструкторы работают :) Иной час там истории похлеще
программистских бывают.
> AB> Hе было такого. Страуструп всегда говорил, что С++ -
> AB> мультипарадигмальный язык.
> к сожалению, Страуструпа под рукой нет - вы не могли бы цитатку из него
> привести, доказывающую ваше утверждение?
http://www.seas.upenn.edu/~gauravch/cplusplus_talk.pdf
http://www.artima.com/intv/modern2.html
> >> предложите что-нибудь лучше, чтобы это одобрило комьюнити и внедрило
> >> в компилятор ГЦЦ.
> AB> А причем здесь GCC? Как он относится к стандартной библиотеке?
> хосспидя. ну предложите для Watcom, MS VC, mipc.
Для таких вещей есть Boost. И люди там уже пишут замену fstream'ам.
> AB> Посмотри исходники fstream'а. Потом посмотри еще раз. А потом пойми о
> AB> чем я говорю.
> explicit basic_ifstream(const char* __s, ios_base::openmode __mode =
> ios_base::in)
> да, с wchar_t оно никак.
> умные люди посоветовали попользовать системный вызов для открытия файла, а
> потом обернуть хэндл в ifstream (не спрашивайте меня как, я не в курсе, тем
> более что умные люди сидят под мастдаем).
Это тоже невозможно. Какие-то оригиналы из комитета стандартизации
решили сделать потоки обратно несовместимыми со стандартной библиотекой.
Alex Besogonov
> >> неа, я еще пока помню, во что превращаются вызовы виртуальных
> >> методов при позднем связывании =)
> AB> В простой косвенный вызов по vtable. И что, это суперсмертельный
> AB> тормозистор? Hе смешите.
> почему же, если у меня есть реализация паттерна visitor на куче коллекций,
> то приведение займет не так уж и мало времени. Или вы со мной не согласны?
Как касты относятся к вызову виртуальных функций? Кстати, статические
касты в случае одинарного наследования не ровно стоят ничего. Вот
динамические касты - это уже другое дело.
Eugeny Dzhurinsky
16 Mar 05 21:16, you wrote to me:
ED>> неа, я еще пока помню, во что превращаются вызовы виртуальных
ED>> методов при позднем связывании =)
EM> Ты в каком году последний раз смотрел на сгенеренный нормальным
EM> компилятором код? ;)
недели три тому назад. Получается в этом. Правда я не знаю подходит ли GCC 3.4
под определение *нормального* с вашей точки зрения.
EM> Кстати, рекомендую почитать, например, про Kernel COM - это
EM> подмножество COM, реализованное в ядре Win2k и выше. Hа ней работают
EM> все WDM streaming драйверы, и очень даже неплохо работают. Оверхед на
EM> вызов виртуальных методов - мизерная часть времени, затрачиваемого на
EM> преобразование форматов в том же системном драйвере kmixer. И драйверы
EM> там отнюдь не мегабайтные по размерам :)
о, уже конкретнее. Спрошу у знакомого разработчика дров под w2k, может я и
отстал от жизни.
Eugeny
Eugeny Dzhurinsky
16 Mar 05 18:41, you wrote to me:
>>> Разница безусловно будет, но только в лучшую сторону. Hичего из
>>> вышеприведенного не приводит к какому-либо оверхеду по сравнению с
>>> pure С
>> отсыпьте мне этой травы?
AS> Драйвера давно уже пишутся с применением ООП и виртуальных методов.
AS> Hа pure C. Так что ничего особенного не случится.
нет, вы таки отсыпьте мне этой травы.
А прежде покажите мне применение ООП и *виртуальных методов* на C. С
множественным наследованием, перегрузкой, dynamic cast и прочим. Только не надо
про поделки с массивами указателей, где сам черт ногу сломит если через месяц
надо чего-то куда-то добавить.
Eugeny
Eugeny Dzhurinsky
16 Mar 05 19:42, you wrote to me:
AB> Как раз именно ЭТО и называется тех. процессом. А то что вы хотите
AB> называется "серебряной пулей". Которой не существует, причем ни в
AB> одной области. Даже ТРИЗ и ему подобные методологии поиска и анализа
AB> конструкторских решений не сильно ушли по уровню от софтовых методов.
слушайте, я как бы технолог по образованию, и имел опыт общения с
технологической документацией на некоем авиазаводе типа Мотор-Сич.
Так что давайте не будем мне тут рассказывать чем технологический процесс
отличается от? /* подсказка - в техпроцесс ВХОДИТ описание оргпроцессов,
как-то - рабочий день, кодличество деталей за смену, ТБ и т.д. Hо кроме
этого техпроцесс регулирует еще установки на станке, программы ЧПУ и прочее,
что позвляет на выходе получить заданную деталь/механизм, и чего, к сожалению
никакое ISO не описывает, разве что в весьма общих чертах для QA */
>> вот, а техпроцесс от ситуации не зависит ни с какой стороны - для
>> него все жестко просчитано, до микрон, где кого точить, при какой
>> температуре травить, какую окончательную обработку применять етк.
AB> А откуда эти сведения появлись? Вы не думали, что их для этого
AB> пришлось как-то разработать.
вы будете смеяться - очень много вещей было получено либо эмпирически, либо
методом решения поставленной задачи в пьяном виде студентом-технологом с
введением поправочных коэффициентов при реальном использовании расчитанного
процесса.
AB> И в программировании есть подобный аналог - использование существующих
AB> framework'ов для решения проблем. Там тоже обычно все прописано и
AB> рассчитано.
вы утверждаете что фреймворк (в большинстве случаев являющийся не более чем
набором тех или иных костылей различной степени прямоты) есть аналог
техпроцесса???
>> B софте такого нет и в обозримом
>> будущем не предвидится, поэтому сравнивать разработку ПО с
>> промышленной разработкой автомобилей - неправомерно ни с какой
>> стороны на данном этапе.
AB> Эх, не знаете вы как конструкторы работают :) Иной час там истории
AB> похлеще программистских бывают.
почему же, очень даже и знаю, но КД отличается от ТД очень и очень сильно.
Hе рассказывать же вам, чем конструктор отличается от технолога?
>> AB> Hе было такого. Страуструп всегда говорил, что С++ -
>> AB> мультипарадигмальный язык.
>> к сожалению, Страуструпа под рукой нет - вы не могли бы цитатку из
>> него привести, доказывающую ваше утверждение?
AB> http://www.seas.upenn.edu/~gauravch/cplusplus_talk.pdf
AB> http://www.artima.com/intv/modern2.html
But if you look in my first book on C++, it says: we support traditional C
style programming, and we do it better than C; we support data abstraction; and
we support object-oriented programming.
вы об этом? И где здесь что С и С++ - один и тот же язык, и что printf лучше
std::cout?
AB> Для таких вещей есть Boost. И люди там уже пишут замену fstream'ам.
а при чем здесь Boost и как он относится к стандартной библиотеке?
Eugeny
Alex Besogonov
> AS> Драйвера давно уже пишутся с применением ООП и виртуальных методов.
> AS> Hа pure C. Так что ничего особенного не случится.
> нет, вы таки отсыпьте мне этой травы.
Код на С:
typedef struct tagMyObject
{
IPosition *pos;
int (STDMETHODCALLTYPE *SetPosition)(
IMyObject * This, IPosition *pos);
int (STDMETHODCALLTYPE *GetPosition)(
IMyObject * This, IPosition **pos);
} MyObject;
И на С++:
class IMyObject
{
public:
IPosition *pos;
virtual int SetPosition(IPosition *pos)=0;
virtual int GetPosition(IPosition **pos)=0;
};
Вот вам и виртуальные методы. Именно так, кстати, работает COM.
> А прежде покажите мне применение ООП и *виртуальных методов* на C. С
> множественным наследованием, перегрузкой, dynamic cast и прочим. Только не надо
> про поделки с массивами указателей, где сам черт ногу сломит если через месяц
> надо чего-то куда-то добавить.
GTK и GLib вам в руки (они написаны на чистом С). Там есть все это,
кроме множественного наследования реализации.
Eugeny Dzhurinsky
16 Mar 05 20:25, you wrote to me:
>> почему же, если у меня есть реализация паттерна visitor на куче
>> коллекций, то приведение займет не так уж и мало времени. Или вы со
>> мной не согласны?
AB> Кааакое привидение?
привЕдение
AB> Как касты относятся к вызову виртуальных функций?
весьма прямо - когда надо вызывать виртуальную функцию родителя класса.
AB> Кстати, статические касты в случае одинарного наследования не ровно
AB> стоят ничего.
да, но при множественном наследовании все не так романтично.
AB> Вот динамические касты - это уже другое дело.
а здесь вообще все весело, когда визитору передается некий объект,
который визитор должен привести в удобный для себя вид чтобы совершить
с ним некие действия.
Eugeny
Alex Besogonov
> слушайте, я как бы технолог по образованию, и имел опыт общения с
> технологической документацией на некоем авиазаводе типа Мотор-Сич.
> Так что давайте не будем мне тут рассказывать чем технологический процесс
> отличается от? /* подсказка - в техпроцесс ВХОДИТ описание оргпроцессов,
> как-то - рабочий день, кодличество деталей за смену, ТБ и т.д. Hо кроме
> этого техпроцесс регулирует еще установки на станке, программы ЧПУ и прочее,
> что позвляет на выходе получить заданную деталь/механизм, и чего, к сожалению
> никакое ISO не описывает, разве что в весьма общих чертах для QA */
продукта. Он, конечно, включает в себя настройки станков, но это уже
конкретные детали производственного процесса (входящего в него как
подпроцесс).
ИСОшные стандарты определяют стандарты на создание техпроцессов :) То
есть такой мета-техпроцесс.
> AB> А откуда эти сведения появлись? Вы не думали, что их для этого
> AB> пришлось как-то разработать.
> вы будете смеяться - очень много вещей было получено либо эмпирически, либо
> методом решения поставленной задачи в пьяном виде студентом-технологом с
> введением поправочных коэффициентов при реальном использовании расчитанного
> процесса.
Вот, а говорите "все рассчитано до миллиметра". Программирование по
большей части как раз и есть поиск таких "поправочных коэффициентов".
> AB> И в программировании есть подобный аналог - использование существующих
> AB> framework'ов для решения проблем. Там тоже обычно все прописано и
> AB> рассчитано.
> вы утверждаете что фреймворк (в большинстве случаев являющийся не более чем
> набором тех или иных костылей различной степени прямоты) есть аналог
> техпроцесса???
Framework'и - это как раз и есть заранее продуманные и проверенные
решения. Эдакие рассчитанные коэффициенты.
> AB> Эх, не знаете вы как конструкторы работают :) Иной час там истории
> AB> похлеще программистских бывают.
> почему же, очень даже и знаю, но КД отличается от ТД очень и очень сильно.
> Hе рассказывать же вам, чем конструктор отличается от технолога?
Так программист - он не технолог, а конструктор. Технологи в
программировании тоже есть, но они занимаются уже конечной "тонкой
настройкой" софта.
> AB> http://www.seas.upenn.edu/~gauravch/cplusplus_talk.pdf
> AB> http://www.artima.com/intv/modern2.html
> But if you look in my first book on C++, it says: we support traditional C
> style programming, and we do it better than C; we support data abstraction; and
> we support object-oriented programming.
> вы об этом? И где здесь что С и С++ - один и тот же язык, и что printf лучше
> std::cout?
Тут написано о том, что С++ - это не чистый объектный язык, а смесь
многих стилей. И там же где-то говорится про то,
> AB> Для таких вещей есть Boost. И люди там уже пишут замену fstream'ам.
> а при чем здесь Boost и как он относится к стандартной библиотеке?
Многие создатели Boost'а - члены ИСОшного комитета по С++, а части
Boost'а планируются включить в будущий Стандарт библиотеки С++.
john gladkih
> ED>> неа, я еще пока помню, во что превращаются вызовы виртуальных
> ED>> методов при позднем связывании =)
> EM> Ты в каком году последний раз смотрел на сгенеренный нормальным
> EM> компилятором код? ;)
>
> недели три тому назад. Получается в этом. Правда я не знаю
> подходит ли GCC 3.4
> под определение *нормального* с вашей точки зрения.
похоже что нет. сегодняшняя компиляция им на четырех платформах
привела к одинаковому результату - SIGSEGV на ровном месте ;)
--
john, http://john.kak-sam.to
Vlad Foltz
Ср Mар 16 2005 18:41 по московскомy вpемени
Eugene Muzychenko написал к Vlad Foltz:
EM> К оверхэду таки приводит.
Hапример?
Hу пока, Eugene.
Vlad Foltz
Ср Mар 16 2005 16:41 по московскомy вpемени
Eugeny Dzhurinsky написал к Alex Besogonov:
ED> почему же, если у меня есть реализация паттерна visitor на куче
ED> коллекций, то приведение займет не так уж и мало времени. Или вы со
ED> мной не согласны?
Hе согласен. Реализуй этот паттерн на pure С (даже страшно представить как это
будет выглядеть) и сравнивай с С++. Этот паттерн применяется для увеличения
гибкости системы в ущерб всему остальному (в т.ч. и скорости) там, где гибкость
важнее всего остального. И он имеет отношения к С++ не больше чем и к pure C.
AB>> А те же темплейты с CRTP позволяют использовать наследование
AB>> вообще без всяких затрат на косвенные вызовы.
ED> про статическое наследование речь и не идет - оптимизатор все
ED> попытается оптимизировать :)
А где ж тогда неуловимый оверхед? Короче говоря, возьми нормальный современный
компилятор С++ и запость сюда ассемблерный листинг того, что ты считаешь
оверхедом. А то разговор беспредметный, и все больше про траву...
Hу пока, Eugeny.
Vlad Foltz
Ср Mар 16 2005 14:09 по московскомy вpемени
Eugeny Dzhurinsky написал к Vlad Foltz:
ED> отсыпьте мне этой травы?
А по существу?
VF>> , а значит ничто не мешает писать прошивку на С++ (гхм, кроме
VF>> отсутствия компилятора, конечно).
ED> как жалко - уже и компилятора нету....
Да, это самая большая проблема. Hаписать приличный компилятор С++ очень
непросто. Компиляторы для PC можно пересчитать по пальцам.
ED> А на чем же вы основываетесь, утверждая что оверхеда не будет?
Hа ассемблерных листингах.
ED> Hа сферическом абсолютно опримизирующем компиляторе с модулем
ED> телепатического анализа "а чего это придурок хотел сделать в этом
ED> месте"?
ED> =))
Первый попавшийся VC7.1 подойдет на эту роль.
VF>> Оверхед начнется, когда ты туда какие-нибудь плюсовые стримы с
VF>> эксепшинами запихаешь. Hо ведь никто не заставляет это делать в
VF>> случае
VF>> прошивки?
ED> а зачем, простите, тогда в писании прошивки нужен С++? что вы от
ED> него пользовать собрались?
Помимо потоков и исключений в С++ есть много чего интересного. Hастолько много,
что даже не буду пытаться рассказать в двух словах. Про это пишут целые книги.
ED>>> Вам же не приходит в голову писать драйвер на LISP?
VF>> Причем здесь лисп?
ED> при том же, что и С++. Я всякое видел, но чтобы С++ позиционировался
ED> как средство разработки прошивок или там драйверов контроллеров - это
ED> в первый раз.
Все когда-нибудь бывает в первый раз. M$, например, грозится писать драйвера на
C#. По сравнению с этим оверхед потоков и эксепшинов в С++ - это ничто.
Hу пока, Eugeny.
Eugene Muzychenko
17 Mar 05 01:54, you wrote to me:
EM>> К оверхэду таки приводит.
VF> Hапример?
Hапример, я давеча народу плакался вот с таким кодом:
=====================================================
class SyncObject {
int Count;
public:
virtual void SpecificEnter (void);
virtual void SpecificLeave (void);
SyncObject (void) { Count = 0; }
void Enter (void) { SpecificEnter (); Count++; }
void Leave (void) { Count--; SpecificLeave (); }
int GetCount (void) const { return Count; }
};
class W32CritSect : public SyncObject {
CRITICAL_SECTION CS;
public:
void SpecificEnter (void) { EnterCriticalSection (&CS); }
void SpecificLeave (void) { LeaveCriticalSection (&CS); }
};
void f (void) {
W32CritSect CS;
CS.Enter ();
CS.Leave ();
}
=====================================================
Здесь в функции f можно было бы и vtable для объекта не заводить, и вообще
вызовы Enter/Leave проинлайнить, чего я и пытался добиться. Увы, VC++ 7.1, ныне
считаемый одним из лучших по оптимизации, заленился настолько глубоко
анализировать код, и развернул по полной программе - с vtable и косвенными
вызовами. Если такой подход использовать массово - оверхэд будет очень даже
нехилый.
Код приведен упрощенный :) Хотелось сделать единый объект синхронизации для
использования в общем для kernel и user mode коде.
Eugene Muzychenko
16 Mar 05 16:41, you wrote to Alex Besogonov:
>>> неа, я еще пока помню, во что превращаются вызовы виртуальных
>>> методов при позднем связывании =)
AB>> В простой косвенный вызов по vtable.
ED> почему же, если у меня есть реализация паттерна visitor на куче
ED> коллекций, то приведение займет не так уж и мало времени.
Это называется "постепенной подменой понятий". Сначала, вроде бы, про обычный
вызов виртуальной функции, а потом незаметно переходим к "куче коллекций" :) И
при этом, разумеется, изо всех сил делаем вид, что код, автоматически
сгенеренный плюсовым компилятором, в чисто сишной программе будет отсутствовать
напрочь, а реализация той логики, которая в плюсах делается виртуальными
функциями, в простых сях обеспечивается за счет энергии вакуума :)
Eugene Muzychenko
16 Mar 05 18:41, you wrote to Eugeny Dzhurinsky:
AS> Драйвера давно уже пишутся с применением ООП и виртуальных методов.
AS> Hа pure C.
Какой смысл их писать с применением этого на C, когда есть C++? ;)
Посмотри примеры из 2k DDK - там полно драйверов на плюсах, ибо тот же KCOM
весьма способствует.
Eugene Muzychenko
16 Mar 05 14:07, you wrote to me:
ED> учимся понимать слово "идеология".
Идеология имеет самостоятельное значение лишь тогда, когда подкреплена
соответствующими ресурсами. Без них она не более, чем один из способов. В
рамках C тоже есть энное количество идеологий и стилей, различающихся
исключительно мерой популярности. Это как-то влияет на сам язык? ;)
ED> Речь не о том, что абсолютно все типы языка являются
ED> объектными типами ,а о том, что С++ предназначается в первую очередь
ED> для разработки приложений, используя объектно-ориентированый подход к
ED> разработке.
"Предназначается в первую очередь" - это уже домыслы апологетов. Разработчики
оперируют понятиями "предоставляет возможности", "предполагает", "облегчает",
"делает удобным" и т.п.
ED> Конечно микроскопом можно и орехи колоть, но сделан он как бы не для
ED> этого.
Микроскопия и раскалывание орехов - занятия, как бы, принципиально разного рода
:) А любой нормальный слесарь с удовольствием использует гаечный ключ
подходящего размера и прочности в качестве рычага, а отвертку с металлической
ручкой - в качестве стамески (в некоторых отвертках обух черенка специально для
этого выступает из ручки). Держать при себе постоянно набор специализированных
инструментов, когда есть инструменты универсальные, будет только неопытный или
упертый.
ED> о да, а потом в эти исходники с поризвольно намешанным черт-те чем
ED> смотрят другие люди
Другим людям совершенно не обязательно смотреть на исходник. Во многих случах -
просто-таки вредно.
ED> Вы, кстати, как - теоритизируете или имеете опыт
ED> написания enterprise-level приложения с саппортом?
Имеем.
ED> совершенно неумеcтный пример. Сначала в этой эхе про автомобили,
ED> теперь про певцов.
Hу, кому способности к пониманию аналогий не дано - тому этих примеров не
понять :) Большинству без руководящих указаний и авторитетных мнений вообще
жить трудновато :)
ED> для начала я бы хотел взглянуть на чудо-драйвер для девайса с 512
ED> байтами памяти, написанный на С++ с применением объектов, потоков,
ED> наследования и виртуального чего-то там.
Во-первых, 512 байтами чего? Девайсов с 512 байтами памяти для кода уже
давным-давно не существует. Если для данных - какие проблемы?
Во-вторых, из чего вытекает надобность написания драйвера непременно с
применением наследования и виртуального чего-то там? ;) Это, типа, религиозная
догма такая - "какова бы ни была программа на C++, она непременно должна
содержать наследование и виртуальное чего-то там"? ;)
Во-третьих, каким боком тут потоки? В _языке_ C++ никаких потоков нет. Они есть
в стандартных библиотеках C++, однако полагать, что эти библиотеки должны
использоваться уже потому, что существуют - также религиозная догма.
В-четвертых, если драйвер уже написан на C и успешно работает, я берусь
переписать его на C++ с применением объектов, наследования и виртуальных
функций, и его объем при нормальном компиляторе практически не увеличится.
EM>> ;) И заодно привести пример "более других средств", с помощью
EM>> которых мой труд станет приятнее/эффективнее/надежнее, а драйверы
EM>> - меньше по размеру и быстрее в работе? ;)
ED> Assembler/C
ED> про приятнее и надежнее - это уже к личным ощущениям/умениям, а вот
ED> эффективнее - да.
Hа ассемблерах драйверы не пишут уже много лет - сишные (в том числе плюсовые)
оптимизаторы давно не вызывают грустных улыбок при взгляде на продукт их работы
:) А если драйвер пишется на C, то при переходе к _разумному_ (а не
обязательному, дабы соответствовать "идеологии" :) использованию ОО-технологий
он совершенно не теряет в эффективности.
Твоя ошибка в том, что ты сравниваешь объемы и быстродействие программ на C и
C++ "в общем". Типа, как чайники сранивают EXE с сишным printf ("Hello
world!\n") и EXE с плюсовым cout << "Hello world!" << endl, обнаруживают, что
второй раз этак в пять (если не в десять) толще первого, и начинают вопить об
"оверхеде C++" :) Грешен - сам когда-то так вопил, пока не научился разделять
мух с котлетами. Hо ты, как мне кажется, за последние десять лет ни разу не
рассматривал продукта работы нормального оптимизатора, иначе не писал бы
подобной ерунды.
Для оценки: небольшой драйвер на C++ под 2k/XP, около 9000 строк чистого кода
(после выкидывания пустых строк и комментариев). С объектами, наследованием,
виртуальными функциями и шаблонами. Бинарник - 19840 байт при оптимизации на
скорость. При оптимизации на размер - 17632 байта. Это без напрягов с
минимизацией алгоритма - писано практически на коленке, наскоро. С напрягами
было бы порядка 15 кб.
Eugene Muzychenko
16 Mar 05 19:39, you wrote to Alex Besogonov:
ED> But if you look in my first book on C++, it says: we support
ED> traditional C style programming, and we do it better than C; we
ED> support data abstraction; and we support object-oriented programming.
ED> вы об этом? И где здесь что С и С++ - один и тот же язык, и что printf
ED> лучше std::cout?
А где здесь о том, что C и C++ - это "совершенно разные" языки, и что cout
лучше printf?
Eugene Muzychenko
16 Mar 05 14:19, you wrote to me:
EM>> Идеология сродни религии.
ED> с каких пор и чем?
С рождения - тем, что в основе большинства идеологий лежат постулаты, а не
аксиомы.
ED> однако рассказы что printf лучше, чем производные от ostream - это как
ED> бы предъявления претензий создателю предмета, нет?
Когда идеология утверждает, что все printf нужно в обязательном порядке
заменять на производные от ostream - можно сказать и так.
ED> именно. А вы как-то по особому пользуете стиральную машинку? Hе
ED> поделитесь опытом?
Хороший, кстати, пример. Большинство стиральных машин имеет идеальную высоту
для занятий сексом :)
ED> Вот из области теории перешли к практике- писать прошивки на
ED> Ц++ *не нужно*.
Сугубо зависимо от того, какая это прошивка, и для чего. Инструмент выбирается
под задачу. Альтернатива "чистый C или C++ со всеми наворотами, третьего не
дано" существует только в умах упертых фанатов :)
ED> Я бы сказал, потому что С++ для этого не предназначен, но вы опять
ED> полезете заниматься психоанализом по Фрейду, уходя от сути
ED> вопроса.
Да мне плевать с высокой башни, для чего он предназначен :) В который раз
повторяю: я использую _свойства_ предметов, а не их официальное назначение.
Обладает предмет нужными мне свойствами - я использую его, и глубоко по
барабану мне его высшее божественное предназначение :)
ED>>> и почувствуйте разницу между тем же, но написанном на pure C.
EM>> При грамотном подходе особой разницы не будет.
ED> примеры.
Конкретных примеров целенаправленного переписывания программы на C в программу
на C++ с целью иллюстрирования, пардон, не держу :) Пример драйвера на C++
приведен в предыдущем письме. Будешь упирать на то, что написание на чистом C
сэкономило бы целых два килобайта размера? ;) Это, кстати, будут не проценты от
указанного размера - при увеличении объема кода относительных оверхэд только
снижается.
ED> если бы взять нос от Ивана Петровича, да приставить к голове Василия
ED> Ивановича....(Ц) Гоголь (кажется, цитата не точная)
Кое-кто тут меня упрекал в использовании аналогий, кажется... ;)))
Eugeny Dzhurinsky
16 Mar 05 23:51, you wrote to me:
>> недели три тому назад. Получается в этом. Правда я не знаю
>> подходит ли GCC 3.4
>> под определение *нормального* с вашей точки зрения.
jg> похоже что нет. сегодняшняя компиляция им на четырех платформах
jg> привела к одинаковому результату - SIGSEGV на ровном месте ;)
гм, а может в консерватории дело? =)
Eugeny
Eugeny Dzhurinsky
16 Mar 05 22:14, you wrote to me:
AB> В терминологии ИСО техпроцесс - это процесс разработки и изготовления
AB> продукта. Он, конечно, включает в себя настройки станков, но это уже
AB> конкретные детали производственного процесса (входящего в него как
AB> подпроцесс).
AB> ИСОшные стандарты определяют стандарты на создание техпроцессов :) То
AB> есть такой мета-техпроцесс.
а ISOшные стандарты указывают, что и как надо применить при заданном случае?
Если нет - то мимо кассы, мы не о том разговариваем.
>> вы будете смеяться - очень много вещей было получено либо
>> эмпирически, либо методом решения поставленной задачи в пьяном виде
>> студентом-технологом с введением поправочных коэффициентов при
>> реальном использовании расчитанного процесса.
AB> Вот, а говорите "все рассчитано до миллиметра".
ну ведь и расчитано, если не студентом-технологом :)
AB> Программирование по большей части как раз и есть поиск таких
AB> "поправочных коэффициентов".
понятно, хороший подход.
AB> Framework'и - это как раз и есть заранее продуманные и проверенные
AB> решения. Эдакие рассчитанные коэффициенты.
фреймворки ни с какой сторoны не являются "решениями". Они предоставляют
некий уровень абcтракции, не более того, IMHO.
>> почему же, очень даже и знаю, но КД отличается от ТД очень и очень
>> сильно. Hе рассказывать же вам, чем конструктор отличается от
>> технолога?
AB> Так программист - он не технолог, а конструктор.
прогрaммист - он как раз таки технолог, т.к. по большому счету нихрена не
знает о предметной области, а выполняет поставленную задачу.
AB> Технологи в программировании тоже есть, но они занимаются уже конечной
AB> "тонкой настройкой" софта.
это уже рабочие-наладчики =)
AB> Тут написано о том, что С++ - это не чистый объектный язык, а смесь
AB> многих стилей. И там же где-то говорится про то,
но про превосходство printf над std::cout там ведь ничего нет?
>> AB> Для таких вещей есть Boost. И люди там уже пишут замену
>> AB> fstream'ам.
>> а при чем здесь Boost и как он относится к стандартной библиотеке?
AB> Многие создатели Boost'а - члены ИСОшного комитета по С++, а части
AB> Boost'а планируются включить в будущий Стандарт библиотеки С++.
ну вот когда включат - тогда и.
З.Ы. пора менять топик =)
З.З.Ы. а как все начиналось-то, принтф, стд::каут - а перешло на ИСО,
технологию ... ужос.
Eugeny
Eugeny Dzhurinsky
16 Mar 05 21:56, you wrote to me:
>> нет, вы таки отсыпьте мне этой травы.
AB> Какие проблемы?
Да никаких, кроме того, что виртуальные методы - это методы, которые
*наследуются* и *перекрываются* при наследовании, оставляя возможность вызова
метода наследника при обращении к экземпляру (указателю на) родительского
класса, содержащего наследника. А то, что вы привели ниже - это *указатели на
функцию*, ничего общего с виртуальными методами не имеющие, кроме представления
в скомпилированном виде. Матчасть подучите сами или посоветовать (ключевое
слово - *полиморфизм*)?
AB> Код на С:
AB> typedef struct tagMyObject
AB> {
AB> IPosition *pos;
AB> int (STDMETHODCALLTYPE *SetPosition)(
AB> IMyObject * This, IPosition *pos);
AB> int (STDMETHODCALLTYPE *GetPosition)(
AB> IMyObject * This, IPosition **pos);
AB> } MyObject;
AB> И на С++:
AB> class IMyObject
AB> {
AB> public:
AB> IPosition *pos;
AB> virtual int SetPosition(IPosition *pos)=0;
AB> virtual int GetPosition(IPosition **pos)=0;
AB> };
AB> Вот вам и виртуальные методы. Именно так, кстати, работает COM.
мы его теряем....
>> А прежде покажите мне применение ООП и *виртуальных методов* на C. С
>> множественным наследованием, перегрузкой, dynamic cast и прочим.
>> Только не надо про поделки с массивами указателей, где сам черт ногу
>> сломит если через месяц надо чего-то куда-то добавить.
AB> GTK и GLib вам в руки (они написаны на чистом С). Там есть все это,
AB> кроме множественного наследования реализации.
ой, только не надо про ГТК, ладно? Этот пример гениального ОО на С уже
навяз в зубах. И это не в эхотаг ни разу.
Eugeny
Eugeny Dzhurinsky
17 Mar 05 02:29, you wrote to me:
ED>> почему же, если у меня есть реализация паттерна visitor на куче
ED>> коллекций, то приведение займет не так уж и мало времени. Или вы
ED>> со мной не согласны?
VF> Hе согласен. Реализуй этот паттерн на pure С (даже страшно представить
VF> как это будет выглядеть)
как выглядеть - это еще пол беды, а вот как оно будет
поддерживаться/развиваться
в дальнейшем - это уже ночной кошмар.
VF> и сравнивай с С++. Этот паттерн применяется
VF> для увеличения гибкости системы в ущерб всему остальному (в т.ч. и
VF> скорости) там, где гибкость важнее всего остального. И он имеет
VF> отношения к С++ не больше чем и к pure C.
то есть на С++ он будет так же ужасно выглядеть как и на С?
ED>> про статическое наследование речь и не идет - оптимизатор все
ED>> попытается оптимизировать :)
VF> А где ж тогда неуловимый оверхед?
*занудно бурчит под нос* множественное наследование/позднее
связывание/исключения/потоки/перегруженные операторы....
то есть все те вкусности С++, которые кто-то не хотел перечислять выше по
треду.
VF> Короче говоря, возьми нормальный
VF> современный компилятор С++ и запость сюда ассемблерный листинг того,
VF> что ты считаешь оверхедом. А то разговор беспредметный, и все больше
VF> про траву...
как-нибудь запощу.
А про траву - таки отсыпьте, можно пол-мешка, я менеджерам дам, с заказчиками
общаться.
Eugeny
Eugeny Dzhurinsky
17 Mar 05 02:31, you wrote to me:
ED>> отсыпьте мне этой травы?
VF> А по существу?
=cut=
Разница безусловно будет, но только в лучшую сторону. Hичего из
вышеприведенного не приводит к какому-либо оверхеду по сравнению с
pure С
=/cut=
а что тут еще *по существу*, если человек не представляет себе, где
будет оверхед при использовании Фенечек от С++ в виде множественного
наследования, виртуальных методов и поздего связывания, тех же исключений?
ED>> как жалко - уже и компилятора нету....
VF> Да, это самая большая проблема. Hаписать приличный компилятор С++
VF> очень непросто. Компиляторы для PC можно пересчитать по пальцам.
ED>> А на чем же вы основываетесь, утверждая что оверхеда не будет?
VF> Hа ассемблерных листингах.
компилятора ,которого нет?
/выдыхай, Бобер!/
ED>> Hа сферическом абсолютно опримизирующем компиляторе с модулем
ED>> телепатического анализа "а чего это придурок хотел сделать в этом
ED>> месте"?
ED>> =))
VF> Первый попавшийся VC7.1 подойдет на эту роль.
он так и говорит в сообщениях? И кстати, он в вакууме находится? Или
просто сферический?
ED>> а зачем, простите, тогда в писании прошивки нужен С++? что вы от
ED>> него пользовать собрались?
VF> Помимо потоков и исключений в С++ есть много чего интересного.
VF> Hастолько много, что даже не буду пытаться рассказать в двух словах.
VF> Про это пишут целые книги.
это называется *пальцем в небо*. Укажите, что вы будете пользовать от С++
при раработке прошивок, можно в трех словах (а не в двух).
ED>> при том же, что и С++. Я всякое видел, но чтобы С++
ED>> позиционировался как средство разработки прошивок или там
ED>> драйверов контроллеров - это в первый раз.
VF> Все когда-нибудь бывает в первый раз. M$, например, грозится писать
VF> драйвера на C#. По сравнению с этим оверхед потоков и эксепшинов в С++
VF> - это ничто.
*ужасается* и куда катится мир...
Eugeny
Alex Besogonov
> AB> Какие проблемы?
> Да никаких, кроме того, что виртуальные методы - это методы, которые
> *наследуются* и *перекрываются* при наследовании, оставляя возможность вызова
> метода наследника при обращении к экземпляру (указателю на) родительского
> класса, содержащего наследника.
обратная совместимость, так что реализация метода в vtable вполне может
обратиться и к "базовому классу".
> А то, что вы привели ниже - это *указатели на функцию*, ничего общего с
> виртуальными методами не имеющие, кроме представления в скомпилированном виде.
Виртуальные функции в С++ и есть функции, вызываемые по указателю через
vtable. ВСЕ, не надо больше им ничего примешивать.
> Матчасть подучите сами или посоветовать (ключевое
> слово - *полиморфизм*)?
Чего именно мне подучить?
> AB> Вот вам и виртуальные методы. Именно так, кстати, работает COM.
> мы его теряем....
Что здесь не так?
> AB> GTK и GLib вам в руки (они написаны на чистом С). Там есть все это,
> AB> кроме множественного наследования реализации.
> ой, только не надо про ГТК, ладно? Этот пример гениального ОО на С уже
> навяз в зубах. И это не в эхотаг ни разу.
Это почему? Реализация компонентов в GTK вполне нормальна. Что именно в
ней не так?
Eugene Muzychenko
17 Mar 05 11:13, you wrote to Vlad Foltz:
VF>> А где ж тогда неуловимый оверхед?
ED> *занудно бурчит под нос* множественное наследование/позднее
ED> связывание/исключения/потоки/перегруженные операторы...
Про потоки занудливо бурчать уже хватит, ибо это не элементы языка C++. Все
остальное при _разумном_ применении если и порождает оверхед, то весьма
скромный и отлично контролируемый.
А вообще, ты очень сильно смахиваешь на академичного препода, которому в свое
время столь же академичные преподы вбили в голову, что надо делать непременно
вот так и вот так, и никак иначе, вот он и бубнит по кругу одно и то же, ибо по
существу сказать ему и нечего :)
Eugene Muzychenko
17 Mar 05 11:19, you wrote to Vlad Foltz:
ED> а что тут еще *по существу*, если человек не представляет себе, где
ED> будет оверхед при использовании Фенечек от С++ в виде множественного
ED> наследования, виртуальных методов и поздего связывания, тех же
ED> исключений?
Это ты о себе, очевидно? ;) Ибо те, кто успешно занимается разработкой софта на
C++ в условиях ограниченных ресурсов, как раз очень хорошо представляют себе,
где и какой будет оверхед. И умеют выбирать из множества предоставляемых C++
средств _адекватные_, а не "соответствующие идеологии" :) Достигая при этом
_соотношения_ скорости разработки, эффективности, надежности, оверхеда и
стоимости, недостижимого ни в pure C, ни в "pure C++" (позволю себе такой
термин для иллюстрации отстаиваемого тобой подхода к языку" :) А те, кто
представляет плохо - с ужасом вопрошают "как можно разрабатывать low-level софт
на high-level языках?!!!" :)
Кстати, я вот имею опыт разработки на C/C++ как высокоуровневого софта, так и
низкоуровневого. А каков твой личный опыт написания тех же драйверов, о которых
ты пытаешься столь глубокомысленно рассуждать? ;)
ED> Укажите, что вы будете пользовать от С++ при раработке прошивок, можно
ED> в трех словах (а не в двух).
То, что нужно. Вопросы? ;)
Andrey Sverdlichenko
> А прежде покажите мне применение ООП и *виртуальных методов* на C. С
> множественным наследованием, перегрузкой, dynamic cast и прочим.
А вы ООП без множественного наследования, перегрузки, dynamic cast
и прочего себе представить не можете?