Гостевая книга

Здесь вы можете оставить сообщение для владельца сайта, отзыв о функционировании, оформлении, содержании и вообще написать всё, что думаете по этому поводу. Просьба придерживаться темы ("по этому" — это ещё не "по любому") и соблюдать приличия :-)

Обратите внимание, что связаться с автором сайта можно также и через страницу обратной связи, которая позволяет отправить автору email.

Учтите, что комментарии на этом сайте премодерируются.

[Все старые комментарии перемещены в архив >>>]

Хеш-таблицы

Добрый вечер, Андрей Викторович! Я хотел спросить про хеш-таблцы: их на этапе использования языка Паскаль стоит изучать и стоит ли их изучать вообще, либо же лучше освоить работу с двоичным деревом поиска, и использовать его, когда число хранимых элементов среди которых надо проводить поиск - большое? Спасибо!

Общий принцип

Общий принцип работы хеш-таблиц прост до невозможности, эффект от них весьма серьёзный, так что нужно, по-видимому, понимать, что это такое и как оно (в общих чертах) работает. "Изучать" их не надо — изучите, когда попадётся соответствующая задача. Пока она не попалась, достаточно знать, что это за зверь.

Возможно глупый вопрос

Добрый вечер. Хотелось бы задать пару, возможно, глупых вопросов. Начать хотелось бы с офф-топа, учусь на 1 курсе, на лекциях по программированию (а начали мы сразу с C++, ведь это современно!) часто всплывают вопросы компиляции всего, что мы пишем, а также организации кода в памяти. В общем, меня интересуют следующие вопросы:
1) часто упоминается undefined behavior и говорится о том, что с этим не стоит бороться и понимать, просто следует избегать;
2) при вопросах, связанных с памятью (хочу заметить, что 2 том вашего введения я читал, но кое-что следует просмотреть ещё раз) ответы совпадают с содержанием вашей книги, но просят в это не лезть, так как "всё это было так лет 20 назад, сейчас любой профессионал скажет, что всё намного сложнее". В общем, любые попытки узнать что-то новое заканчиваются провалом.
Ну, и последнее. Является ли это дезинформацией? И что делать, если я хочу в это лезть и хочу понимать?
Извиняюсь за некоторую расплывчатость вопросов. С нетерпением жду ответа, спасибо.

Что-то вам неудачный вариант попался

Undefined behavior (само понятие такового) — это порождение проклятых стандартизационных комитетов. Между прочим, согласно пресловутым стандартам, сложение двух целых чисел может вызвать UB — если числа знаковые и результат не поместится в разрядность. Как можно это воспринимать всерьёз, лично для меня вопрос открытый.

По поводу памяти — всё по-прежнему именно так, как было «лет двадцать назад», (ну вот разве что появилась секция .rodata, я её не рассматриваю в книге) и если интересно мнение профессионала — то я вроде бы таковым являюсь. Обычно фраза «на самом деле всё намного сложнее» часто выдаёт непонимание предмета преподавателем, а уж просьба куда-то не лезть — с моей точки зрения вообще для преподавателей категорическое табу. Если преподаватель не хочет что-то рассказывать (я и сам многое рассказывать не хочу), он по крайней мере должен отделываться от подобных вопросов фразами вроде «это можно посмотреть там и там, если очень хотите».

Ну а если хотите понимать — берите всякие источники и экспериментируйте с компьютером.

Верно сказано

И ведь в самом деле неудачный, местами даже вредный. Хотелось бы ещё отметить, что, изучая тот самый C++, из него берётся всё самое ненужное (iostream и iomanip), всё остальное идёт из C (тот же cmath, "C-строки" и т. д.). Поэтому смысла в этом цирке я не вижу. А у меня совсем не "программистская" специальность. На "программистских" во всю используют auto, лямбды и vector'ы. Я, конечно, обычный начинающий и любитель, но задаюсь вопросом: зачем изучать в таких условиях C++, и почему бы не взять что-то повыше.

На

На "программистских" во всю используют auto, лямбды и vector'ы.

Замечу, им повезло ещё меньше, чем вам. Из них там макак делают целенаправленно.

Ну, общий принцип тут простой: за использование C++ в качестве первого языка при обучении программированию надо убивать. Медленно и со вкусом.

Дин массивы Паскаль

Добрый день, Андрей Викторович! Я решил освоить динамические массивы на примере Паскаля. Из той информации, которую я нашел, следует, что переменная дин массива на самом деле является указателем на динамически выделенную (под массив) область памяти. А освобождение выделенной под массив памяти происходит с помощью операциии arr := nil, где arr - имя переменной дин массива. В связи с этим у меня возник вопрос: а действительно ли эта операция освобождает память, или же на самом деле происходит то, что вместо того, чтоб освободить память, просто теряется к ней доступ? Спасибо!

Если вы не

Если вы не собираетесь писать на Паскале за деньги (а я очень надеюсь, что не собираетесь), то не трогайте динамические массивы вообще. Их реализация в Паскале тщательно скрывает их истинную суть и механику, лежащую под ними – и, в довершение, мешает освоению указателей, поскольку найти задачу, в которой нужны списки, а дин.массивы не годятся — намного труднее, чем найти такую задачу, в которой нужны динамические данные как таковые.

Я в книге не рассматриваю динамические массивы Паскаля, и этому, как видим, есть причина.

Список опечаток

Есть смысл публиковать на сайте список найденных опечаток?

Чтобы пользователям и вам не заморачиваться, если опечатка уже найдена.

Смысл, может, и

Смысл, может, и есть, времени нет.

Очепятка

Здравствуйте. Если не ошибаюсь, то на с. 253-254 вышла опечатка. Вызов происходит с числом 7583, а вот на выходе результат вызова при значении 5783.

Эту уже нашли,

Эту уже нашли, но всё равно спасибо :-)

Благодарнасть

Спасибо Вам, Андрей Викторович, за Ваш труд! Возможно, Вы меня спасли для программирования: в ВУЗе у меня был C#, что для меня (человека, не знакомого с программированием) казалось тяжело, и отпугивало меня от программирования. Взял Вашу книгу, и по карйней мере пока что программирование для меня - занятное время провождение: это меня интересует, мне интересно попробывать всякие варианты, поиграться в процессе обучения.

Ссылки vs указатели.

Добрый день! Почитываю книжку про С++. Так вот, никак не могу отделать от ощущения, что ссылки внутри устроены "внутри" также из указателей + модификаторов. Можете что-то посоветовать? Есть ощущения, что ссылки - это только визуальное улучшение + меньше текста писать.

PS я не программист. И даже не близок к этому. Но эти книги - единственные {В России}, которые внятно рассказывают мир IT.

ps. капча ужасна.

Каких ещё

Каких ещё "модификаторов"? Там тупо адрес хранится/передаётся, так же как и в указателях. И да, ссылки — это синтаксический сахар, не более того; но языки программирования вообще состоят из синтаксического сахара.

Мне вот другое интересно, если вы не программист, то за каким лешим вам сдался C++?

C++ незачем, но

C++ незачем, но вот ваша подача материала про ООП очень даже зачем (надеюсь).

Это зависит от

Это зависит от того, каков размер (например, тупо количество строк) самой большой из написанных вами практически применимых программ. Если меньше чем 2000 (ну, плюс-минус несколько сотен, как обычно в таких случаях), то ООП останется для вас пустым звуком, даже если ваши собственные ощущения говорят об ином.

Посимвольный ввод информации. Паскаль.

Очень непонятно как работает read c типом char в программе char2num.pas

Странный вопрос

Read работает точно так же, как и всегда: считывает из потока стандартного ввода (в просторечии -- с клавиатуры) значение заданного типа (того типа, переменная которого передана параметром) и считанное значение помещает в переменную. В данном случае переменная имеет тип char, поэтому считывается значение именно этого типа — то есть ровно один символ. Он же и помещается в переменную.

Мне довольно сложно понять, что конкретно вам оказалось непонятно. Могу посоветовать взять вот такую программу:

program CharInput;
var
    c: char;
begin
    while not eof do
    begin
        read(c);
        if c = #10 then
            writeln
        else
            write('[', c, ']')
    end
end.

и посмотреть, как она будет работать, ну там погонять её и так и эдак. Возможно, это вам поможет. Если нет — попробуйте всё-таки сформулировать, в чём состоит проблема.

Исполнение кода, сформированного динамически

В первом томе на страницах 190-191 утверждается, что невозможно сформировать машинный код в памяти, а затем его выполнить. Кроме того, это утверждается в этом комментарии. Насколько я понимаю, это не совсем верно, поскольку именно так работает Just-In-Time компиляция. Конечно, если защиту от исполнения данных таки включить, то JIT работать не будет, но, насколько я понимаю, на практике её включают разве что на серверах, где требуется усиленная безопасность. Во всяком случае, по умолчанию это вроде как выключено.

Про сервера и

Про сервера и усиленную безопасность -- это вы путаете с исполнением в стеке. Что касается исполнения в секции данных, то оно запрещено ВСЕГДА, в любой мультизадачной системе, и, кстати, точно так же, как модификация секции кода.

Чтобы сделать возможным JIT, нужно затребовать у системы новую секцию памяти с соответствующими флагами (одновременно доступную на чтение, запись и исполнение). В *nix-системах это делается с помощью системного вызова mmap. И да, это возможно сделать, в книге утверждение слишком категоричное. Во втором издании поправлю.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступны HTML теги: <a> <em> <strong> <ins> <del> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre>
  • Строки и параграфы переносятся автоматически.

Подробнее о форматировании

CAPTCHA
Проверка на бота
Image CAPTCHA
Copy the characters (respecting upper/lower case) from the image.