Здесь вы можете оставить сообщение для владельца сайта, отзыв о функционировании, оформлении, содержании и вообще написать всё, что думаете по этому поводу. Просьба придерживаться темы ("по этому" — это ещё не "по любому") и соблюдать приличия :-)
Обратите внимание, что связаться с автором сайта можно также и через страницу обратной связи, которая позволяет отправить автору email.
Учтите, что комментарии на этом сайте премодерируются.
[Все старые комментарии перемещены в архив >>>]
Лисп здесь при
Лисп здесь при том, что из всех встреченных по жизни языков, Tcl показался мне ближе всего именно к Лиспу. То есть, исходилось не из разницы в парадигмах, а из сходства самих языков. Ну, правда, оставил очень неоднозначное впечатление... Совершенно неинтуитивный язык, много конструкций, которые сравнить оказалось не с чем. Взять upvar, uplevel, к примеру - это же додуматься надо вводить в язык такую кочергу для доставания адресов переменных, давно уже закопанных в стеке! Чего бы просто и понятно не указать в передаваемых аргументах или в параметрах вызываемой функции то, что значение переменной будет меняться? Людям-то понятней будет!
Но в целом, язык достаточно интересный (именно в силу своей неинтуитивности, неожиданности, своеобразия синтаксиса), хотя и практически проще применять тот же Python и даже Perl. Каких-то особых преферансов выявлено не было.
"Честно говоря,
"Честно говоря, его практическая применимость выглядит для меня довольно мутной."
В общем, да! :) Понять могу. Примерно также полагаю, поскольку тоже не раз хватался и за Lisp, и за некоторые другие "нестандартные" языки. И если, скажем, Пролог находил у меня применение как некая достаточно удобная среда для органицации баз данных - очень своеобразный язык - сформулировал условия, ограничения, и тут же имеешь ответ, то задачи для Lisp'а не находилось вообще!
Попробуйте на
Попробуйте на досуге решить задачу символьного дифференцирования. Дана формула в текстовом виде, надо взять производную по заданной переменной, попутно выкинув всякие сложения с нулём и умножения на единицу, которые при автоматическом дифференцировании отовсюду вылезают.
А ещё Лисп хорош при анализе и преобразованиях всяческих SGML-подобных разметок, в смысле XML и HTML. Я вообще не понимаю, какого чёрта мы вынуждены рисовать эти нелепые тэги в угловых скобках; тема слабоструктурированных данных полностью раскрыта S-выражениями в конце 1950-х годов, то есть за четверть века до появления HTML.
Про Лисп
Я знаю только один приличный учебник Лиспа для начинающих (в смысле, начинающих лисперов). Хювёнен, Сеппянен. Мир Лиспа. Т.1. Вроде в инете где-то валялись djvu от него. Второй том не нужен, ибо лет двадцать как утратил остатки актуальности, а вот первый как был, так и есть.
А про функциональщину в качестве начального этапа обучения программированию всё, на мой взгляд, просто: где вы найдёте столько адекватных преподавателей функциональщины.
"только один
"только один приличный учебник"
На самом деле не всё так уныло!
Маленьким "сишникам" можно, к примеру, ещё посмотреть "The Little Schemer" (Daniel Friedman), "Land of Lisp..." (Conrad Barsky), Paul Graham "Ansi Common Lisp" имеется даже на русском. Есть и с чего начать, и чем продолжить.
Про Лисп again
Припадки "интеллектуального голодания" бывают у многих "сишников". Есть в Лиспе что-то, тут не попрёшь! Тоже не раз в этом направлении двигаться пытался. Один из наиболее длительных "лисповых запоев" был связан с таким диалектом, как newlisp, представляющим собою откровенно скриптовый язык и довольно здорово отличающийся от классических реализаций (Common Lisp, прежде всего). Около года ваял скрипты общего назначения именно на нём. И вроде, даже интересно было, доволен был. Правда, когда в какой-то момент написал какой-то скрипт (по старинке!) на Python, отложив уже привычный newlisp в сторону, неожиданно даже для себя вздохнул с облегчением! :) Окинув взглядом всё, что было на нём понаписано, опять же неожиданно для себя обнаружил, что написано-то всё в стиле исключительно процедурном (никакой функциональщины там даже и рядом не лежало). Наличие синтаксических скобок в языке сами по себе не делают его ещё функциональным. Везде, где "по-хорошему" должна бы быть рекурсия, вопрос решался итеративно. Так и зачем оно было надо? Если для решения моих задач существуют языки именно для моих задач! Вот не попадались сроду задачи, требующие Лиспа! Так что, никаких "слёз радости" не было и в помине. Ну, а двадцать одну минуту вполне можно и выбросить из жизни - вполне достаточно, думаю, для понимания основ. Там всё просто. Тем более, для "сишника"...
Эх, string, понимаешь...
Вот нет у людей чувства прекрасного!
Бывает засидишься малость подольше, код разных языков воспринимается уже несколько своеобразно - видишь "красоту" кода, что ли... Чисто визуально. Неестественность любая в языке прослеживается. Сложно довольно объяснить ощущение, но когда посреди откровенно сишного кода встречается какой-нибудь "вехтор" заместо массива, то выглядит он каким-то ублюдком просто! Инородным чем-то. Нечто типичное не то. По глазам просто бьёт. Вот в Python почему-то любой контейнер выглядит изящно - на месте он. На своем месте. Да и синтаксис красивше. "Стринги" опять же эти! Ну, не мущинская одёжа, эти ваши "стринги"... Char! И крути его как хочешь! Не для стрингов С++, не для стрингов. Ведь наваяют целые контейнеры стрингов - смотреть на код страшно! А ведь начиналось когда-то так хорошо... Классы. Классы в Си дадены были для сотворения мира - от атома до Вселенной, любой уровень! Для созидания. Для строительства. Для выражения мысли, которая более по-человечески звучит по-сравнению с чистым Си. А сейчас в какой кусок кода ни плюнь - что от лукавого, что от Степанова, что от прочих затейников... В общем, сплошные стринги! Просто глазу отдохнуть негде...
Вот в чистом Си почему-то ничего никогда глаз не режет!
Вот в чистом Си
Вот в чистом Си почему-то ничего никогда глаз не режет!
Бгг, а вы код openssl, например, смотрели?
Справедливости ради
это всё-таки не язык виноват. Написать как курица лапой можно на любом языке.
Так и я про то
Так и я про то же.
В чистом Си -- ещё как режет
Знаете, что ОНИ сделали с переменной errno? Она теперь не переменная, она теперь макрос. Примерно такой:
Вот не знаю как вам, а мне макрос маленькими буквами ещё как глаз режет. И константы, вводимые enum'ом, но при этом набираемые капсом — тоже. И то, что если
f— имя функции, то написать можно хоть простоf, хоть&f, хоть*f— и это всё будет одно и то же — режет-режет. А если вернуться к библиотеке, то как вам, например, мьютекс внутри malloc'а? Вот я, например, принципиально никогда — НИКОГДА — не использую треды и другим не советую, почему я должен терпеть мьютексы в библиотечных функциях? Хоть свою libc пиши.Увы, чистый Си — коленно-гаражная поделка, не более того, и каждый новый теракт в виде очередного стандарта это всё только усугубляет. Но, как я неоднократно подчёркиваю в тексте книги, будь он хоть триста раз гаражной поделкой, любим мы его не за это.
"Вот я,
"Вот я, например, принципиально никогда — НИКОГДА — не использую треды"
А почему? Что-то не так с многопоточностью в принципе?
Офигеть можно
Мне вот интересно, вы такие вопросы всерьёз задаёте? Если да, то вам треды использовать просто опасно: тем, кто в теме разбирается, заведомо известны все аргументы противников многопоточности (как, например, мне известны все аргументы её сторонников). Ну то есть с этими аргументами можно не соглашаться, но ЗНАТЬ их строго обязательно.
Настоятельно рекомендую что-нибудь на эту тему погуглить. Я с двух запросов нашёл вот такую презенташку: https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf По правде говоря, у меня этот урл не открылся, пришлось скачивать сохранённую копию из веб-архива. Вот этот файл: http://www.croco.net/misc/why_threads_are_a_bad_idea.pdf Останавливаться на этом не следует: во-первых, это всего лишь презенташка без текста, только тезисы, а во-вторых, она охватывает далеко не всё.
В качестве продолжения напомню старую цитату из Алана Кокса:
A computer is a state machine. Threads are for people who can't program state machines.
Я с Коксом полностью согласен, и не потому что он Кокс, а потому что он, зараза, тут абсолютно прав.
А в-третьих, эта
А в-третьих, эта презенташка очень слишком древняя.
http://russian.joelonsoftware.com/Articles/Craftsmanship.html
Вообще не о том
Ссылка любопытная, но где там хоть слово о том, чтобы треды могли быть полезны? Впрочем, и о том, что они вредны, только ссылка на Реймонда и всё.
Маленькие треды - маленькие беды, большие треды...
Да, спасибо. В столь явном виде мысль "threads are a bad idea" попалась впервые.
Но, правда, это действительно лишь "презенташка". К чему-то. И без этого "чего-то" она выглядит довольно убого. По сути, всё, что там выражено - это то, что треды - вещь запарная ("very hard to program"), слабодуракоустойчивая ("Forget a lock? Corrupted data."), требующая квалификации и однозначного понимания, куда их можно пихать, а куда нет ("Too hard for most programmers to use."). И потом, "презенташка" 95-го года от автора тикля - как раз время появления и развития наиболее популярных графических интерфейсов. Так что, не исключаю, что многоупоминаемое "event-driven programming" связано именно с этим. И именно поэтому треды оказались нехороши. Когда прикручивался к Tcl Tk уже не помню. Но то, что последние версии Tcl имеют уже многопоточность - это есть факт. Отказ от многопоточности... эдак недалеко и до признания, что и вытесняющая многозадачность - фигня. А чего - каждому процессу свой процессор! "One thread per CPU"? Да никто ж не против! Собственно, вполне реально... лет так через "дцать". Ну, а пока - треды, как бы нехороши они не были! :)
Как бы то ни было - за новую для меня информацию благодарю. Вопрос бы надо угуглить повнимательней.
По сути, всё,
По сути, всё, что там выражено - это то, что треды - вещь запарная ("very hard to program"), слабодуракоустойчивая ("Forget a lock? Corrupted data."), требующая квалификации и однозначного понимания, куда их можно пихать, а куда нет ("Too hard for most programmers to use.").
Простите, вам МАЛО? Ладно, добавлю ещё один аргумент: от них нет никакого полезного толка, одни проблемы.
Отказ от многопоточности... эдак недалеко и до признания, что и вытесняющая многозадачность - фигня.
Чушь собачья. Я никогда не имел ничего против использования параллельных процессов, если это делается по делу. Но не тредов, работающих в одном адресном пространстве.
Ужас внутри malloc'а
как вам, например, мьютекс внутри malloc'а?
Взмедитировал было, но не осознал почему-то, не ужаснулся. Надо будет попробовать! :)
Что "нехорошо" - понял. Далее будем посмотреть.
Так классика же
Классика любого правильного развития инструмента состоит в том, что каждый расплачивается только за то, чем пользуется, а за ненужное — не платит. Мьютекс внутри malloc'а нужен только тредофагам, а расплачиваются за него все, кто пишет на Си и/или пользуется однопоточными программами, написанными на Си.
Давить давилкой.
Есть thread-safe
Есть thread-safe библиотеки, а есть не thread-safe библиотеки, в том числе и stdlib есть в не thread-safe реализации. Есть опции/ключики для отключения thread-safe. Слышали про такое?
ЩАЗ
Если бы всё это было, настал бы рай.
В действительности есть только некоторые функции (вроде localtime_r), которые специально сделаны как multithread safe, в отличие от их прообразов без _r, которые в их исходной спецификации реализовать как mt-safe невозможно. Никаких "ключиков/опций" для "отключения" mt-safety нет, не существует даже compile-time options в реализации самих библиотек для этого -- во всяком случае, в glibc и в musl. Не могу сказать, что смотрел прямо вот _все_ реализации libC, но очень сомневаюсь, что такое есть хоть где-то. Если говорить о стандартах, то в "современных" их версиях прямо написано, что замена malloc/free собственными функциями пользователя ведёт к U.B.
Между прочим, сделать две параллельные версии функций, имеющих/не имеющих в пузе мьютексы, можно было бы без особых проблем, и те их версии, которые с мьютексами, включить в pthread, так что при наличии -lpthread подхватывались бы именно эти версии, а при отсутствии — версии из libc без всяких мьютексов. Но этим, разумеется, никто не заморочился, ни гнушники с их монстром по имени glibc, ни Rich Felker с его более-менее разумным musl'ом. Не, нуачо, маленький же оверхед, и вообще, все же пишут на тредах, ога.
Так что прежде чем спрашивать меня, слышал ли я о чём-то, иди сам предмет поизучай.
Раз уж начал тут писать
Раз уж начал тут писать, то не могу не спросить про STL. Почему вам кажется, что это плохая идея включить его в стандарт? Для примера возьму std::string -- разве чем-то плохо его использование в коде? На мой взгляд, это удобно всегда иметь под рукой некий автообъект, который содержит в себе строчку и который присутствует на всех компиляторах. Ну, то есть я серьезно не понимаю, в чем проблема присутствия этого класса в стандарте с вашей точки зрения. Чтобы как-то "прорекламировать" этот класс, я на досуге порылся в ваших исходниках, и обнаружил ошибку в http://www.croco.net/software/inifile/ :
IniFileParser::Parameter::Parameter(const char *aname, const char *aval)
{
name = new char[strlen(aname)+1];
strcpy(name, aname);
value = new char[strlen(aval)+1];
strcpy(value, aval);
next = 0;
}
IniFileParser::Parameter::~Parameter()
{
delete[] name;
delete[] value;
if(next) delete next;
}
-- в случае если второе выделение памяти закончилось неудачей (= выкинулось исключение), то первое выделение памяти утекает в неведомые края и остается с процессом до конца. Конечно, проблема так себе, но она имеет место. ИМХО, если использовать std::string в данном случае, то данная проблема исключена просто автоматически, и какого то оверхеда с тем, что сейчас имеется в этом коде, в связи с использованием STL, я не могу придумать (ну, кроме пары dword'ов, которые увеличат размер класса).
Полчаса здорового смеха продлевают жизнь на сутки
На вопрос про STL тут на сайте в комментариях ответы неоднократно давались, даже прямо на этой странице. Повторять одно и то же мне изрядно надоело, поэтому не буду (впрочем, как правило, это и бесполезно: если человек не понимает, почему STL ни на что не годен, то никакие объяснения ничего не дадут).
Но вот дальше, гм... э...
и обнаружил ошибку
если второе выделение памяти закончилось неудачей (= выкинулось исключение), то первое выделение памяти утекает в неведомые края и остается с процессом до конца
Вы ведь пошутили, да? Хотя, похоже, не пошутили.
Ну так вот, в современных (читай — послеDOSовских) условиях операция выделения динамической памяти может кончиться неудачей в двух случаях: если процесс дошёл до максимального возможного размера виртуального пространства (обычно 3Gb на 32-битных системах, на 64-битных можно считать, что этого предела нет вообще) и если в системе реально кончилось пространство для свопа. О наступлении второго случая ваш процесс не узнает — в такой ситуации, во-первых, встаёт раком вся система, и тут уже не до какого-то там несчастного процесса, и, во-вторых, ошибка как таковая случается не при выделении памяти, а при обращении к ней, и выглядит это как прилетевший фатальный сигнал, а вовсе не как NULL из malloc'а и тем более не как исключение из new. Что касается первого случая, то ежели процесс дорос до 3Gb, то, очевидно, работать дальше он заведомо не сможет, так что даже если при этом система его не пристрелит (насколько я понимаю, это зависит от версии ядра), то он в любом случае сдохнет сам, причём прямо сейчас. И уж во всяком случае жалкая утечка памяти, случившаяся непосредственно перед полным армагеддецом — это самое последнее, что должно нас волновать.
(NB: да, я не проверяю значение, возвращаемое malloc'ом)
если использовать std::string в данном случае, то данная проблема исключена просто автоматически
Безотносительно того, что в данном случае проблема существовала исключительно в вашем воображении — если хотите, чтобы проблемы решались автоматически, пишите на питоне или на пхп — там вообще динамической памяти нет.
На вопрос про STL
На вопрос про STL тут на сайте в комментариях ответы неоднократно давались, даже прямо на этой странице.
Так я ж все их прочитал. На мой взгляд, они все несколько неконкретны, например "С ними не так буквально всё. Впрочем, это либо очевидно, либо — если не очевидно — то любые объяснения, как правило, бессмысленны". Не могли ли бы вы пояснить на примере, чем, по вашему мнению, замена голых указателей, в той же либе inifile, на std::string плоха? (я не про внешние интерфейсы, а про реализацию)
Ну так вот, в современных (читай — послеDOSовских) условиях операция выделения динамической памяти может кончиться неудачей в двух случаях: если процесс дошёл до максимального возможного размера виртуального пространства (обычно 3Gb на 32-битных системах, на 64-битных можно считать, что этого предела нет вообще) и если в системе реально кончилось пространство для свопа
А разве нельзя через ulimit ограничить память процесса? В OpenBSD вроде вообще это ограничено по дефолту довольно жестко.
И уж во всяком случае жалкая утечка памяти, случившаяся непосредственно перед полным армагеддецом — это самое последнее, что должно нас волновать.
Здесь соглашусь, думал, что этот параметр прилетает извне (из файла, например, где могут быть строки по 768мб), но по какой-то причине конструктор вызывается только с "" во втором параметре, если я ничего не пропустил. Вот, видимо, более "честный" пример на тему std::string vs char*:
delete[] value;
value = new char[ll+1];
-- тут строка вроде может прийти через
IniFileParser::SetParamот пользователя либы (который мог прочитать целый гигабайт из файла), а т.к. value не обнуляется после delete[], то рано или поздно будет double free.Тут вопросов целый ряд
Пардон, долго я на этот коммент внимания не обращал, поскольку в нём, кажется, вопрос всего один, но на самом деле их тут целый ряд:
— иначе говоря, почему я не стал бы его использовать в программах, даже если бы он не был ни частью стандарта, ни частью STL; кстати, это, пожалуй, самый интересный вопрос — если STL я не использовал никогда ни в одной из своих программ, то классом string я до 2001 года активно пользовался, и лишь в 2001 году понял, что делаю это зря;
На часть этих вопросов тут в комментариях ответы уже были даны, вы просто предпочли их не заметить, зацепившись за "рамочную" фразу и решив, видимо, что она тут единственная. Так или иначе, рано или поздно мне придётся сформулировать развёрнутые ответы на каждый из этих вопросов. Извините, но это не прямо сейчас, тут каждый из этих вопросов тянет на статью килобайт по тридцать каждая.
Но есть одна вещь, за которую вам большое спасибо: это насчёт ulimit'ов. Я почему-то был уверен, что при достижении любого из установленных setrlimit(2)'ом предела процессу тут же приходит полярный зверь песец в виде фатального сигнала, ан нет: лимит на максимальный объём адресного пространства (который ulimit -v, он же
RLIMIT_AS) работает мягче, там, оказывается, brk и mmap возвращают ошибку, и — вуаля! — malloc возвращает NULL. Вот те номер. Я-то был уверен, что заставить malloc вернуть NULL в современных условиях вообще невозможно, ну то есть если, конечно, не давать ему заведомо неправильный параметр, либо нулевой или отрицательный, либо превышающий размер адресного пространства.С другой стороны, гм... double free? Программа, упёршаяся в лимит, до double free не доживёт, и разница между программой, проверяющей malloc на NULL, и программой, которая этого не делает, лишь в том, в каких конкретно выражениях она свалится. Точнее, кто нам скажет, что наша программа "всё": она сама или её окружение (последнее в форме SIGSEGV с сакраментальным "Segmentation fault, core dumped" в результате разыменования нулевого указателя). Программу, которая после NULL из malloc'а ещё что-то сможет сделать, я теоретически могу себе представить (ну там всякие свои кеши подропать, что-то на диск слить и освободить, etc), но на практике таких не бывает. Слишком много сил на это надо и слишком редко до такой ситуации доходит дело.
Хотя, конечно, валиться по SIGSEGV'у — это моветон. Придётся мне, видимо, пересмотреть своё отношение к значению, возвращаемому malloc'ом.
но на самом
но на самом деле их тут целый ряд
Не силен в формулировке своих мыслей, тут вы правильно сформулировали, что я хотел спросить:)
Сразу замечу, что я тоже считаю, что нельзя использовать STL при обучении конструкциям языка C++, потому что это несколько странно.
Так или иначе, рано или поздно мне придётся сформулировать развёрнутые ответы на каждый из этих вопросов.
Было бы интересно почитать:)
На часть этих вопросов тут в комментариях ответы уже были даны
почему я считаю сугубо дебильным класс string
Замечу, что, насколько я помню, на этом сайте были только претензии к отсутствии copy-on-write в реализации строк. Но и при использовании malloc/free этого же тоже не происходит. Тем более с COW строками появляются неприятные проблемы, типа того, что если позвали c_str(), то надо делать копию памяти внутри вызовы перед возвратом указателя, т.к. кто-то может сохранить этот указатель (аналогично при любых вызовах приводящих к возврату сырой памяти).
но и свой собственный класс, созданный для обработки строк, который я называю ScriptVariable (см. там же библиотеку scriptpp)
Ну это-то почти очевидно почему. Подозреваю, тот класс создавался для своих узких целей с использованием refcount (и где, возможно, это было оправдано), а в либе inifile это просто не за чем, потому что самой с собой ей скорее всего нечего шарить, а обязывать пользователя передавать такой класс в методы -- это мазохизм для клиента и, скорее всего, пример плохого интерфейса.
С другой стороны, гм...
Я тут еще раз попытаюсь сформулировать что я хотел сказать на примере, безотносительно вашего кода. Допустим, у кого-то есть веб сервер, на который можно аплоадить .zip файлы и получать распакованные из архива файлы. Но нельзя же писать кодяру типа (далее псевдокод в стиле C с допущениями, что не будет integer overflow и не будет ошибок распаковки, связанных с форматом. По какой-то причине отступы пропали)
struct unpacked_file { unsigned char* content; uint32_t content_size; }; int unpack_zip(unsigned char *zip_file, uint32_t zip_file_size, struct unpacked_file **files, uint32_t *files_count) { assert(zip_file); assert(files); assert(files_count); *files_count = get_file_count_from_zip(zip_file, zip_file_size); *files = malloc(*files_count * sizeof(struct unpacked_file)); for (uint32_t i = 0; i != *files_count; ++i) { (*files)[i].content_size = get_one_file_size_from_zip(i, zip_file, zip_file_size); (*files)[i].content = malloc((*files)[i].content_size); unpack_one_file_from_zip(i, zip_file, zip_file_size, (*files)[i].content); } }Потому что кто-то может скрафтить такой zip файл, что несколько первых malloc'ов будут успешными, а последний потребует много-много памяти и выделение окончится ошибкой. Т.о. образом повесить (с помощью memory leak) или убить (из-за разыменования NULL'а) подобный сервер не будет проблемой. В таком контексте, игнорирование результата выделения памяти кажется крайне диким. Ну то есть такое такое поведение возможно для написания программ написанных на коленке для собственных целей, но это не уровень библиотек, которые можно использовать в подобных местах. И поощрять такой подход, на мой взгляд, неправильно. А если же корректно обрабатывать результат malloc'а, то занятая память освободится, сколько бы ее ни было и с сервером ничего не случится.
Пардон за
Пардон за задержку, было сугубо не до того.
Было бы интересно почитать:)
Ну да, осталось только написать.
насколько я помню, на этом сайте были только претензии к отсутствии copy-on-write в реализации строк
Свой класс ScriptVarable я написал (и перешёл на него, тем самым полностью отказавшись от стандартной библиотеки C++) лет за десять до того, как std::string утратил своё единственное полезное свойство.
Нет, класс string я считаю дебильным не поэтому, а потому, что, во-первых, его интерфейс построен дебильно (ЕМНИП, пять методов find, шесть методов replace и всё в таком духе; можете для сравнения посмотреть, как построен интерфейс ScriptVariable), и, во-вторых, потому что этот класс, вроде бы предзназначенный для работы со строками, не умеет как раз того, что постоянно приходится со строками делать — разбиение на слова/токены и перевод чисел в строковое представление и обратно.
с COW строками появляются неприятные проблемы, типа того, что если позвали c_str(), то надо делать копию памяти
Ага, то есть вам дали адрес _чужой_ памяти, а вы возмущаетесь, что не можете её использовать как свою, и (упс) виноват-то, оказывается, COW.
Я бы сказал, что при любых передачах адресов не надо забывать про правило одного владельца, а если про него забыть, то тут уж хоть COW, хоть не COW — не поможет вообще ничего. Ну, разве что сборка мусора, но я сильно надеюсь, что такой вариант вы предлагать не станете.
а в либе inifile это просто не за чем
Дело не в этом, и, больше того, использование класса ScriptVariable с его развесистой функциональностью сделало бы реализацию inifile раза в полтора короче.
Дело в том, что библиотеки не должны зависеть друг от друга. Никакие, никогда, ни за что. До недавнего времени я считал, что стандартная библиотека чистого Си — это исключение из общего правила, сейчас я уже и в этом сомневаюсь.
кто-то может скрафтить такой zip файл,
Ну так проблема-то, естественно, не в zip-файле, а в том, что (а) надо проверять размеры и (б) чтение файла в память целиком допустимо только для очень небольших файлов, т.е. надо либо отказываться работать с файлами, размер которых превышает некую константу, либо, если файлы могут оказываться большими по смыслу задачи, то уметь обрабатывать их порциями.
Т.е. malloc тут вообще ни при чём.
P.S. отступы пропали, потому что тэг code так не работает :) Поменял его на pre. А ещё длина строк в коде не имеет права вылезать за 80 символов, о причинах — вот тут, параграф 1.3.4, стр. 22.
во-первых, его
во-первых, его интерфейс построен дебильно (ЕМНИП, пять методов find, шесть методов replace и всё в таком духе; можете для сравнения посмотреть, как построен интерфейс ScriptVariable)
Ну, это, возможно, действительно странно. Вообще, я думаю, что этому в строке не место, т.к. это алгоритмы, внешние по отношению к контейнеру (хотя бы по тому, что должна быть возможность делать подобные операции и для сырых данных, не конструируя std::string). Предположим, что это legacy-ужосы уровня std::cout -- вас же не заставляют это использовать. Вообще, я строку тоже местами странной нахожу, но можно же выбрать "удовлетворительное" подмножество и пользоваться им. В любом случае, в std::vector подобных странностей нет, если говорить про контейнеры из STL.
шесть методов replace
Забавно, что бывает и больше.
во-вторых, потому что этот класс, вроде бы предзназначенный для работы со строками, не умеет как раз того, что постоянно приходится со строками делать — разбиение на слова/токены и перевод чисел в строковое представление и обратно.
Этож уже алгоритмы. Т.е. это и не должно входить в интерфейс std::string -- в чем проблема использовать что-то внешнее? Для разбиения -- std::find, для перевода чисел в строковое и обратно -- что-то другое. В любом случае невозможно впихнуть в класс строки все, что может кому-либо потребоваться в операциях с ней (сегодня переводим целые положительные числа, завтра числа с плавающей запятой с экспонентой и мантиссой, а послезавтра вообще захотим получать числа из строки "сорок два").
Ага, то есть вам дали адрес _чужой_ памяти, а вы возмущаетесь, что не можете её использовать как свою, и (упс) виноват-то, оказывается, COW.
Если у меня лежит const объект то я считаю, что должна быть гарантия того, что для внешнего наблюдателя (т.е. меня) объект не изменится ни при каких условиях (если честно им пользоваться без всяких кастов, конечно). Иначе это не по правилам языка как-то.
Я бы сказал, что при любых передачах адресов не надо забывать про правило одного владельца, а если про него забыть, то тут уж хоть COW, хоть не COW — не поможет вообще ничего.
Да, я тоже так думаю. Но в примере выше, это было бы несколько неожиданно, что мой const (!) объект которым я владею вдруг может перестать быть владельцем памяти и я это могу заметить, притом что его никто не менял (например, я в другом месте вызвал operator[] для того же объекта, при условии, что там нет константности).
Возвращаясь к теме "чужой" памяти, зачем нужен EnsureOwnCopy() здесь:
char& ScriptVariable::operator[](int i) { if(p) EnsureOwnCopy(); else Create(i+1); return p->buf[i]; }? Это же точно такая же "чужая" память, что и в c_str(), т.е. эти рассуждения можно переложить и на эту функцию, но здесь почему-то создание отдельной копии имеет место (на всякий случай уточню, что я в курсе, что если написать иначе, то будет ошибка).
Дело в том, что библиотеки не должны зависеть друг от друга.
Когда вы писали про использование этой строки, я и подумать не мог, что вы под этим имеете ввиду использование другой библиотеки, в которой реализация строки -- это не основное для чего эта библиотека нужна. Вообще, я подразумевал, что имеется ввиду написание аналогичного класса/копирование имеющегося.
До недавнего времени я считал, что стандартная библиотека чистого Си — это исключение из общего правила, сейчас я уже и в этом сомневаюсь.
Сразу делаете сисколы с неистовой переносимостью?:)
Ну так проблема-то, естественно, не в zip-файле,
Так я это и не утверждал.
(а) надо проверять размеры
Не совсем понял: какие размеры и как их проверять?
(б) чтение файла в память целиком допустимо только для очень небольших файлов, т.е. надо либо отказываться работать с файлами, размер которых превышает некую константу, либо, если файлы могут оказываться большими по смыслу задачи, то уметь обрабатывать их порциями.
Так а я же не против. Можно обрабатывать порциями в памяти, результат писать на жесткий диск, например. Но проблема-то не уйдет: раньше кончалась оперативная память теперь -- жесткий диск. И не думаю, что эти техника работы с RAM/HDD должна как-то отличаться друг от друга с т.з. обработки ошибок. А брать какую-нибудь константу -- это имхо вообще не очень: у кого-то она будет адекватно выглядеть на его машине, у другого она будет выглядеть слишком большой. А через 100 лет константа будет казаться смешной.
А ещё длина строк в коде не имеет права вылезать за 80 символов
А у вас негров линчуют^W^W табы с пробелами перепутаны в scriptpp-0.3.00.tgz . И тега <strike> в комментариях нет.
это алгоритмы,
это алгоритмы, внешние по отношению к контейнеру
Строка — не контейнер. Точнее, она мне в качестве "контейнера" не интересна и не нужна, в моём понимании строка есть абстрактный тип данных, хранящий (спасибо Капитану) строку (в смысле, текст или его фрагмент). То, что строка может рассматриваться как массив символов (причём осторожно, с оговорками и не всегда) — это одно из её свойств, не единственное и не главное.
если говорить про контейнеры из STL
Вроде бы речь не шла о контейнерах. А если бы пошла, то я бы использовал совершенно другие выражения. Если строка мне всё-таки нужна, не в том виде, так в другом (свой-то класс я для этого в итоге всё-таки сделал), то контейнеры не нужны никогда, ни для чего, ни в каких случаях — это заведомо вредная сущность, не имеющая права на существование.
Этож уже алгоритмы
Разделение вида "контейнеры отдельно, алгоритмы отдельно" — это парадигма, внедрённая, собственно говоря, STL'ем и вредная, как и всё, что с этим бастардом связано. На самом же деле в ООП не бывает ничего "внешнего по отношению", там есть только объекты и их методы. Иной вопрос, что STL — это не ООП, а АТД, а его долбаный автор вообще не умеет ООП и неоднократно заявлял, что ООП есть методологическая ошибка.
Если у меня лежит const объект
Тут у вас наблюдается путаница. Как это "лежит const-объект"? Я ни разу не видел, чтобы свой собственный объект (именно объект) делали const'ом, хотя язык это и допускает.
Так вот, если у вас лежит ОБЪЕКТ — ваш собственный объект, например, локально сконструированный в стековом фрейме вызванной функции, и вы с этим объектом не делаете ничего, что могло бы изменить его состояние, то он не может вдруг внезапно перестать быть владельцем его памяти. При COW свою собственную копию делает тот, кого изменяют, а не тот, кто остаётся неизменным.
Если же у вас на самом деле не объект, а константный адрес такового (неважно, ссылка или указатель), то объект при этом не ваш. Как следствие, нельзя предполагать его неизменность, если вы допускаете передачу управления кому-то, кто хотя бы теоретически может этот объект изменить.
Сразу делаете сисколы с неистовой переносимостью?:)
Пока нет. Но не исключаю, что придётся, если дело так дальше пойдёт. Между прочим, сисколлы постабильнее будут, чем libc, в том смысле что в libc поведение некоторых функций то и дело меняется, а сисколлы (во всяком случае, ядра Linux) сохраняют обратную совместимость чуть ли не со временами, когда версия ядра начиналась с нолика.
Не совсем понял: какие размеры и как их проверять?
Прежде чем начинать размещать содержимое файла в памяти, нужно проверить его размер, сравнив таковой с константой, заданной, например, в конфигурационном файле.
раньше кончалась оперативная память теперь -- жесткий диск.
Вообще-то мы вроде malloc обсуждали. Впрочем, проблема с нехваткой жёсткого диска решается теми же сравнениями: во-первых, должен быть установлен верхний предел для размеров файла, а во-вторых, многие сервера отказываются принимать информацию, которую потом нужно будет сохранить, если в результате такого сохранения места на диске останется меньше, чем, опять же, некая константа. Например, postfix так работает.
через 100 лет константа будет казаться смешной
Во-первых, я сильно сомневаюсь, что хоть какой-нибудь софт проживёт сто лет, а во-вторых, если константу задавать в конфиге, проблем с её абсолютным значением возникнуть вроде не должно.
табы с пробелами перепутаны
где?
И тега <strike> в комментариях нет
Так его и нет в XHTML вообще-то.
По поводу STL,
По поводу STL, видимо, мне придется подождать статьи (если она будет, конечно), потому что сейчас обсуждение идет как-то урывками. Например, неясно, чем вам контейнеры не угодили, что не так с контейнерами-алгоритмами, в чем проблема использовать "удовлетворительное" подмножество и т.д. -- слишком большое обсуждение получается.
Тут у вас наблюдается путаница.
Да, я написал полную ерунду. К сожалению, возможности отредактировать комментарий не было.
Между прочим, сисколлы постабильнее будут, чем libc
Я ж говорил, про переносимость на разные UNIX'ы (хотя бы) и на разные хардварные платформы. Даже на линуксе x86 эти сисколы по разному делаются вроде (sysenter/syscall/int 80h). В этом плане, полагаю, переносимость околонулевая (если вы собрались хардкодить линуксовые вызовы, конечно, а не как интересный факт написали).
в том смысле что в libc поведение некоторых функций то и дело меняется
Я не специалист по libc -- можно ли примеры, ради интереса?
сравнив таковой с константой, заданной, например, в конфигурационном файле
Возможно, это логично для какой-то конечной программы, но не для либы. Я, например, (как разработчик конечной программы, которая использует некую либу), могу ограничить потребляемый размер через ulimit или запуская x86 на x64, позволяя использовать программе все что она пожелает. Не совсем ясно, в этих случаях, почему либа должна меня ограничивать в выборе средств. Впрочем, вы вроде согласились задуматься над проверкой кода возврата malloc'а, поэтому, видимо, и обсуждать здесь нечего.
где?
Вот здесь, файл scrvar.cpp, например.
По поводу STL,
По поводу STL, видимо, мне придется подождать статьи
Будет, конечно. Пока не могу сказать, когда.
Я ж говорил, про переносимость на разные UNIX'ы (хотя бы) и на разные хардварные платформы.
В этом случае достаточно сделать обёртки для сисколлов. У меня вон для асма (!) в книжке приводится файл, позволяющий все примеры из книжки запускать на Linux и FreeBSD, хотя там разные конвенции.
Даже на линуксе x86 эти сисколы по разному делаются вроде (sysenter/syscall/int 80h)
Насколько я понимаю, sysenter не использовался никогда, а syscall стал использоваться на x86_64. При этом ядро благополучно продолжает поддерживать int 80h для сохранения совместимости с 32-битными бинарниками. Но это к делу не относится :-)
если вы собрались хардкодить линуксовые вызовы
Если под "хардкодить" понимается "делать вручную в каждом месте, где нужно обратиться к ядру", то это тупо неудобно, переносимость тут вообще ни при чём.
Я имел в виду несколько другое: Си вполне позволяет написать свои собственные обёртки для сисколлов и работать без стандартной библиотеки. И вот такую возможность я рассматриваю, да.
Я не специалист по libc -- можно ли примеры, ради интереса?
Да хоть бы тот же многострадальный signal. В ядре Linux этот сисколл есть и имеет семантику System V ("одноразовую"). В libc имеется одноимённая функция, реализованная через sigaction, и она долгое время демонстрировала семантику BSD; потом кому-то пришло в голову зачем-то ещё и SA_RESTART из неё взводить, что лично мне испортило песню: я студентов учил, что блокирующие системные вызовы при приходе сигнала вылетают с EINTR, что нужно учитывать, а ушлые студенты в какой-то момент мне продемонстрировали, что никто никуда уже не вылетает (хотя ещё недавно вылетало). А не далее как полгода назад у нас в терминальных классах обнаружилось, что дебианеры опять всё сломали и signal у них теперь снова в семантике System V.
Всё это время поведение _вызова_ signal оставалось абсолютно неизменным, только до него ещё поди доберись.
Возможно, это логично для какой-то конечной программы, но не для либы.
Для либы всё ещё проще: она соответствующий лимит должна получить от головной программы (например, как параметр функции инициализации, или что-нибудь ещё в таком духе), даже никакой конфигурационный файл не нужен.
Для либы всё
Для либы всё ещё проще: она соответствующий лимит должна получить от головной программы
Ну, честно говоря, не видел ни одной либы, которая бы принимала себе на вход такой параметр как "лимит памяти". Все известные мне либы, в которых есть параметр связанный с аллокациями, принимают на вход кастомный аллокатор (например, curl, zlib, openssl), что позволяет полностью управлять динамической памятью либы, в т.ч. ограничивать ее. В таком подходе либа обязана правильно обрабатывать ошибки аллокации. А т.к. такой подход похоже более общий, то нет причин использовать передачу лимита памяти (и придется считаться с тем, что аллокация может вернуть NULL).
И что? Какое
И что? Какое это всё имеет отношение к предмету обсуждения? Или вы тут вываливаете всё, что по ассоциации вспомнили?
Уж отчаялся
Уж отчаялся получить ответ:)
Если под "хардкодить" понимается "делать вручную в каждом месте, где нужно обратиться к ядру", то это тупо неудобно
Я имел ввиду, что где-то придется вшивать в бинарь OS specific инфу, типа "какой сискол надо позвать для вызова open если это Linux для ARMv7".
Я имел в виду несколько другое
Так а это и не особо важно с т.з. зрения переносимости. Здесь проблема в том, что я не могу просто так взять и скомпилировать сорцы под другую ОС/архитектуру, если использовать такой подход (вызов голых сисколов вместо функций из стандартной библиотеки). Ну то есть, вы же физически не учтете в своей "прокладке" те ОС и архитектуры которые еще не появились, т.е. потенциальным клиентам придется допиливать эту "прокладку". Конечно, это все можно вынести в stand-alone либу, но тут получается зависимость либы от либы, а подобные зависимости вам (да и мне тоже) не нравится. И это даже не учитывая всякие экзотические случаи типа cygwin'а (подозреваю, что там внутри libc'шных функций прямых сисколов вообще не происходит).
Да хоть бы тот же многострадальный signal.
Всё это время поведение _вызова_ signal оставалось абсолютно неизменным
Я если, честно такого сискола, как signal не нашел ни в Linux, ни во FreeBSD. Есть только sigaction, который вполне себе фиксированный. Т.е. если я ничего не упустил, то в данном контексте несчетовый пример: сискола такого нет, соответственно, переход на сисколы бы не решил проблемы (такого сискола же нет!). А если использовать переносимый sigaction, то проблемы бы не возникло.
я студентов учил, что блокирующие системные вызовы при приходе сигнала вылетают с EINTR, что нужно учитывать, а ушлые студенты в какой-то момент мне продемонстрировали, что никто никуда уже не вылетает
Подозреваю, что необходимость учета ошибки EINTR из системных функции не зависит от версии Debian в машзале:)
придется
придется вшивать в бинарь OS specific инфу
Не надо в неё ничего вшивать, бинарь сама по себе os-specific.
я не могу просто так взять и скомпилировать сорцы под другую ОС/архитектуру, если использовать такой подход
Условная компиляция поможет гиганту мысли
Я если, честно такого сискола, как signal не нашел
В Linux/i386 он имел номер 48, смотрите внимательнее. Правда, в x86_64 я его не вижу, видимо, всё-таки выкинули. Про FreeBSD не скажу, у меня её сейчас нет под рукой.
если использовать переносимый sigaction, то проблемы бы не возникло
Какой "проблемы"? Вы просили пример, я его привёл, ни о каких проблемах речи не шло. У меня вообще странное ощущение, что вы не помните, о чём сами же писали полтора поста назад. Ну так полистайте вверх и посмотрите. Про существование sigaction я, как можно догадаться, в курсе.
необходимость учета ошибки EINTR из системных функции не зависит от версии Debian в машзале
Студентам мало сказать, что вот так надо, а так не надо. Им ещё надо ответить на вопрос "почему". Иначе не поверят и правильно сделают.
Вот я им рассказал "почему", а они полезли проверять. И, опять же, правильно сделали, так и надо: многие вещи пока руками не потрогаешь, не поверишь. И -- упс -- всё оказалось не так.
HTTPS
Андрей Викторович, почему сайт не работает через https? Порт 443, насколько я вижу, закрыт. Просто потому что действительный сертификат стоит денег, или есть какие-либо другие причины?
Основная
Основная причина именно эта. Точнее говоря, сертификат не СТОИТ денег, за него ХОТЯТ денег. А стоить сгенерённые компьютером биты и байты не могут вообще нисколько, то есть принципиально — этим паразитам я не заплачу ни цента.
А стоить
А стоить сгенерённые компьютером биты и байты не могут вообще нисколько
Почему? Как минимум, они могут стоить сумме эквивалентной затратам на потраченное электричество для их генерации. Кроме того, сюда же можно включить выплаты программистам, которые написали программу для генерации. (Это я безотносительно центров сертификации рассуждаю).
Вот именно потому
Затраты электричества на генерацию одного сертификата — сумма настолько ничтожная, что о ней невозможно говорить всерьёз, это сотые доли цента. А вот идея выплат программистам как раз категорически неприемлема, собственно говоря, точно так же, как и в любых инициативных разработках, а равно и в других областях, где для этого пытаются применять так называемую "интеллектуальную собственность". В данном конкретном случае трудозатраты на создание программного обеспечения никак не связаны с количеством сертификатов, которые потом будут этим ПО сгенерированы. Следовательно, невозможно (вообще никак) связать стоимость сертификатов с зарплатой программистов, а все разговоры на эту тему представляют собой лишь прикрытие для откровенной торговли воздухом.
Вообще пора бы уже понять, что модель производственных отношений, заточенная под материальное производство, совершенно непригодна для случая "производства" информации.
Затраты
Затраты электричества на генерацию одного сертификата — сумма настолько ничтожная, что о ней невозможно говорить всерьёз, это сотые доли цента.
А вот идея выплат программистам как раз категорически неприемлема, собственно говоря, точно так же, как и в любых инициативных разработках, а равно и в других областях, где для этого пытаются применять так называемую "интеллектуальную собственность".
Так я же и написал в скобочках, что говорю это безотносительно центров сертификации. И про зарплату программистов тоже безотносительно этого. Пример несколько надуманный, но, допустим, кто-то хочет найти закрытый RSA ключ по открытому и для этого нанимает людей, платит им деньги за код/анализ, платит за электричество (большие деньги скорее всего), в итоге получает меньше килобайта информации за много денег. Разве и эти сгенеренные компьютером биты и байты тоже будут стоит нисколько?
А по поводу центров сертификации, хоть я и не имел с ними дела никогда, но, подозреваю, они берут деньги за подтверждение личности и траты своего времени на это, а не за генерацию цифроподписи к сертификату.
Пример
Пример несколько надуманный, но, допустим, кто-то хочет найти закрытый RSA ключ по открытому и для этого нанимает людей, платит им деньги за код/анализ, платит за электричество (большие деньги скорее всего), в итоге получает меньше килобайта информации за много денег
Это совершенно другой случай, потому что...
эти сгенеренные компьютером биты и байты
потому что эти биты и байты нельзя считать "сгенерёнными компьютером". Они получены в результате целенаправленной деятельности людей, которые использовали компьютеры, то есть их не компьютер сгенерил, их люди получили, и то, что они при этом пользовались компьютерами, никак сути не меняет.
Говоря про "сгенерённые компьютером биты и байты", я имел в виду такие биты и байты, которые сгенерированы компьютером по запросу без участия людей, то есть люди не тратят своё время на обслуживание отдельно взятого запроса. Если это не так, то есть если люди тратят своё время на обслуживание запроса, то стоимость таких битов и байтов будет определяться стоимостью трудозатрат. Собственно говоря, в мире есть всего две сущности, которые могут стоить денег: человеческое время (при условии, что оно потрачено не "вообще", а на обслуживание конкретного заказа; кто музыку заказывает, тот за неё и платит) и материальные (т.е. расходуемые) объекты. Электричество относится ко второй категории, то есть оно тоже стоит денег.
берут деньги за подтверждение личности и траты своего времени
Там не требуется подтверждать личность, к тому же в ряде стран "подтвердить личность" вообще практически невозможно ввиду отсутствия аналогов российских паспортов. Всё, что там требуется — это продемонстрировать свой контроль над доменом, это не требует вмешательства человека и траты человеческого времени.
Говоря про
Говоря про "сгенерённые компьютером биты и байты", я имел в виду такие биты и байты, которые сгенерированы компьютером по запросу без участия людей, то есть люди не тратят своё время на обслуживание отдельно взятого запроса.
Значит я вас не так понял:)
Всё, что там требуется — это продемонстрировать свой контроль над доменом, это не требует вмешательства человека и траты человеческого времени.
Ну, это жесть какая-то, действительно. Видимо, оплата за подобное пропадет из-за бесплатных сервисов, того же let's encrypt, предложенного выше.
Btw, на этом сайте похоже время спешит на час вперед (по крайней мере у меня в браузере так в таймстампах комментариев).
Про сертификаты
Так сейчас же появился свободный центр сертификации Let's encrypt, у них бесплатные сертификаты.
В принципе
В принципе штука любопытная, я про неё не знал, спасибо.
К сожалению, сходу ничего не вышло, там требуется клиент для ACME, и тот клиент, который они предлагают (certbot) написан на питоне. На моих серверах везде Opewall GNU/*/Linux, раскурить на нём питон в принципе можно (существуют пакеты от Гремлина и ещё от кого-то), но, откровенно говоря, лень, особенно если учесть, что результат далеко не всегда получается положительным, там постоянно вылезают трудности с библиотеками. Ещё два цента в мою копилку ненависти к развесистым интерпретируемым языкам.
Скорее всего, есть другие клиенты для этого ACME, прямо сейчас нет времени исследовать этот вопрос.
Список АСМЕ клиентов
Андрей Викторович, если вопрос получения сертификата для вас в какой-то момент станет шибко актуальным, то чтобы может сэкономить ваше время на поиски клиента для манипуляций с сертификатами этой конторы, вот их список на сайте самого проекта:
https://letsencrypt.org/docs/client-options/
Уже нашёл.
Уже нашёл. Осталось выбрать время и попробовать с этим что-то сделать.
Что почитать по С++
" ...буквально нечего было студентам ответить на вопрос "что почитать по C++""
Ирэ Пол. "Объектно-ориентированное программирование на языке С++", издание, которое существовало в 1997 году.
(В более поздних изданиях имя автора перевели как Айра Пол)
Выпускник ВМК,
преподавателя практикума (и С++) на 2 курсе - Т.В.Руденко вспоминаю с огромной благодарностью и уважением.
Ну, нынче год не тот
Если оно на русском было издано в 1997 или раньше, то на языке оригинала, скорее всего, вышло году этак в 1994. То есть до начала степановской эпохи.
Более поздние издания (которые как раз под именем "Айра Пол") я листал, не понравилось. Уже, к сожалению, не помню, чем конкретно не понравилось.
Тоже помню
Тоже помню этого автора, это издание. И тоже не понравилось. Правда, очень хорошо помню почему "конкретно". Препод у нас такой был - дяденька тихий, спокойный, весь из себя добродушный-добродушный, лекцию отчитает, что-то пробубнит себе под нос: "Книжечку посмотрите эту, эту... примерчики вот эти гляньте... эту еще книжечку... запишите, забудете..." Кто бы знал, записали бы! На зачете вроде тоже все хорошо, тихо, спокойно, вчистую зачеты вроде всем... За "маленьким" совсем исключением:
— Книжечку эту смотрели?
— Да!!!
— Примерчики эти делали?
— Конечно!!!
— Все получилось?
— Да!!!
— И на компьютере запускали?
— А то!!!
— Вот и славно, приходите через две недели...
Вот как раз и "примерчик" из этой самой "книжечки".
Уже при беглом взгляде видно, что одна из функций банально не дописана. То есть, программа не будет работать никак. И пример этот далеко не единственный. Типографии тогда работали просто жутко. Про переводы и говорить не приходится. Качество книг было совершенно отвратное. Вот этот наш "добродушный дяденька", оказавшийся на деле злым и коварным, этим и пользовался - говорят на такой ерунде полгруппы как-то завалил. Сейчас-то, даже весело, пожалуй, а тогда было не очень!
Правда потом (уже значительно позже), когда попалась подобная же типографская дребедень, уже даже интересно было привести ее к нормальному виду - не везде ошибки настолько тривиальные. Но - это было потом...
А чего вам не
А чего вам не нравится? Смотрю по тексту, там еще через пару примеров вводятся понятия дружественной функции и перегрузки операторов. В трех словах буквально. А далее пример, в котором помимо отсутствующей той же функции, ещё и новые косяки! Похоже, книжка просто исполнена ребусов - разбирайся, да исправляй! Хороший задачник! ;)
Можно
Можно бесконечно долго вспоминать книги, на которых учился - их у всех наберется немалая книжная полка. Конечно, их помнишь, как и преподавателей, которые чего-то тебе объясняли, благодаря которым ты на сегодня что-то знаешь. Но не будешь же предлагать нынешним студентам всю эту книжную полку! Хорошо бы ее представить в каком-нибудь очень конспективном, "квинтэссентивном" виде. Убрав лишнее. Книги по С++ вовсе не закончили еще писать и издавать, так что нынешние студенты свое еще огребут. Но на вопрос студента "что почитать" конкретно, указать на что-то пальцем в самом деле непросто. Как сказал поверху совсем уже нестуденческого возраста "Гриша" - это только если искать по ВУЗам методички. Похоже на истину. Действительно, их пишут люди, которые сегодня и сейчас обучают программированию. А здесь еще и целые книги издаются, не методички даже. Так что, на вопрос "что почитать", по мне - так уже есть куда показать пальцем. И думаю, что место это не единственное, хотя много их быть не может. Но поди найди, если даже на этот сайт, где издаются книги по программированию, я попал совершенно случайно, по какой-то совершенно серой, незаметной ссылке!
Есть такая проблема, да
попал совершенно случайно, по какой-то совершенно серой, незаметной ссылке!
Поскольку коммерцией я тут не занимаюсь, делать для своего сайта рекламу в традиционном формате мне кажется несколько нелепым, особенно если учесть моё хорошо известное отношение к рекламе как к явлению.
Так что мне остаётся надеяться на word of mouth, также известное как «сарафанное радио». С учётом этого я ценю любую ссылку, будь она сколь угодно серой и незаметной.
Книги ваши
Книги ваши прочитал. Отзывов положительных немало вижу. Действительно, есть нечто отличное, от того, что читал ранее. Да и движение какое-то чувствую!
А по каким книгам Вы сами учились? Какие могли бы порекомендовать? Интересует прежде всего С++. Литературы-то очень много, только всю подряд молотить - дело совсем неблагодарное, да и не думаю, что оно того стоит.
Иных уж нет, а те далече
Сам я учился программировать примерно в 1989--1993 гг. Это, понятное дело, был совсем другой мир. Цапнуть любую книжку, в которой хоть что-то полезное есть, и немедленно пробовать, пробовать, а вдруг получится, а компьютеров дома тогда ещё ни у кого не было (понятное дело, когда несчастная 286-я, уже тогда безнадёжно устаревшая, стоила как два автомобиля), поди урви себе пару часов машинного времени, ещё и не сразу найдёшь.
Большую часть книг, которые я тогда прочитал, я уже просто не помню, то есть помню, как выглядели, о чём там было написано, но не помню ни авторов, ни заглавий. Да и не интересны они сейчас. Вот разве что помню, по какой книге изучал C++, тут всё просто: по второму изданию Страуструпа. Это такой двухтомничек был не шибко большого формата, кстати, если попадётся — готов купить за любые разумные деньги, чисто для коллекции. (UPD: всё, неактуально, нашёл :-))
Ну а из того, что сейчас есть... э... у меня в книжках есть небольшие списки литературы, и даже эти книги я не все готов именно что рекомендовать к прочтению. Того же Танненбаума упоминаю просто по принципу "если очень хочется, то вам туда".
Second Edition
Андрей Викторович, а как Вы, интересно, поступите, если к Вам на экзамен заявится скандинавской наружности лысый очкастый вьюнош и со знанием дела начнет излагать примерно следующее:
"Парадигмы программирования. Объектно-ориентированное программирование - это метод программирования, способ написания "хороших" программ для множества задач. Если этот термин имеет какой-то смысл, то он должен подразумевать: такой язык программирования, который представляет хорошие возможности для объектно-ориентированного стиля программирования..."
Извольте видеть - второе издание! Типа, собралась расширить чисто сишный кругозор...
Во как :)
Довольно косноязычный перевод, мне почему-то казалось, что тот, который я когда-то читал, не отличался таким косноязычием. Ну хотя давно дело было.
Про парадигмы и их соотношение с языком программирования можно говорить более детально, я в своём курсе, который так и называется "Парадигмы программирования", привожу семь различных уровней. Да и не такая уж это "пустая трата сил", во всяком случае ООП на чистом Си (с ручным выписыванием таблиц виртуальных функций, например) -- это то, как написано ядро Linux.
То, что перевод
То, что перевод был абсолютно тот же самый, можно даже не сомневаться. Правда, англоязычного исходника я не нашел - везде только 3-е и 4-е издание, а там несколько все иначе написано, но несколько русскоязычных переводов дают тот же самый текст. Думаю, что если бы на сегодня Андрей Викторович взяли эту книгу (впервые!), да увидели это безобразие, эффект мог бы быть довольно интересным! :) Но это сейчас он дважды кандидат с доцентом, а когда он читал эту книжку именно впервые, он еще студентом был, если вообще не пионером. Тогда, очевидно, и подходы, и цели были несколько другие. Но однозначно - это перевод. Такую байду даже в детском саду услышать сложно.
Но такой подход, как у Ольги - посмотреть, нарваться на паршивый перевод, плюнуть, да сказать, что "мне и в Си хорошо", может, не самый лучший. Все-таки "плюсы" не просто так появились, не просто так на них люди пишут. Кстати, не только профессионалы! Кто-то тут на странице с обсуждением двухтомника упоминал об интерпретаторе ROOT, разработанном и используемом в CERN'е (называйте его просто - центр ядерных исследований!;)). Так используют его именно пользователи - всякие математики, физики - им, вообще говоря, по барабану, что Python какой-нибудь выучить (который с точки зрения программиста подходил бы к задаче больше), что "плюсы" - образование, работа, вытекающая оттуда системность мышления... Ну, чего от них еще ожидать-то, от этих математиков, да физиков? :) Вот башка у них так заточена - потому и используют и "плюсы", и STL, и все что хочешь для своих нужд! И в интерпретируемом варианте, до кучи. Сам же процесс программирования для них глубоко побочный - вычисляют там чем-то, рисуют-визуализируют... На чем они это делают - им все равно, у них другие проблемы. Даже тут уже видно, что С++ для чего-то все-таки нужен.
Так что, с точки зрения "расширения сишного кругозора", возможно, следовало взять для начала не Страуструпа (тем более, с такими горбушками в переводе), а нечто более описательное - любой учебник по "плюсам". И на английском. Во избежание. Уж этого-то - как грязи! Вот, к примеру, вполне подходящая для такой цели книжка. С десяток тычков в Гугле. Обращено внимание лишь на год (2002), чтоб не сильно остандарчено было, да на сам текст - чтобы не носитель писал. По языковой "бедности" изложения это обычно хорошо видно. А то, попадутся такие, что идиоматов на полстраницы натолкают, еще и не каждый переводчик без стакана разберется, какого-нибудь специалиста филолога звать придется... Книжку по программированию, называется, взял! :)
Простейшее совершенно описание языка на элементарных примерах. Страниц под тысячу, но для "сишника" - это неделя максимум. Не исключено, что где-то зацепишься за кусок кода, который "вдруг" захочется куда-то запихать, мысль какая-то появится. А вот тогда уже придется вернуться к Страуструпу, несмотря на горбушки в переводе, или взяв более позднее издание (кстати, можно уже и на русском - качество переводов за последние годы стало куда выше, чем в начале века - там вообще беда была с этим!). Примерно таков может быть путь. По любому повеселее, что плюнуть на это мутное дело из-за плохого перевода и продолжать смотреть на "плюсы" сверху вниз. Есть в них что-то, есть...
Э-мммм, всяк кулик своё болото...
...вот и я, пожалуй, обращу внимание почтеннейшей публики на свою книжку по C++. Чуть больше 120 страниц. Если речь идёт о том, чтобы понять, чем C++ отличается от чистого Си и зачем это всё надо — imho в самый раз. Написана она была, как обычно, от безысходности — ну вот буквально нечего было студентам ответить на вопрос "что почитать по C++".
Текст этой книжки планируется сделать первой частью четвёртого тома, но это будет, скорее всего, где-то через год, так что ждать не обязательно, благо книжка в электронном виде доступна, пользуйтесь на здоровье.
Все бы так
Все бы так писали "от безысходности"! Очень даже приличный учебник.
Тем более, что ориентирован он именно на "сишников", а не как это обычно водится, неизвестно на кого. У "сишника" (даже со стажем в год - это уже программист) возникают сто раз уже наблюдаемые мною проблемы - поскольку это УЖЕ программист, то уже и имеет некоторые свойственные мышлению черты. Прежде всего, для него важна последовательность изложения. Галопом по европам он скакать не будет. Поэтому даже корявый перевод (буквально в одном месте) - далеко ходить не надо! - вызывает негативную реакцию и остановку. Более того, возможно, на долгие годы очень подозрительный взгляд в сторону С++. Плюс, как УЖЕ программисту, необходимо при решении задачи (в том числе задачи обучения) видеть картину целиком. Какое там "целиком" может быть в случае языка С++, если на сегодня он, мало того, что уже представляет собой большое многоэтажное здание, еще и каждые три года изменяется-дополняется "стандартами"? Думаю, относительно необходимости таких "изменений-дополнений" ни у кого никаких иллюзий не возникает. Кстати, боюсь, что последний стандарт и сам Страуструп не знает, хотя он имеет все же еще некоторое отношение к языку С++. Так что, созданный чуть выше анекдотичный образ студента Страуструпа на экзамене можно легко развить:
— Студент Страуструп, назовите основные, наиболее важные изменения в языке, которые произошли с введением стандарта С++ 2023?
— Э...М-ммм...
— Студент Страуструп, как вы собираетесь учиться дальше?! Мы со следующего семестра приступаем к изучению таких книг, как "The C++ Programming Language", "The Design and Evolution of C++". Что вы сможете там понять? Если вам незнакомы самые элементарные, самые основополагающие вещи!
Фактически, на сегодня Страуструп стал просто придатком комитетов по стандартам С++, которые книжки-то свои, похоже, издает-переиздает именно по договорам с этими комитетами, в качестве рекламы грядущего стандарта. Т.е. по сути некогда самостоятельный и толковый человек был сожран этими самыми комитетами. Как он сам себя чувствует в связи с этим, сказать сложно. Впрочем, это уже совсем другая история!
Что касается "Введения в С++", то думаю, что многие из тех, кто вообще попадал на сайт, ее безусловно видели. Книжки-то все в одном месте! По любому, в авторском "Введении в С++" есть помимо четкой целевой направленности ("сишник"), еще и некоторое описанное подмножество языка С++, которое можно бы попробовать использовать именно "сишнику" с целью определения "а не может ли мне чего из этого пригодиться". И совершенно не исключено, что что-то вполне "может"! Ну, а дальше - это самое многоэтажное, многостандартное и многострадальное здание С++. На все ли этажи заходить - дело хозяйское, но и не дети ведь уже! Си - это очень даже приличная подготовка. Короче, лиха беда начало...
Ну, а по поводу "безысходности"... Будет настроение или состояние, близкое к "безысходному", Вы пишите, Андрей Викторович, пишите. А люди разберутся! :) Кстати, сам факт, что разогнав больше половины возможных читателей, да отплевавшись от предложений разместить лекции на ютубах (популяризация, реклама, однако!), удается еще собирать какие-то деньги на типографии, да издавать книги - это уже чудом попахивает! Так что, "безысходность" - это не для всех плохо...
120 страниц
120 страниц, и очень даже хорошо! Куда больше? Основы языка даны? Даны. Чего еще-то? Именно язык и может вызывать сложности - там немало нового по сравнению с Си. Концептуально. А библиотеки - они и в Африке библиотеки, если язык знаешь, какие проблемы? Тем более, что не обязательно это стандартные библиотеки. Это может быть и Qt, и U++, и тот же ROOT. И все разные! А язык в основе своей везде один. Так что, это куда лучше, чем долбать толстенный учебник, нацеленный именно на стандартные "плюсы". Ну, а то, что язык в принципе не должен бы включать каких бы то ни было библиотек - это само собой, просто в случае С++ на это можно давно уже плюнуть и позабыть :) Хотя, понимать это надо и осложнять себе жизнь толстенными учебниками без необходимости вовсе ни к чему. Есть короткий, толковый учебник по языку - и зашибись! Понадобится чего-то еще (скорее всего, библиотеки) - доберешь по ходу пьесы, не маленький...
Да, 120 страниц.
Кстати, по-моему, единственная книжка, в которой даже iostream отсутствует.
То есть, декларируется исходно - ИЗУЧАЕМ ЯЗЫК! Помнится, в целях оказания помощи младшим товарищам, я пытался определить для них последовательность изучения С++, зачеркивая фломастером в Шилдте то, что к языку не относится. Оставлял то, что должно быть понято в первую очередь. Просто брал на их глазах и зачирикивал целые страницы. Ну, очень грубо, конечно, получилось... Но они поняли! У них до этого момента был какой-то барьер при подходе к С++. Ничуть не способствовал его преодолению размер книжки Шилдта. А ведь по сравнению с тем, что можно увидеть сейчас - это не такая уж большая книжка. И тем не менее, барьер был! И он ушел. Люди поняли принципиальную последовательность изучения (начиная именно с языка!), и пошел нормальный процесс обучения. Сами, естественно, читали/разбирались, я не препод. Гавкнуть могу разок, когда вижу что людей откровенно не туда несет, но люди взрослые уже, и читать умеют сами. Да, в языке для сишника проблемы быть могут, концепции для него новые. Но и запредельно сложного ничего нет. Особенно, если не брать громадный учебник, паря себе же мозги.
А вот во "Введении в С++" Столярова уже все зачирикано. Причем с чувством, с толком, с расстановкой. Препод же! Его цель - именно научить. И не понимать нужную последовательность обучения он просто не может. Потому нету даже iostream. При чем здесь iostream? Вот, коли напомнили про Qt с UPP - именно сейчас ваяю небольшую приблуду на UPP. Нужно элементарно вывести в консоль отладочную запись. Попробуем "cout"? Ошибка! Извольте писать "Cout". С большой буквы. Другой iostream. И в кьюте все иначе. И другие библиотеки STL. Свои библиотеки. Хотя, к ним относится все то, что можно сказать про STL - использовать никто не запрещает, разумеется, но без них - будет эффективней. Это большие фреймворки, там все свое. Быть может, я сейчас пишу не на С++? На чем-то другом? Ну, можно сказать, что на "нестандартном С++". Что это меняет? Язык-то тот же! Тот самый, который описан во "Введении в С++". Причем, коротко, четко и ясно. Без лишних нахлобучек.
В общем, "Введение в С++" - хороший стартовый учебник. Останется немногое - взять свой последний купленный, тяжеленный и с трудом донесенный до дома учебник по "плюсам", отыскать его автора, затолкать этот учебник по его прямому назначению, и все - весь С++ у вас как на ладони! :)
Ого!
Вот это нонича цены на стандарты! $212 — членам, $265 — не-членам.
По памяти, вроде, полтинник было. Но то ли давно не заходил, то ли овес нынче дорог.
Конечно, вопрос стандартизаций — это прежде всего, вопрос денег. Так было всегда. Кстати, и время для первых атак стандартизаторов на язык было выбрано очень удачно — конец прошлого, самое начало этого века, время, когда поднималась Java ("Написанное однажды — работает везде" — лозунг очень мощный!), время, когда много известных, авторитетных весьма программистов полностью ушли в Java. Сообщество было ослаблено. Так что, произнесенное где-то выше "профсоюз программистов ниже среднего уровня" применительно к стандарту 2003 года имеет под собой вполне реальную основу. А такие настроения, как "еще год-два, и все, абсолютно все будут писать на Java" в начале века были действительно очень популярны. Очевидно, что сбыться этому было никак не суждено. Но настроения такие были.
Что касается Страуструпа, то ничуть его не жалко, как бы он там себя ни чувствовал — пусть даже разгул стандартизаторов станет его личной трагедией, виноват он сам. Да, на сегодня он просто придаток стандартов, не больше. Просто картинка на упаковке. Но они же почти одного возраста с хайрастым и бородатым Столлманом! Сколько тот орал о собственности, о лицензировании? И на сегодня попробуй срубить бабла на чем-нибудь GNU-том, воткнув хотя бы маленький кусочек кода в какой-нибудь закрытый коммерческий проект! А Страуструп как в другом мире жил! Столлман это же не какой-то классово-чуждый элемент для Страуструпа — такой же программист, из страны вполне демократической, а вовсе не какой-то герой-комсомолец с горящими глазами, ратующий "за обчественность" на общественных же началах из советской литературы. Первые версии emacs, кстати, по триста баксов уходили, хоть и по большей части платилось за доставку — по тем временам совсем немало. То есть, прислушаться к нему Страуструп вполне мог, не просто же так тот распинался! Дело по большей части именно в этом. Отпустил вожжи Страуструп. Вот зачем? В Perl, Python — лицензии ведь есть? Для человека незнакомого совершенно с тем как живут и мыслят эти самые по Задорнову "ну тупы-ы-ые", они просто смешны. Однако, именно благодаря им ни в Perl, ни в Python ни одна мышь в языке и пукнуть не посмеет без ведома Larry и Guido. А здесь — стандарт за стандартом! И если это дело нравится Страуструпу, то с четверть века назад я его представлял себе несколько другим. Но все возможно, конечно... Остается лишь радоваться, что дело это не затрагивает язык Си. А могло вполне! Просто "младший брат" прикрыл грудью. Может, именно в этом его историческая миссия. Стандартных "нововведений" в Си не так уж много. Из откровенно непристойных только переменные массивы вспоминаются. Видать, кто-то из стандартизаторов сподобился изучить Бейсик. А скорее просто оператор REDIM. Честь ему и хвала, конечно, и большое человеческое спасибо за то, что на этом остановился.
Относительно же "Введения в С++" — да, написано хорошо и полезно. Более десяти лет, правда, не заходил в российские книжные магазины, но практически уверен, что ничего нового, касаемо программирования, там появиться не могло — в сети бы появилось. Это только по вузам если выискивать-вылавливать какие-то методички, это еще возможно, с тиражом сто штук на круг. А в магазинах кроме откровенной макулатуры, из которой в лучшем случае можно что-то выдирать поабзацно, сроду ничего не видел. А уж тем более, ожидать нечто целостного, что можно на полном серьезе воспринимать как учебник, не приходится никак. Здесь же, как раз, имеется некое последовательное изложение. Причем очень короткое (менее 150 страниц — это учебник по "плюсам", где вы такое видели?) и ненапряжное. Которое стопроцентно может быть понято человеком, владеющим Си. Даются именно те основы, которые являются принципиально необходимыми. И славно! Толстенный учебник, в который заталкивают все, что можно (уж кто во что горазд!) оптимизм вряд ли у кого вызовет. Да это и не нужно вовсе! В то же время этих полутора сотен страниц вполне достаточно чтобы начать переделывать свои же программы на Си. Пожалуй, это лучший способ разобраться с С++. Заодно выработается обычная совершенно способность для людей пишущих как на Си, так и на С++ легко переключаться между взглядом на программу с точки зрения Си и "плюсовой" точкой зрения. Она действительно совершенно обычная. А расхожий штамп, идущий от Страуструпа, что человеку, хорошо знающему Си, сложнее обучиться С++ ничего реального под собой не имеет. Скажем так, "неаккуратно человек выразился". То, что сам ход мышления на этих двух языках несколько отличается, так это понятно каждому, кто прочитал с десяток страниц любого совершенно учебника. Но никаких фатальных последствий для знатоков Си, разумеется, нет. Имхо. Правда, как ни крути, знание Си, все же, обязательно — это уже не "имхо", это даже и не смешите! Иначе... короче, даже и не смешите. Так что, книжка вполне, и как раз. Отписываться, впрочем, в обсуждении не стал, "имеющий глаза, да увидит". Да это и не удивляет особо — если человек 74-го года, пусть даже в 20 лет начал учиться программировать, то он в любом случае попадает на еще достандартный С++. То есть, по возрасту никак не относится к тому пионерскому отряду, место которому уже заботливо подготовлено Майкрософт — резервация .NET. Ведь какую бы систему лично не предпочитали представители этого пионерского отряда, деньги зарабатывать в качестве программистов им, скорее всего, придется, именно под Windows. А Майкрософт уже лет десять как целенаправленно выбивает из Windows программистов на С++. Самыми разными методами. Так что, точка зрения Столярова, что учиться программированию надо не под Windows, совпадает полностью с точкой зрения Майкрософт (в части языка С++). Хоть и по разным причинам — первый Windows вообще, похоже, за систему не держит, что же касается второй, то их цель предельно простая — оставить С++, как системный язык, лишь для программистов Майкрософт, всех же остальных — засунуть под .NET. Что ж, логика ясна как день — безопасность системы. Пущай делают чего хотят под виртуальной машиной, а в систему — ни-ни!
Как-то зашел на эту страницу, пробежался сверху, почему-то начало века вспомнилось, время для меня значительно более активное, нежели сейчас, потому и отписался несколько больше, чем предполагал. В Питере еще жил, говорил и читал по-русски, нечто ностальгическое просто... В любом случае, автору удачи пожелаю — "Написанное хорошо, читают всегда". А научить-объяснить вряд ли проще, чем самому что-то придумать. Во всяком случае, изобретают-придумывают что-то новое куда чаще, чем появляются люди, которые в состоянии это новое толково объяснить. Хоть и стоять на крайних точках зрения и переть против течения более характерно лет для 20, когда 40 — не уверен. Впрочем, каждому — свое. Мне-то уже еще на 20 больше, может, и в этом дело. Но, как бы то ни было — удачи.
А вдруг...
Здравствуйте, Андрей Викторович!
Вопрос, быть может, не совсем корректный, не знаю... А может, даже и не вопрос...
Книги ваши читал, некоторую дополнительную информацию выдал этот форум. Однако, досадно временами, что нигде и никогда не встречалось ваших лекций - именно тех, что читаются вживую. Книги-то вы издаете? И вовсе не "банального прибытку" ради, как вижу. А вот живые лекции почему-то отсутствуют! Хотя, по жизни, текста в них ничуть не меньше, а толку (пусть даже со всеми отклонениями от темы) еще и поболе будет! Уж если даете возможность людям учиться по книгам, и неплохим книгам - скажем, общее количество книг от "сиплюспюс-донцовых" (думаю, термин ясен!) уже давно превышает общее количество "донцовых литературных", что те, что другие не тянут даже на подставку для чайника, а вот по вашим - учиться вполне можно! И по комментам вижу, что я не одинок в своей точке зрения. Так почему бы и живые лекции не издать, не распространить? Ну, или хотя бы дайте какую-нибудь (пусть профессионально в будущем никчемную), но аккуратную студентку, которая записывать умеет, пусть даже не понимая что! Повеселее было бы всяко... Не все же в Москве живут, да учатся! Это может на частных уроках какие тайные знания/откровения, а то, что по любому в аудитории-то звучит...
Город у нас немаленький, ВУЗов хватает, и тем не менее. Было тут вообще пожелание обратиться к Столярову с затеей откомментировать построчно последнее издание Страуструпа - жанр-то, редчайший, умер, фактически, не родившись в средние века. В основном, "комментировали" Аристотеля (а кто такому суровому дядьке перечить будет? Потому и шли в основном упрощающие понимание комменты), но здесь-то всяко пошире поле деятельности! Ну, об этом только помечтать... А в лекциях-то сложного ведь ничего нет? Хороший, нечасто встречающийся материал и лишь для нескольких десятков человек! Мрак, короче...
Живые лекции?
Как вы себе это представляете?
Конспекты своих лекций, даже написанные студентками-отличницами, я неоднократно видел — это просто ужоснах и триллер. То есть от лекции как таковой не остаётся вообще ничего. Видео всякое я считал и считаю суррогатом и самообманом.
Мне известен только один способ доступа к "живой лекции" — находиться в аудитории во время её чтения. Никаких других способов лично я не знаю.
Да, тут был
Да, тут был мимоходом в Москве, тоже была идея заехать, да послушать Столярова "вживую"! :)
Прежде всего, потому, что где-то в сети встречалось описание манеры его преподавания. Своеобразно и весело написано, похоже, действительно, есть на что глянуть, что послушать. В частности, так славно описывались децибелы голоса, что послушать бы неплохо, конечно... Впрочем, идея эта была не настолько серьезна, как у Анонимуса с постом №73. Разумеется, были и более серьезные дела, да и попасть на лекцию в один день в конкретный ВУЗ - это же как подгадать надо!
Что касается видео, то - да, неплохо бы. Однако, вопрос уже этот задавался, и однозначный ответ был дан. И спорить тут, очевидно, бесполезно - "суррогат", и все тут! :) Ну, а лекции "девочек-отличниц", конечно, никакой критики не держат - ведь то, что в книге, самим автором вычитывается и правится десятки и сотни раз, чего тут можно ожидать от какой-то девочки, сидящей на лекции?! Конечно, триллер...
Мне единственное что по тексту Анонимуса показалось, что это явный студент, которому понравилась ПОНЯТНОСТЬ изложения и который бы хотел получать такое же ПОНЯТНОЕ изложение дальше. Спору нет, подобная ПОНЯТНОСТЬ - вещь, действительно, редкая. И она обращает на себя внимание. И дано сие не всем. И связана она, похоже, вовсе даже не с предыдушим опытом программирования автора, с чем-то другим... Дело лишь в том, что никакой Столяров на ВСЕ ВОПРОСЫ ответы не даст. Самому постараться придется. Вот вижу написано - "книги ваши читал". И чего? Допустим, в первом томе очень даже ПОНЯТНО описаны некоторые структуры данных. Действительно, очень ПОНЯТНО, мне тоже очень понравилось. На примере Паскаля. А на сях делал? Смотрел? А на плюсах? А как это в STL? Или "сам сказал", что STL - это бяка? А может, врет! Почему нет? Взял, да посмотрел - как оно... Вот это и есть самая настоящая "живая лекция"! :) Замечу, что в обсуждении книги не один человек (и это совсем не новички "хэлловорлдные"), уже по коду в самых маленьких программах видно, САМИ что-то смотрят, ставят вопросы, ищут ответы, находят, интересуются точкой зрения... Вот это и есть опять же "живая лекция"! Люди сами учатся. Кстати, Столяров тоже учиться не прекращал - в этом можно не сомневаться...
Не в огорчение, студент - даже если в каждую аудиторию вашего ВУЗА запихать по столярову, умеющему объяснять ПОНЯТНО, то без самостоятельной работы (чисто в расчете на столяровых), как пришел на первый курс идиотом, так и останешься им на пятом! А диплом - это бумажка, сам по себе, от идиотизма никого и никогда не спасал!
Впрочем, надо отметить еще и такой момент - как бы Андрей Викторович не упирались с видеолекциями, а популярность однако растет без всяких ютубов - чего стоит одно предложение целую книгу Страуструпа откомментировать! :) А ведь личный сайт незаметный совсем! Да и тиражи изданных книг не поражают воображение - поди, найди в магазинах! И тем не менее...
Из того, что
Из того, что человек интересуется видеолекциями, еще не вытекает, что он студент.
Например (специально порыла), вижу что кроме меня до №73 никто видеолекциями не интересовался. И именно мне был дан ответ о "суррогатности" и "самообманности" последних. Хотя, я уже не студентка вовсе.
Ну, а по поводу самостоятельной работы само собой! Институт в принципе и должен научить работать самостоятельно. Это лишь самое начало обучения, которое потом продолжается всю оставшуюся жизнь. Дело, разумеется, не в аспирантурах, ученых степенях и званиях (тут особый разговор, здесь надо немного представлять себе кухню на кафедрах ВУЗов - а она довольно специфичная!), просто существование человека после ВУЗа немыслимо без дальнейшего постоянного обучения, совершенствования собственных навыков в профессии. Иначе, человек просто зря учился - его не научили учиться, он просто зря потратил время. И таких навалом - вроде, отучился, а работает каким-нибудь манагером, продавая коврики для кошек... Кстати, о "кухне"! ))) Недавно совершенно встретила однокурсника, профессором стал. И настолько его образ, создавшийся за годы обучения не вязался со словом "профессор", что первые секунды была просто в шоке. Правда, чуть пообщавшись с ним, с мыслью "я вас умоляю!", поняла, что за прошедшие годы не изменилось ровным счетом ничего! И такого сколько хочешь... В общем, под обучением понимается просто процесс самостоятельной работы.
Что же касается именно видеолекций, оно, конечно, хотелось бы, просто не худо себе представлять, что одно дело пользователям отыскать где-нибудь на ютубе нечто сообразное, а другое совершенно самому автору разместить там же свои же лекции. Не то чтобы это совсем уж себя не уважать - люди-то и на ютубе разные, просто припоминая контент, который можно выудить по запросу, скажем, "С++", это все же, в изрядной степени, искупаться в дерьме. Так что, дело здесь не совсем в том, что лекция, записанная на видео совсем ничего уж не несет. Нести, она в любом случае несет. Дело не в том.
В общем, книжки есть - читаем! По этим "началам программирования" с учетом самостоятельной работы, вполне можно получить приличный средний уровень. Не случайно, думаю, в обсуждении двухтомника откровенных новичков не видно. У всех отписавшихся самые "начальные" навыки уже есть. А они, тем не менее, читают почему-то "Введение в профессию". А некоторые из моих знакомых, так и вообще в РЕФАЛ полезли, да в InteLib'ы всякие - за 10-15 лет, конечно, многое изменилось, но и в древних манускриптах, видать, что-то интересное от автора отыскать можно.
Вообще, в разное время отслеживались сайты, на которые вполне реально можно послать обучающихся программированию. Это был когда-то и сайт разработчиков PascalABC (ныне - ABC.NET - совсем уж не та балалайка), и питерского препода Полякова (только с С++ и школьниками он всяко погорячился - даже уровень абстракции там явно не по возрасту, но информация полезная была), из Сибири кое-кто был... В общем, немного совсем. А на сегодня только если сюда отослать, больше некуда!
Две большие разницы
Что касается учителя Полякова, то это не совсем "обучение программированию". Здесь две большие разницы - то, чему он учит, входит в область "общих знаний". Что, собственно, и должна давать школа. Всё, что касается информатики - это у них обязательные предметы. Потому и отношение школьников к этим предметам самое, что ни на есть обычное. Зачастую дофенистическое. Слов нет, если из них кто-то продолжит обучение по тому же направлению, ему будет проще. Но выход там будущих программистов не более, чем из школ с математическим уклоном математиков. То есть, один на несколько выпусков. Хотя, общая грамотность у них, конечно, повыше. Не случайно Поляков "заслуженный учитель". Но факт остается фактом - реальный выход небольшой. Даже несмотря на то, что люди вообще и школьники в частности стали значительно более прагматичны с тех пор, как я заканчивала школу, о выборе профессии в школе даже и речи быть не может.
А у Столярова направленность именно на человека, который сознательно выбрал профессию и по ней учится. Это уже студенты. Другая возрастная категория. Именно поэтому поляковские книжки вполне можно читать, а столяровские нужно отрабатывать. Два неплохих преподавателя, но у них совершенно разные цели. И то, что у Полякова контингент учащихся несколько мифологический - ну, не потянет школьник многие из тем, которые он вещает, совершенно однозначно. Тем не менее, и плохого ничего нет. Но это, всё же, не "обучение программированию".
Насмешили!
Какие "видеолекции", вы о чём? :) Вот этого уж никак ожидать не приходится!
Книжки откройте ещё разок, просмотрите. По форуму пробегитесь. Для кого написано? Для всех ли? В это сложно поверить, но даже на сегодня существует куча людей (в том числе программистов), которые ни разу в жизни не ставили nix'ы ни в каком виде. Ни разу! Можно посочувствовать, конечно, но факт остаётся фактом — они из потенциальных читателей выпадают однозначно. Грубо — половину "всех" уже выкинули. Можно ли подготовить программиста под Windows? Ну, разумеется! Как и под любой другой системой. Но здесь-то постановка чёткая — nix'ы, и никак иначе! Итак, половины уже нет.
Идём дальше. Точку зрения про STL, про стандарты все видели? Наверно, не был бы столь категоричен, но основания для отрицания "стандартных нововведений" безусловно есть. Стандартно-разжиревший С++, например, позволяет писать откровенно неприличный код. Откровенным дуракам. И они его пишут! Кстати, если по совести, то всегда казалось, что разработка стандарта 2003 года (просто за обсуждением и подготовкой этого стандарта ещё следил) вообще имела целью создание "профсоюза программистов среднего и ниже среднего уровня". То есть, под отрицанием STL (Столяров здесь, кстати, вовсе не одинок) неплохо бы понимать просто неприятие халтуры, уважение к себе, к собственному коду. И существует немало людей, которые используют подмножество С++, не включающее STL. Но сколько народу выкинем дополнительно, безусловно о ней возрыдающих? ;) Сколько осталось?
Ну, а теперь прикинем расклад стандартной студенческой группы, присутствующей обычно на лекции. Сколько человек в принципе пригодны для обучения? Тех, которые обладают нужным для конкретного преподавателя объёмом знаний, способностями, возможно, некоторым сходством понятий. Пять! Если десять — это очень сильная группа. Можно сказать, "повезло". Хотя, это "везение" принесёт с собой и больший объём работы. Оставшийся контингент интересует обычно не более, чем прошлогодний снег в Зимбабве. Да и вообще, "народнохозяйственное значение" подготовленных специалистов вряд ли кого интересовало даже в советские времена. Некоторое значение оно, конечно, имеет, как показатель успешности собственной преподавательской деятельности, но в основном, преподавание — это просто самовыражение, утверждение собственной точки зрения — "как оно должно быть".
Так и если хотя бы частично признать правоту того, что написано оно и преподаётся оно не для всех (а в случае Столярова это особенно заметно), для кого он будет записывать видеолекции? Тем более, что они неминуемо попадут на какой-нибудь ютуб, а это, как совершенно справедливо замечено, означает "искупаться в дерьме"? Ну, разумеется, на ютубе можно отыскать очень даже приличные лекции, они есть, но готовы "искупаться", всё же, не все! ;) Как-то так...
Вопрос по оконному менеджеру fvwn2
Андрей Викторович, здравствуйте.
Хочу задать вопрос по оконному менеджеру fvwn.
Несколько месяцев являюсь пользователем Линукс. На основном компьютере установлена Mint, благо производительности машины хватает.
На второй машине (небтуке, у которого оперативная память всего гигабайт) иногда "подтормаживают" даже kubuntu и lubuntu.
В вашей книге прочитал про оконный менеджер fvwn2, хочу попробовать установить его на нетбуке, чтобы еще чуть повысить производительность.
Данный менеджер, как я понял, требует серьезной кастомизации. Можете порекомендовать какие-нибудь материалы по первым шагам в работе с этим менеджером? Попытки чтения мануалов (на языке оригинала) даются тяжеловато...
Поставьте IceWM
Поставьте IceWM :-)
Что касается fvwm2, то я его всю жизнь настраивал "по аналогии", там с ним идёт образец конфига, из которого более-менее всё понятно. Начать с ним работу можно и без кастомизации. Иной вопрос, что, пожалуй, это всё-таки не очень хорошая идея. Для меня fvwm2 -- дело привычки, но у вас-то привычек таких нет.
Да, рабочий
Да, рабочий стол - это дело привычки. Помнится, когда-то меня вполне устраивали вторые "кеды". Но когда они подросли на размерчик, я сместился на тогдашний Gnome. Правда, когда и он дорос до "gnome 3", вынужден был уже перейти на xfce, где сейчас и пребываю. И пока доволен. Единственное, что смущает, так это возможные перспективы его "развития" в сторону вещей, которые (по возможности) будут все равно отключаться, что опять же может привести к изменению привычек. При всем при этом, я бы не сказал, что у меня машина слабая.
Это я к тому, что в линуксах тоже далеко не все так безоблачно.
Гыгыгы
Поставьте IceWM :-)
What about D language?
Если возможно, хотя бы одним словом...
Одним словом не могу
Одним словом у меня не получится, могу вот тремя: "чёрт его знает" :-)
Ага!
Что ж, спасибо! Тогда займёмся. Мнение важно.
Программистом быть, конечно, неплохо, но быть чёртом... Ещё заманчивей! :)
Нет, всё же, не "ага"!
Передумал я быть чёртом.
Две недели ушло на чтение Александреску вперемешку с каким-то турком. В результате написанные тестовые программки по размеру (в десятки и сотни раз, как ни старайся) оказались больше, чем аналоги на Си. Скорость исполнения в разы ниже. Если в этом самом "D" понаотключать всё подряд, то, может, дела будут обстоять и получше. Но уж системным языком D я назвать бы не решился никак! Короче, не торт. Каждому своё, конечно, но для меня это было просто даром потраченное время.
Желанный Язык
Здравствуйте!
Очень интересует ваше мнение!
Представьте себе язык программирования на котором бы вам хотелось писать, такой что бы некоторый круг задач решался бы на нем наиболее эффективно по параметрам:
- скорости решения/написания, т.е. времени которое будет потрачено программистом,
- легкости, т.е. умственных усилий которые будут потрачены программистом,
- дизайн ориентированный на избавление от избыточной сложности,
- размера получаемых программ,
- размера используемой памяти при выполнении,
- скорости выполнения,
- пригодности и для системного программирования (например путем описания упрощенного подмножества)
- пригодности и для самого высокоуровнего программирования (например путем описания надмножества языка, даже допускаю введение раздельных режимов компиляции для любого модуля, т.е. модуль на низко или высоко уровневом подмножестве языка может быть написан и соответственно скомпилирован),
- созданы все условия для надежного и безопасного программирования.
И во вторую очередь, что бы этот круг задач которые решаются эффективно - был бы как можно больше.
Является ли вопрос синтаксиса для построения такого языка, - достаточно ключевым? Что бы и программист легко мог не только освоить такой язык, но и быстро разбираться с чужим кодом, и быстро кодировать алгоритмы и абстракции.
Такой же аналогичный вопрос насчет синтаксического сахара и его количества! Мне думается важно качество сахара, но что насчет количества?
Как же все таки создать такой язык?
Может взять какой то из уже существующих и просто правильно его огранить, если видны недостатки может быть должно быть видно то что станет достоинством ?
Мне кажется кандидатами на донорство могли бы выступить такие языки как:
- Oberon
- Nim
- Seed7
- D
- Ruby
- Basic (Euphoria, FreeBasic, LangMF)
Если можно, напишите после раздумий и ответа, хорошую статью, а то и даже побудите, найдя хороший путь, кого то на создание такого языка, а может быть сами сможете "родить" хотя бы черновик спецификации?
Уже
Относительно того, каким должен быть идеальный язык, уже пара статей была написана, первая из них ещё в 2007 году:
http://www.croco.net/croco/papers/stolyarov_2007b.pdf
Если коротко, то в самом языке вообще не должно быть синтаксического сахара, должны быть средства для его создания в библиотеках; библиотеки как раз и должны быть его источником, а равно и источником большинства свойств, которые вы хотите видеть в языке. Сам язык должен быть ещё более низкоуровневым, чем чистый Си, и это должно быть его основное свойство, точнее, одно из двух основных; второе -- широкие возможности по введению новых абстракций. Из перечисленных вами ни один язык не может стать "донором", поскольку они все высокоуровневые.
Программа diamond "Азы программирования".
На стр. 239 в программе diamond есть небольшая недоработка в строке: "until (h > 0) and (h mod 2 = 1);", в этом случае можно ввести 1, тогда бриллиант не получается, а лишь 1 *. Если установить h > 2, то получится бриллиант из 4 *.
Ну так это вроде бы нормально
Да, я при написании этого примера решил, что высота, равная единице, представляет собой валидный частный случай, хотя и вырожденный. Не вижу в этом проблемы, программа работает вполне корректно.
Опечатка в "Азы программирования".
Ошибка на стр. 217. Во втором предложении сверху -- путаница.
?
Несколько раз перечитал весь верхний абзац, путаницы не обнаружил. Может быть, у меня взгляд уже настолько замылен?
Возможно туплю
На стр. 215 в последнем абзаце -- "... правильнее будет говорить о "вводе из стандартного потока ввода."", а на стр. 217 -- "... правильнее говорить о выводе в ((из(?)) стандартный поток вывода...".
Всё ещё не вижу проблемы
Когда мы что-то вводим, то это что-то есть где-то там в потоке ввода, а мы это оттуда (_ИЗ_ потока) добываем. А когда мы что-то вЫводим, то оно, вот это вот "что-то", есть у нас, и мы это "что-то" в поток запихиваем. _В_ поток.
Или я вас опять не понял? :)
Я уже и сам
Я уже и сам запутался.) Вроде логичнее, когда вводим _В_ и выводим _ИЗ_. В любом случае, у Вас в книге вроде как одна и та же мысль на стр. 215 и 217.Если это так, то похоже, что в одном из предложений есть неточность.
P.S. Капча стала невероятно сложной. :(
Когда вводим,
Когда вводим, информация идёт В нашу программу (в её переменные) -- естественно, _из_ потока ввода. В случае вывода всё наоборот.
Так я именно об
Так я именно об этом и говорю, а в книге написано иначе.)
Обнаружил ещё две неточности. В томе II на стр.193 написано - дает себя знать, вместо дает о себе знать.Так же а стр.210 в полном примере discr вместо discrim, программа не скомпилируется и не заработает.
Проверил ещё
Проверил ещё раз. Насколько я могу судить, в тексте книги всё в порядке (это про потоки).
Про discrim -- да, есть такое.
Go
Go перенаправляется на /dev/ass, как и все прочие поделки от Гугеля (простите, не удержался)...
Но у меня к Вам похожий чисто внешне вопрос и вовсе не холивару священнага ради - а что думаете о Rust? Таки сможет ли он, так долго зревший в утробе и ныне, наконец-то родившись, увы, сразу же отданный на растерзание покемонам от программизма прийти на смену усталому С, да ещё не просто заменить, но превзойти (как это высоко и красиво мечталось его первому биологическому отцу)?
Не знаю ответа, увы
Исходно было похоже, что ничего у Rust не получится, поскольку там тоже была сборка мусора и ещё много чего, но, говорят, к 1.0 от всего этого мракобесия избавились.
С другой стороны, говорят (сам не видел), что в Rust имеются высокоуровневые конструкции, реализация (то есть перевод в машинный код) которых неочевидна и может быть выполнена многими разными путями. Если это так, то на смену чистому Си этот язык не годится. Disclaimer: я не знаю Rust :-)
Опечатка в "Азы программирования".
Здравствуйте. На странице 177 второй снизу абац содержит опечатку -- "...далеко не все их (из) них существуют..."
Спасибо!
Есть такое, да.
SeekEof и конвейер
Здравствуйте, Андрей. Есть вопрос по параграфу 2.7.4 первого тома "Введения в профессию".
После замены
eofнаSeekEofправильно работают ввод с клавиатуры и перенаправление из файла, но не конвейер.Здесь у кого-то тоже проблемы с SeekEof. Неужели это баг в Free Pascal?
Похоже на то
Судя по тому, что strace показывает, эта штука убеждается, что на входе не терминал, и на этом основании решает, что можно использовать lseek. А на pipe это у неё, естественно, не получается. Руки бы поотрывать :-)
Go
Доброго времени суток!
Хотелось бы услышать Ваше мнение о языке Go. После поверхностного ознакомления, мне он показался хорошей альтернативой таким языка как С++ и Java. Что Вы думаете о нем?
Императивный
Императивный язык со сборкой мусора -- это нонсенс. Ну то есть оно может быть альтернативой для Java, поскольку там тоже сборка мусора, но это просто замена одного сорта дерьма на другой. Альтернативой C++ эта хреновина быть не может. К большому сожалению -- поскольку "плюсам" давно уже требуется замена.
Так Go
Так Go объектно-ориентированный, просто вместо иерархии классов есть интерфейсы, совсем непохожие на интерфейсы в Java.
Не знаю читали или нет вот эту статью (15 глава: Composition not inheritance).
В чистом
В чистом объектно-ориентированном языке не может быть ни вызовов функций, ни самих функций (только методы), ни переменных, ни присваивания. Так что Go нельзя рассматривать как чисто объектно-ориентированный язык, это, очевидно, очередной представитель семейства императивно-объектных гибридов, к которым относятся и C++, и Java, и C#. Повторяю, с моей точки зрения сборка мусора в таком языке означает приговор этому языку, я вообще не готов всерьёз рассматривать подобных бастардов (да, Java и C# тоже именно такие бастарды и даже, наверное, хуже).
Впрочем, ваш вопрос исходно имел отношение к тому, можно ли рассматривать Go в качестве альтернативы C++ и Java. Я не готов отвечать на вопрос, кто лучше -- Java или Go, поскольку имею некое предубеждение против сравнительного анализа сортов дерьма; в качестве же "альтернативы" C++ этот Go вообще никак не годится, то есть заведомо, то есть можно даже об этом не думать. Хотя бы даже из-за GC, хотя не только из-за него: там и range checking неотрубаемый, и много чего ещё.
Опечатка в первом томе книги
Внимательно прочитайте последний абзац на странице 92 книги "Программирование: введение в профессию". Похоже, туда вкралась опечатка.
Уже нашли
Ну да, единица -- это исполнение, а не чтение; вы ведь это имели в виду?
Авторское Право
А вы не задумывались о том, что поступили очень некорректно по отношению к авторам оригинала картинки на обложке вашей книги?
Вы украли концепт и идею и даже не знаете назначение многих символов там и что под ними скрыто.
Не только задумывался, но и точно знаю ситуацию
Прежде чем разглагольствовать об авторском праве, следует хотя бы изучить, что это такое. Во-первых. и в-главных, ни в одной юрисдикции мира никакие имущественные права не охраняют идеи как таковые, причём это касается даже патентного права, не говоря об авторском. Ни сюжет литературного произведения, ни сюжет рисунка не подлежат никакой правовой защите в роли "имущества", то есть имуществом не являются.
Во-вторых, безусловно, кроме юридических крючков, существует ещё и такая вещь, как авторство -- право неимущественное и имеющее существенно более широкую область действия, нежели область действия юридических норм, относимых к интеллектуальной собственности. В частности, выдача чужой идеи за свою, безусловно, являет собой плагиат. Но это тоже не мой случай: я в своей книге, как можно заметить, (стр.12, второй абзац сверху), подробно описал, откуда взялся сюжет картинки для обложки, и никогда не выдавал эту идею за свою.
Теперь к делу. Я требую извинений за слово "украл". Если таковых не последует, дальнейшие ваши комментарии на этом сайте премодерацию не пройдут.
В конце 28
В конце 28 страницы pdf стоит число 20286 - ОПЕЧАТКА!
Да, факт.
Естественно, должно быть 80286.
Сетевая академия Cisco
Добрый день, Андрей Викторович.
Стали бы вы обучаться в Сетевой академии Cisco, будучи студентом, например, если бы обладали такой возможностью (по времени и пр.)? Другими словами, видите ли вы пользу (учебно-научную, практическую или какую-нибудь другую) в такой программе?
P. S. Спрашиваю у вас, поскольку Cisco --- один из мировых лидеров производства сетевой аппаратуры, Сетевая академия --- комплекс образовательных программ, направленных на повышение компетентности IT-специалистов в области сетей и пр., а вы, если не ошибаюсь, достаточно долго работали с организацией/администрированием сетей и хорошо с этим делом знакомы.
Не стал бы, разумеется
Cisco — просто один из монополистов с задранными в космос ценами на железо. Заниматься изучением их "технологий" можно, на мой взгляд, в одном и только одном случае: если вам прямо здесь и сейчас необходимо срочно что-то делать с их железками. Такое бывает, если (1) вас УЖЕ взяли на работу и там надо дрессировать этих "кошечек" или (2) вам кто-то (буквально) подарил железку от Cisco (мне вот на день варенья недавно задарили старый каталист, чисто на поностальгировать) и вы хотите из неё извлечь какую-нибудь пользу.
NB: я с этими "кошками" в своё время разобрался без каких-либо "академий", без документации и даже без гугла в помощь, ибо гугла тогда ещё не было (1997 год). Правда, на моё счастье, было у кого спросить, когда становилось совсем непонятно. А сейчас на дворе вовсе не 1997 год, а совсем даже 2015-й, в интернете просто ПРОРВА информации о том, как справиться с любой мало-мальски распространённой железкой, феерическое количество всевозможных форумов, где можно задать вопросы, когда всё остальное не помогает, и т.д. Я это к тому, что если вдруг (!) вам понадобятся эти или другие железяки, то никаких проблем с тем, чтобы с ними разобраться, не будет. Просто пусть они вам сначала понадобятся.
А пока они вам не понадобились, не тратьте своё бесценное время на изучение чьих бы то ни было проприетарных бастардов. Изучайте лучше математику, накачивайте эластичность мозга. Оно всяко полезнее. Это можно выразить и иначе: своё драгоценное время очевидно полезнее инвестировать в себя, любимого, нежели чем в благополучие коммерческого гиганта, у которого, кстати, и так всё хорошо. Изучая технологии, которые являются чьей-то собственностью, вы попросту дарите собственное время владельцу этой технологии. У вас что, много лишнего времени? Я бы сказал, время вообще не может быть лишним, жизнь гораздо короче, чем хотелось бы.
Ах да, ещё один момент: если бы я сейчас строил провайдера, как в тогда 1997 году, то ни одной циски в моей сети бы не было. Это, замечу, несмотря на то, что обращаться я с ними прекрасно умею, там по моим наблюдениям почти ничего не поменялось за 15 лет.
В целом я
В целом я поддерживаю Ваше мнение о том, что на курсы не стоит тратить времени и денег. С одной стороны, на курсы будут потрачены время и деньги, а полученный сертификационный статус нужно будет периодически подкреплять, т.к. он со временем устаревает. С другой стороны, я думаю что курсы Cisco полезно пройти хотя бы один раз, человеку, который занимается вопросами архитектуры сети. Полезно, потому что рецепты и ответы на вопросы из интернета не дадут охватить одним взглядом всю сеть и правильно спроектировать её. Курсы в этом cлучае ознакомят со всем ассортиментом технологий и общепринятыми хорошими практиками проектирования сетей. При этом при реальном проектировании сети совсем не обязательно зацикливаться только на одном
производителе, а делать уже осознанный выбор из всех доступных вариантов оборудования разных производителей, принимая во внимание доступные функции, цену, надёжность, наличие гарантийных центров, удобной технической поддержки и прочие критерии.
Для себя я уже давно определился, что проходить курсы по сетевым технологиям Cisco не хочу, как не хочу вообще заниматься телекоммуникациями. Для меня важно, чтобы круг интересных задач и потенциальных работодателей был несколько шире, чем одни лишь телекоммуникации и телекоммуникационные компании. Вне телекоммуникационных компаний и телекоммуникаций знание проприетарного оборудования не даёт мне почти ничего.
Поскольку Вы сказали, что в настоящее время обошлись бы без оборудования Cisco при строительстве провайдера, интересно узнать, какое оборудование Вы бы выбрали сейчас и по каким причинам?
И при чём тут курсы конкретного вендора?
Не забывайте, что Cisco — коммерческая компания, так что всё, что они делают, направлено на извлечение прибыли (по определению; это не плохо и не хорошо, это просто факт). Естественно, и все их курсы направлены в основном на пополнение рядов специалистов, умеющих работать именно с их оборудованием. Когда такой "спец" приходит куда-то строить сеть, он, естественно, требует закупить оборудование Cisco, мотивируя это тем, что оно такое замечательное, продвинутое, классное и всё такое, но на самом деле причина одна: он, вот этот "спец" хренов, Cisco умеет, а остальное не умеет. А уж это ваше «охватить одним взглядом всю сеть и правильно спроектировать её» вообще ни к каким курсам не имеет отношения, то есть вообще, заведомо. Это ремесло. Ремёсла осваиваются только в мастерской. Наймитесь в помощники к опытному админу, пасущему серьёзную сеть, лучше всего провайдерскую, и через полгода, если захотите, будете всё уметь. При этом ни какие-либо курсы, ни какое бы то ни было образование в каких бы то ни было учебных заведениях вам того же самого не даст, притом вообще ни за какое время. А уж курсы конкретного вендора — тем более! Такие вещи скорее вредят общему кругозору, нежели наоборот.
какое оборудование Вы бы выбрали сейчас и по каким причинам?
Поставил бы обычные компьютеры. Ну, возможно, в 19"-корпусах, для пущего удобства, всё-таки стойки эксплуатировать проще, чем скопище обычных боксов; и, возможно, там материнские платы были бы серверными, чтобы можно было втыкать больше сетёвок; больше того, возможно, что там вместо жёстких дисков стояли бы SSD с SATA-интерфейсом; но, тем не менее, это были бы именно обычные компьютеры, а не специальные маршрутизаторы. Возможно, управляемые свичи я бы взял от кого-то из брендов, этот вопрос я не изучал на современном рынке; кстати, возможно, даже и cisco'вские взял, тут нужно сравнивать цену/качество, скорее даже просто цены — скажем, определить, что мне нужен vlan-capable manageable switch на 24 порта, потом из всех, которые удовлетворяют задаче, рассмотреть три самых дешёвых, из них выбрать тот, который больше понравится. Но маршрутизаторами у меня бы были Linux box'ы, и даже могу сказать, под чем — под Openwall'ом.
Причина банальна: я не люблю вхолостую тратить деньги, ни свои, ни чужие.
> он,
> он, естественно, требует закупить оборудование Cisco
Вот совершенно не естественно.
Насчёт ремесла и приобретения опыта в реальной работе тоже не соглашусь с вами. В реальной работе за деревьями леса не видно. Часто люди делают что-то просто потому что так принято, не задумываясь о наличии более эффективных путей решения задачи. А чтобы найти эти пути, нужно обладать в том числе и хорошим кругозором, уметь охватить всю картину в целом.
Забавно, что в компании, где я работаю, как раз от маршрутизаторов и серверов стараются избавляться. Больше NAT-трансляций, больше PPP-соединений держит специализированное оборудование с ASIC'ами, заточенными именно на эти задачи. Большое количество серверов - это дополнительные траты на администрирование, на кондиционирование, место в узле связи, больше затраты на электричество, на ИБП для этого оборудования и на бригады инженеров, выезжающие в случае аварии на электросети всё это запитывать от генератора или просто менять ту же вышедшую из строя сетевую карту или жёсткий диск.
У нас стремятся уменьшить количество хопов между клиентом и
пограничным маршрутизатором, заменяя промежуточные маршрутизаторы производительными коммутаторами с поддержкой QinQ и стараясь уменьшить транзитный трафик между узлами связи, за счёт чего повышается эффективность использования производительности оборудования. Лучше потратить эту производительность конкретно на обслуживание клиента, а не бесполезный перегон трафика из одного узла связи в другой.
Благодарю вас за ответ.
> Вот
> Вот совершенно не естественно.
То есть как это не естественно? Очень даже естественно, "я умею решать поставленную задачу, для этого мне нужно оборудование Cisco". Слово "мне" обычно опускают для верности. И так происходит не только с Cisco, тот же Oracle живёт исключительно за счёт "специалистов", не умеющих работать с другими СУБД и не знающих, что в большинстве ситуаций СУБД вообще не нужна. Про "неназываемых" вообще молчу. Ещё раз подчёркиваю, что создание таких "специалистов" (в очень жирных кавычках) как раз и является основной целью всех "программ обучения", продвигаемых "крупняком".
Что касается достоинств сетки на коммутаторах в сравнении с сеткой на роутерах -- всё это никак не противоречит сказанному мной и вообще является иррелевантным в нашем обсуждении. ИНОГДА сервера и роутеры нужны, и никуда не денешься; вот в этих случаях, когда роутеры таки оказываются нужны (например, на пути к аплинку) я Cisco использовать не стал бы, и вообще никакие специальные железки, а поставил бы Linux box'ы. Ну а сетки из свитчей я тоже люблю, но цисковские каталисты — не единственный в мире вид управляемых свитчей.
Ах да, и ещё: роутеры на статике никакого трафика не порождают, кроме ARP. Когда свичи между собой договариваются о span tree, трафика они генерят, пожалуй, побольше.
>Ещё раз
>Ещё раз подчёркиваю, что создание таких "специалистов" (в очень жирных кавычках) как раз и является основной целью всех "программ обучения", продвигаемых "крупняком".
Это не понимают только дураки. Дураки другого рода считают, что на курсах Cisco занимаются ТОЛЬКО агитацией и ничему не учат.
>вот в этих случаях, когда роутеры таки оказываются нужны (например, на пути к аплинку) я Cisco использовать не стал бы, и вообще никакие специальные железки, а поставил бы Linux box'ы. Ну а сетки из свитчей я тоже люблю, но цисковские каталисты — не единственный в мире вид управляемых свитчей.
Когда роутеры таки оказываются нужны, оказывается что Linux box'ы не способны прокачать через себя такой объём трафика. Представьте себе маршрутизатор с десятками портов 10G, который к тому же держит BGP Full View от нескольких вышестоящих операторов, терминирует десятки тысяч PPP, NAT'ит, аутентифицирует, авторизует и учитывает по RADIUS'у и NetFlow льёт.
Даже если упереться в Linux box'ы, то окажется что вместо одной стойки дорогого фирменного оборудования нам понадобится десяток стоек с дешёвыми Lixux box'ами, коммутаторами для них (не забывайте, что каждый Linux box - это дополнительные порты на коммутаторе, а значит дополнительные коммутаторы), ИБП для них и кондиционерами для них. И как вершинка тортика - понадобится высокопроизводительное оборудование, которое сагрегирует весь этот трафик Linux box'ов для вышестоящего оператора. И всё это дело нужно настраивать, менять у него жёсткие диски, распределять между ними нагрузку и т.д. Значит нужно больше людей, которые всем этим будут заниматься.
В сети провайдера, о котором я говорю, используются D-Link'и, редкие H3C/HP и Force10/Dell, и те самые QinQ-коммутаторы - Extreme с 50-ю 10G портами. Кстати, где это возможно, и от коммутаторов стараются избавиться, заменяя их на DWDM-оборудование. Из маршрутизаторов используются считанная пара десятков Cisco (76xx для разного рода MPLS и ASR как пограничные маршрутизаторы) и несколько штук BRAS'ов Ericsson. Catalyst'ы я где-то видел, в единичных экземплярах. Возможно на пробу покупали. Сейчас вместо D-Link пробуют кое-где использовать SNR.
Избавляются как раз от серверов FreeBSD с quagga и mpd - дорого обходятся. Вместо 250 серверов проще и дешевле по всем показателям оказывается парочка BRAS'ов, трафик до которых доводится из узла связи через коммутаторы.
STP порождает много трафика, медленно сходится. Сегментация трафика и кольца RSTP позволяют избавиться от штормов из-за петель и быстро перенаправлять трафик проблемного участка через другой аплинк.
В общем, судя по опыту этого провайдера, выгоднее оказывается покупать дешёвое оборудование для домовой сети, но дорогое - для узлов связи. Не выгоден ни подход "только Cisco", ни "дешёвые коммутаторы и Linux box'ы c Openwall". Нужно подходить ко всем решениям с умом.
Дураки другого
Дураки другого рода считают, что на курсах Cisco занимаются ТОЛЬКО агитацией и ничему не учат.
Если ничему не учить, то полученная на выходе макака не будет ничего уметь (спасибо КО), то есть её, макаку эту, на работу никто не возьмёт и к решению о финансовых затратах не подпустит и толку с неё вендору не будет. Так что совершенно очевидно, что там чему-то учат. Причём, на мой взгляд, очевидно также и то, чему там учат: решать задачи, используя решения данного конкретного вендора. Любые общезначимые знания и навыки, которые там проскакивают — это чистая случайность, некоторые такие вещи слушателям рассказывать приходится, потому что они иначе не поймут того, что им навешать необходимо по правилам игры.
Вопрос тут в другом: зачем вообще нужно такое «перекошенное» обучение, калечащее мозги, особенно если учесть, что там нет и не может быть никаких знаний, которые нельзя было бы приобрести без всяких вендорских курсов.
Обсуждать инженерную конкретику построения сетей я не готов — я сети уже пятнадцать лет не строил, для такой дискуссии нужно хотя бы чуток освежить знания, но тратить на это время только затем, чтобы тут что-то такое ответить, сами понимаете, мне некогда и смысла особого нет, а прикладного смысла для себя я тут не вижу — мне вряд ли когда-нибудь ещё придётся строить провайдерскую сетку. Сказанное про FreeBSD&quagga вызывает вопросы, но лучше я в эту область сейчас не полезу.
Добавьте,
Добавьте, пожалуйста, нумерацию в списке доноров для вашей книги, посетителям сайта будет удобнее оценивать их количество.
Давайте по-другому
У меня вызывает внутреннее противодействие идея снабжать людей номерами, когда в этом нет серьёзной необходимости. Давайте я лучше отдельной строчкой это количество буду указывать.
Здравствуйте!
Здравствуйте!
Случайно наткнулся на ссылку на ваш сайт в сообществе "Типичный Программист"
Хотелось бы спросить у вас совета, с чего стоит начинать программировать? Просто, я пробовал начинать писать на многих языках, писать программки из учебников, но очень быстро сталкивался с тем, мне, грубо говоря, нечего писать, потому что нет никакой конкретной сложной задачи, на которой можно было бы научиться чему-то новому, а самому придумывать такие у меня не получается. Может, есть какой-то учебник, или сборник задач, или просто какой-нибудь способ, как пройти этот порог?
Пройти порог
Ну да, это проблема. В принципе, довольно типичная "первая сложная задача" — это какая-нибудь игрушка. Естественно, без графики и без GUI. Отсутствие графики само по себе вас смущать не должно, вон в Nethack люди десятилетиями рубятся, и ничего.
А ещё рекомендую глянуть здесь на сайте статью "Почему Unix".
Обработка ошибок
Здравствуйте. Интересно узнать Ваше мнение об обработке исключительных ситуаций в С++ и обработке ошибок в целом.
С одной стороны, механизм исключений удобен, но в языке без сборки мусора, единой иерархии классов или хотя бы ограничения на тип исключения он несёт больше проблем, чем решает. При наличии исключений трудно дать какие-либо гарантии, утечки ресурсов могут возникнуть в самых неожиданных местах (да, да, стандарт пытается заткнуть эти дыры). Потенциально исключения позволяют передать произвольную информацию обработчику, но в реальной жизни даже узнать, какой фрагмент кода выборосил исключение, не всегда возможно. Отдельной проблемой является избыточное использование исключений и использование не по назначению (для управления потоком управления, хотя многие считают это достоинством). Причём, последнее зачастую решается только -fno-exceptions со старта.
и при чём тут единая иерархия?!
Вот уж чего совершенно в упор не вижу, так это связи между исключениями с одной стороны и этими вашими сборкой мусора и единой иерархией — с другой. Auto cleanup и деструкторы никто не отменял, так что за высвобождением ресурсов контроль полный в любом случае, если работать аккуратно; ну а безалаберность надо лечить не средствами языка, а лишением премии и увольнением с работы, или ещё лучше электрошоком. С другой стороны, как сборка мусора, так и единая иерархия классов (и, как следствие, таблица виртуальных методов в каждом объекте, а то и, чего доброго, все вызовы методов оптом виртуальные) — это приговор языку сразу и без вариантов, то есть такие языки (вроде пресловутой джавы) использованию не подлежат вообще. Хотя, конечно, C++ после выхода новых стандартов хуже уже не станет, понятное дело, то есть мертвее уже не будет, но тут по крайней мере можно декларировать, что используется подмножество, и ещё некоторое время более-менее нормально жить.
У исключений C++ есть другие недостатки, и прежде всего то, что оно тянет за собой RTTI и вообще очень большой и жирный кусок рантайма, да плюс к тому в генерируемом коде возникает (в начале и конце каждой функции) ТАКОЕ, что в машинный код просто страшно заглядывать. Если бы, к примеру, исключения символизировались не типом объекта, как это сделано в C++, а, например, адресом в памяти (то есть делаем глобальную переменную произвольного типа, в ней же храним информацию об обстоятельствах исключения, а кидаем не "объект произвольного типа", а адрес этой переменной, и ловим исключение не по типу, а путём указания глобальной переменной, отвечающей за данный вид исключения), реализация стала бы проще в разы, и рантайм бы в разы уменьшился. Вон на уровне чистого Си есть setjmp и longjmp, они, по ходу, вообще ничего в программу не втаскивают, и, больше того, даже не являются средством языка, обычные библиотечные функции, правда их реализация зависит, конечно, от платформы и компилятора, но это уже детали.
Короче, резюме такое: надо бы пользователю (программисту) отдать возможность принятия решения о том, сколь сложный механизм обработки исключений ему нужен. В языке такового быть не должно, но должны быть средства для его создания (в частности, архитектурно-независимые средства манипуляции стековыми фреймами с возможностью их, фреймов, пометки для последующего анализа на размотке).
Ну а за использование исключений для управления, то есть для штатного выхода из вложенных контекстов, надо убивать сразу. Желательно насмерть. Если в команде есть такие люди, то -fno-exceptions не более чем полумера, а правильная мера — гнать в три шеи. Хотя, конечно, при нынешнем дефиците программистов это не всегда реально.
Пара слов благодарности
Скажу огромное спасибо Андрею Викторовичу за его стиль преподавания, который чрезвычайно и невероятно раскладывает все по полочкам в голове (хотя иногда это стоит некоторым студентам пары миллионов их нервных клеток :) )
Отдельное спасибо за материалы (книги и статьи), которые подготовлены автором и, более того, выложены в свободный доступ в прекрасном виде. (Жалко только, что pdf зашифрованные, неудобно растаскивать на цитаты :) )
Эти книги и материалы тоже написаны безумно интересно и познавательно - читается легко, понять не сможет только тот, кто не хочет.
Короче говоря, МГУ повезло, что человек с таким талантом преподавания и богатым опытом работы в IT сфере соглашается вкалывать в университете.
Музыкой навеяло
Что-то мне вспоминается классика:
Уж сколько раз твердили миру...
Если серьёзно — да пожалуйста, заходите ещё :-)
Вы разместили
Вы разместили ссылку на сайт с JavaScript => на вредоносный сайт.
Да неужели?
Контент по ссылке доступен при полностью отключённом в браузере исполнении JS. Если у вас JS включён — это ваши проблемы.
(обращаясь к публике) попкорн за углом продают, рассаживайтесь поудобнее...
То есть если я
То есть если я размещу ссылку на вредоносный exeшник, то я не виноват, а это проблемы тех, кто пользуется Windows?
Ну, вообще-то да
Ну, вообще-то да :-) То есть лично я не имею совершенно ничего против распространения вирусов, троянов и прочей гадости, которая усложняет жизнь виндузятников. Правда, уголовный кодекс со мной не согласен, но тут уж я ничего поделать не могу.
Благодарю за
Благодарю за выложенные работы, с интересом прочитал статьи об авторском праве и информационном насилии.
Вы в курсе проекта под названием Diaspora?
https://joindiaspora.com
Как раз то, что вы цените в средствах общения как я понимаю (открытый код, приватность информации)
Интересная ссылка, thanks
В принципе, ощущение такое, что это шаг в правильном направлении. Среди вещей, которые я ценю, в применении к социальным связям основная -- это распределённость, её вы не упомянули, но тут она присутствует.
Что сходу не понравилось -- там на всех страницах javascript и мне не удалось найти ничего на тему его отстригания. Ну а второе -- конечно же, ruby on rails. На моих серверах везде Openwall GNU/*/Linux, для него соответствующих пакетов нет, а самому их делать меня совершенно точно заломает. Мораль -- свой pod мне не запустить. А на чужом я жить не стану, с меня достаточно.
Вообще, на самом деле, центром такой системы должна быть не реализация, а протокол, то есть набор соглашений о структурировании информации и обмене таковой. И как минимум две (для начала) реализации, желательно выполненные на разных языках и совсем разными командами. Если такое будет достигнуто - это будет некая точка невозврата. Ну а у этих ребят, увы, фокусировка прямо противоположна, про протоколы там вообще ничего не говорится, очевидно, что общаться они собираются исключительно сами с собой, в смысле с другими экземплярами того же приложения.
Но так всё же лучше, чем никак.
Лучше бы не наблюдал вовсе
В том всё и дело, что это не "упёртые плюсовики", а как раз предпочитающие те самые сверхвысокоуровневые языки. Но как только берутся за то, что собираются выложить на общественное поругание, зачем-то делают это на С++. И ситуация уже даже не смешная: "хочу шоб було то, то, и то, мне не нравится, но всё равно буду делать так". Тысячи вопросов, тонны недовольств, и продолжают упорствовать. А наблюдается это при внимательном взгляде на публичную деятельность обозначенных персонажей в различных хостингах (может, не такой уж и показатель, но за последние несколько лет для студентов и выпускников в первые 1-2 года ничего принципиально не изменилось), в результате чего и берётся "большой опыт". В любом случае благодарю за некоторое уточнение ситуации.
P.S. Вопрос с ответом уползли в архив, наткнулся случайно.
Они не
Они не "уползли", они там [ http://www.stolyarov.info/guestbook/archive/1#comment-715 ] изначально и были — я забыл в своё время запретить на той странице новые комментарии, а вы свой вопрос зачем-то оставили там, а не здесь.
Ну а про плюсы — а фиг знает, что движет людьми. Вот как можно, например, на PHP писать? Я имею в виду, как можно себя настолько не уважать, что не брезговать ТАКИМИ инструментами? Но ведь пишут.
Физические основы построения ЭВМ
Здравствуйте, Андрей Викторович!
Я учусь в Ташкентском филиале МГУ им. Ломоносова и скоро у нас начнут читать предмет "Физические основы построения ЭВМ". Не могли бы Вы посоветовать литературу (на русском или английском языке), желательно книгу, по которой можно было бы ознакомиться с "Физическими основами построения ЭВМ". На http://msu.uz/e/4f81a3881adf57d776000001 заявлена очень интересная программа, однако большую ее часть на наших лекциях мы проходить не будем.
Спасибо.
Гм
У меня возникает ровно один вопрос: а при чём тут я? К Ташкентскому филиалу я, к счастью, уже скоро пять лет как никакого отношения не имею, к курсу "физ.основы" — тем более.
Если попробовать ответить по существу вопроса, то под названием "Физ.основы построения ЭВМ" может скрываться всё что угодно; когда я был студентом, нам в рамках этого предмета рассказывали, как между собой надо соединять микросхемы памяти (и, кажется, всё - во всяком случае, я больше ничего не помню). Что будут вам читать в рамках этого курса, я не имею и не могу иметь никакого представления, это полностью зависит от лектора.
В общем, вы не по адресу. Совсем.
В каком направлении должен развиваться С++ ?
Здравствуйте. В http://www.stolyarov.info/guestbook/archive/1#comment-468 вы высказали свое недовольство по поводу нового стандарта C++11 и таким вещам, как STL и RTTI. Не могли бы вы более подробно описать, что именно не так с этими вещами? Вы предлагаете для каждого проекта каждый раз писать свое подмножество STL? Или есть что-то лучше, чем STL? В каком направлении должен развиваться С++ ?
О направлениях
вы высказали свое недовольство
Начнём с того, что слово "недовольство" крайне превратно описывает то, что я сказал. Тут больше подходит словосочетание "крайняя степень возмущения", причём не самими STL и RTTI, а теми идиотами, которые их сначала создали, а затем протащили в стандарт языка.
что именно не так с этими вещами
С ними не так буквально всё. Впрочем, это либо очевидно, либо — если не очевидно — то любые объяснения, как правило, бессмысленны.
Вы предлагаете для каждого проекта каждый раз писать свое подмножество STL?
Разумеется, нет. Тогда уж лучше использовать STL, всё равно хуже уже не будет. Впрочем, можно предложить ещё "лучше": писать на PHP. Или на бейсике. Или на коболе. Чего напрягаться-то понапрасну, Си-плюс-плюс какой-то там, классы, методы, это всё слишком сложно. Берём вижуал васик и вперёд.
Если же PHP или бейсик не устраивает, то я не вполне понимаю, как может устраивать связка C++/STL. Контейнеры, очевидно, вообще нельзя использовать — сама идея таковых порочна. Структуры данных не бывают универсальными, за исключением самых простых (массивов и списков), но использование контейнеров для массивов и списков заведомо бессмысленно — за более чем сомнительный выигрыш во времени кодирования мы при этом вынуждены расплачиваться феерическими приключениями во время отладки и сопровождения, причём ставки там приблизительно неделя (проигрыша) за пять минут (экономии); ну а более сложные структуры данных должны, естественно, проектироваться под каждую конкретную задачу (не под проект, а именно под каждую возникающую задачу), и generic они быть не могут — как следствие, ни о каком применении шаблонов при построении сложных (проблемно-ориентированных) структур данных не может быть никакой речи. Это я уже не говорю о том, что
listвообще-то двусвязный, тогда как в большинстве задач список требуется односвязный; или о том, чтоstringв последнее время перестал быть copy-on-write, ну и так далее. То есть даже самые простые порождения STL'я вообще-то никуда не годятся.Подчеркну, это совершенно не означает, что нельзя использовать шаблоны; напротив, их можно и нужно знать и уметь использовать, но контейнеры тут ни при чём.
Или есть что-то лучше, чем STL?
Конечно, есть: его отсутствие.
Если же имеется в виду "есть ли библиотека для решения той же задачи, что и STL, которая решает задачу лучше", то такие наверняка есть (можете поискать в гугле, если не лень), если только допустить, что "та же задача" вообще существует. Я утверждаю, что задачи как таковой попросту нет, поэтому вопрос о существовании аналога STL, который был бы "лучше", оказывается бессмысленным. Не нужен ни STL, ни какие-либо его аналоги. Тем, кто с этим не согласен, следует, очевидно, выбрать другой язык программирования, потому что тратить силы на работу на довольно сложном языке только для того, чтобы идиотская библиотека съела (причём с запасом) все его преимущества — со стороны выглядит как-то глупо.
В каком направлении должен развиваться С++ ?
Теперь уже, видимо, ни в каком. Нужен другой язык, который займёт нишу языка произвольного уровня, в отличие от существующих языков уровня низкого (asm/*, plain C) или высокого (всё остальное). C++ мог занять эту нишу до включения в него RTTI (STL, к счастью, свойством языка не является, так что он бы, в принципе, не смог всерьёз помешать — хотя размах подрывной деятельности стандартизаторов впечатляет, да). В нынешнем своём состоянии C++, особенно в связке с STL — язык, я бы сказал, уровня безнадёжно высокого, приближающийся к командно-скриптовым. Зачем такой нужен ещё один такой язык, не вполне понятно, их уже и так — как грязи.
т.е по вашему
т.е по вашему
подход Степанова [url removed]
поданный в Началах Программирования([url removed])
бесполезен?
зы. [url removed]
Бесполезен?!
Это неправильное слово. Правильное будет по меньшей мере "вреден" или, лучше сказать, "вредоносен".
Степанов — это человек, который нанёс индустрии (и в конечном счёте всей цивилизации) больше вреда, чем Гейтс и Джобс вместе взятые. Именно он фактически уничтожил уникальный инструмент, каковым был ранний язык Си++, при этом так и не поняв, что это было.
Обсуждать здесь нечего.
Вы серьёзно?т.е
Вы серьёзно?
т.е Страуструп пригрел на груди .... ?
С++ (то что у языка нет однозначной грамматики это зигзаг истории) - без stl , а тем более ранний это что?
пропатченый препроцессор - транслятор в old-C
Ага, точно
Нет, блин, я не серьёзно, я тут так, тряпки жгу и смеюсь. У меня встречный вопрос: а вы это тут серьёзно спрашиваете, "что же такое C++ без STL"?
На самом деле, вопрос типичный, его в наше идиотическое время задают на удивление часто (и за одно это Степанова стоило бы публично четвертовать: он не только сам не понял, с чем имеет дело, но и сделал так, что сейчас этого почти никто не понимает). Ну так я вам на этот вопрос отвечу. C++ без STL и без некоторых поздних возможностей — например, исключений — это низкоуровневый язык (то есть пригодный, например, для ядер операционных систем или для микроконтроллеров), но при этом позволяющий навертеть сколь угодно высокоуровневые абстракции. То есть, иначе говоря, это язык произвольного уровня.
Можно зайти с другой стороны. Если из описания C++ выкинуть любые упоминания его треклятой стандартной библиотеки (как это сделал я), то останутся, во-первых, классы с механизмом защиты; во-вторых, конструкторы и деструкторы, в том числе их автоматический вызов в определённых ситуациях (кроме автоматического вызова деструктора при исчезновении объекта тут следует отметить ещё конструкторы копирования и преобразования); перегрузка символов операций для пользовательских типов, что, собственно, даёт на выходе абстрактные типы данных в полный рост. Что с помощью всего этого можно сделать? Ну, например, вот это: http://www.intelib.org ; а точнее — можно сделать что угодно, практически любые инструменты из других языков программирования поддаются моделированию таким способом. А язык при этом сам по себе низкоуровневый (ну, был когда-то, пока исключения в него не впендюрили), то есть у него отсутствуют (отсутствовали) ограничения, не позволяющие где попало использовать ту же джаву, C# и прочее.
Итого: C++ мог (когда-то давно) стать универсальным языком, то есть таким, перед которым ни у каких других языков нет осязаемых преимуществ вне зависимости от решаемой задачи. Разумеется, этот момент упущен, сейчас C++ (даже без STL) — просто язык высокого уровня, притом кривой, а с учётом последних "стандартов" — попросту нежизнеспособный.
Ну а что когда-то на самых ранних этапах своего развития C++ был реализован в виде компилятора, выплёвывающего чистый Си (не "old", а "plain" — plain C остаётся самостоятельным языком и, в отличие от C++, подыхать совершенно не собирается, поскольку альтернатив ему просто нет) — ну так и что с того? Некоторые компиляторы той же Scheme тоже на выходе plain C выплёвывают, и вроде никого это не смущает.
Уж не знаю, кто там кого "на груди пригрел", Степанов-то постарше Страуструпа будет (аж на полтора месяца, гыгы). Но тут скорее другое. Тексты Страуструпа, написанные раньше третьего издания книги "Язык C++", производят впечатление гениальных, а само третье издание и всё, что за ним последовало — впечатление, что это писал душевнобольной. При этом сам Степанов в одном из своих интервью заявил, что Страуструп — упрямый чёрт, но и его удалось переупрямить. Ощущение со стороны такое, что Степанов — из той породы особо опасных дураков, в которых очень сложно разглядеть дурака, а опасность в том, что они делают дураками окружающих, обращая их в свою веру. Степанов превратил гения Стауструпа в дурака Страуструпа. Больше того, эта его дурь сейчас владеет умами тысяч программистов, которые могли бы быть гораздо умнее, если бы не вот эти вот дифирамбы STLю на уровне религиозных. Код, написанный с использованием STL, превращает maintenance в ночной кошмар, а две трети пишущих на нём совершенно не понимают, что делают (есть даже такие, для которых list отличается от vector отсутствием операции индексирования, а значит просто неудобная хреновина — и такие люди пишут программы за деньги) — но всё равно все продолжают петь осанну STLю. Кто поумней — уходят "вниз" на чистый Си или "вверх" на джаву, C# или какой-нибудь питон, и правильно делают — если рассматривать STL как часть C++, то писать на C++ просто нельзя, такие инструменты не подлежат использованию.
Тема на ЛОР про метапрограммирование на C++
Я на ЛОРе создал тему про метапрограммирования на плюсах, и вспомнил про вашу библиотеку intelib. Просьба ответить там https://www.linux.org.ru/forum/development/12198201/page1?lastmod=145036...
данный комментарий можно не раскрывать
Увы
К сожалению, я вообще не вижу, что мне там в этой теме отвечать, на что и зачем. InteLib к метапрограммированию никакого отношения не имеет.
Т.е. InteLib
Т.е. InteLib непригоден для написания макросов, работающих с неким подобием абстрактного синтаксического дерева, и таким образом расширять изначальный синтаксис, добавляя в язык некие новые конструкции или вводя некие правила преобразования AST (как в LISP)? Какая же область применения у данной библиотеки?
Вот вы пишите, что C++ мог стать универсальным, что > а точнее — можно сделать что угодно, практически любые инструменты из других языков программирования поддаются моделированию таким способом
Похоже что это как раз одна из вещей, которую таким способом смоделировать нельзя, как не старайся. И для языка С++ единственный выход из ситуации - использовать кодогенерацию и всякие DSL. Я хочу сказать, что у С++ и прочих производных c Си подобным синтаксисом (obj-C, D) просто изначально нет шанса стать тем самым языком произвольного уровня, и стандартизаторы тут непричем совершенно. К тому же все эти RTTI и обработки исключений легко отключаются соответствующими опциями компилятора, и STL-ом вас тоже никто под дулом пистолета пользоваться не заставляет, так что введением новых фич язык не испортить.
Т.е. InteLib
Разумеется, нет. Там вообще нет макросов.
Какая же область применения у данной библиотеки?
Вы не поверите: программирование на Лиспе (то есть в S-выражениях) в рамках проекта, основным языком которого является C++.
Что меня крайне удивляет, так это то, откуда вы вообще нашли в окрестностях InteLib все эти ваши макросы, синтаксические деревья и прочее метапрограммирование. Ничего подобного там никогда не было и не задумывалось.
Последний ваш абзац мне кажется бессмысленным набором слов, ответить на него я вообще ничего не могу.
> Что меня
> Что меня крайне удивляет, так это то, откуда вы вообще нашли в окрестностях InteLib все эти ваши макросы, синтаксические деревья и прочее метапрограммирование. Ничего подобного там никогда не было и не задумывалось.
Ну я подумал, что если там есть S-выражения, то логично было бы добавить туда макросы, которые позволяли бы на этапе компиляции работать с этими S-выражениями.
> Последний ваш абзац мне кажется бессмысленным набором слов, ответить на него я вообще ничего не могу.
Попробую переформулировать. Последним абзацем я хотел сказать, что универсальный язык произвольного уровня не может быть построен на основе С++ ввиду его унаследованного Си синтаксиса, негомоиконности и невозможности работать с AST (что возможно в лиспе, но лисп не проходит по другой категории - в нем GC)
макросы,
макросы, которые позволяли бы на этапе компиляции работать с этими S-выражениями
Во-первых, макропроцессор в Си/Си++ крайне беден и такие сложные задачи решать не может в принципе. Он, если на то пошло, вообще не годится для метапрограммирования, там же ни циклов нет, ни рекурсии, то есть он сам по себе алгоритмически неполон, а конструкций языка ещё нет (ведь маропроцессор проходит до синтаксического анализа).
Во-вторых, S-выражения в InteLib моделируются иерархией классов с виртуальными функциями, то есть используется динамический полиморфизм в полный рост; работа со всем этим хозяйством во время компиляции тоже, естественно, невозможна, поскольку невозможно определить, с S-выражением какого типа мы имеем дело (заметим, в Лиспе происходит то же самое).
универсальный язык произвольного уровня не может быть построен на основе С++ ввиду его унаследованного Си синтаксиса
Синтаксис здесь вообще ни при чём. Определяющими для универсального языка являются два момента: (1) его низкоуровневость, без которой он оказывается принципиально неприменим в проектах вроде ядер операционных систем и (2) возможность создания сколь угодно сложных абстракций.
негомоиконности
Если я только правильно понимаю, о чём идёт речь, то на универсальность языка такое повлиять в положительную сторону не может. В отрицательную -- запросто: если язык обладает гомоиконностью, то есть в нём программа и данные представляются каким-то одним универсальным способом (S-выражения в Лиспе, строки в командно-скриптовых языках), то возникает соблазн ввести в него EVAL — и всё, прощай низкоуровневость.
невозможности работать с AST
С одной стороны, написать на языке программу, которая генерирует программу на этом же языке, можно на любом языке, обладающем алгоритмической полнотой. С другой стороны, если с AST можно работать в рантайме -- такой язык в плане универсальности заведомо безнадёжен.
Обнаружил
Обнаружил небольшую опечатку. При добавлении комментария появляется "Ваш комментарий помещён в очередь на модерирование. Как только администрация одобрит его, комментарий будеь опубликован."
Спасибо
поправлено
Отправить комментарий