А как вы учите языки?

>так как же более Ъ? и надо ли оно вообще, знать все эти мелочи?

Вообще надо, но нет смысла зубрить это.

детали приходят со временем, а так -- learning by doing

> я смотрю многие предпочитают взять учебник и проделать все примеры от и до

Это когда уже совсем нечего делать. Впрочем, задачи в классических книгах стоит порешать. Эта задачки - результат многих переизданий, и все они, в общем-то, полезные.

А всякие фреймворки и прочее - это по ходу... Бо сегодня один фреймворк, завтра - другой.

Есть задача - беру справочник

Язык не важен

В детстве я читал справочник от начала и до конца, после этого примерно запоминал всё, что есть в язке, без деталей. Дальше я уже знал, что можно делать какими средствами. Так я выучил клиппер.

Потом я стал лениться читать от начала и до конца, и просто начинал писать, а в справочник лез по мере проблем. Это более плохой путь, т.к. некоторые важные вещи ускользают от понимания. Тратятся силы на ненужные велосипеды.

Теперь, похоже, я стал стар. Мне уже нужно не учиться, а учить других. Хотя ХЗ. Посмотрим, хватит ли сил на питон.

более Ъ сначала во всем разобраться, атолько потом писать, а то начнутся костыли и непонятные ошибки. Паскаль и частично си так и учил.

Но сечас мне редко что писать хочется, поэтому методом тыка, в два раза дольше, с костылями, но мне большего и не надо.

ИМХО, если язык не на раз в год требуется, то время потраченное на вдумчивое изучение окупится сполна

> более Ъ сначала во всем разобраться, атолько потом писать

Это утопия. В невырожденных случаях всё и сразу в голову не влезает. Нужна практика. И именно с практикой приходит глубокое понимание, а нюансы оказываются востребованы и перестают восприниматься как бессмысленная казуистика.

> Вот народ мучается, тр***тся с абстрактными примерами, явно вникает во все нюансы

Если хочешь профессионально владеть Си и C++, то по-другому не получится, к сожалению. Некоторые конструкции в этих языках ведут себя совершенно не интуитивно, а профи не должен на этом спотыкаться. Народ трахается еще гораздо жестче - вдумчиво читает Стандарт. Лезть во всё это, не имея за плечами хотя бы года практики, нет никакого смысла.

> была бы такая задача, я бы не задумываясь написал
> const int* pi=&i;
> i++;

В твоем коде pi указывает на i, и (*pi) меняется вместе с i. А в примере http://www.linux.org.ru/view-message.jsp?msgid=3701527 пытаются заставить pi указывать на временную переменную, и так что от последующих изменений i значение (*pi) уже не зависит.

Хотя лично я терпеть не могу temporaries, и предпочел бы дать этой временной переменной явное имя. Лучше написать несколько тривиальных строк кода, чем одну - но требующую глубоких познаний.

int t = i;
++i;

если честно - не очень вникал, что хотят от этого добится, но

>Лучше написать несколько тривиальных строк кода, чем одну - но требующую глубоких познаний.

это правильно, имхо читаемость кода это важнее

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

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

> Вот народ мучается, тр***тся с абстрактными примерами

1. Прочти у алены-срр -- там это не абстрактно

2. Чуваку похоже скзали совсем не в тему про lvalue

3. Я хочу знать с++ на уровне "как он замышлялся и каким должен быть", а не на уровне "могу че-то написать"

> Некоторые конструкции в этих языках ведут себя совершенно не интуитивно, а профи не должен на этом спотыкаться.

Это может казаться из-за слишком узкого кругозора, или может быть именно так из-за (необязательно кривых) решений при проектировании языка.

Так или иначе, это надо знать.

Вдумчиво читаю учебники, мануалы, по ходу делаю учебные примеры, потом начинаю использовать полученные знания на практике и оттачивать практические навыки. По мере оттачивания практических навыков стараюсь читать уже более углублённую теорию по вопросу. Иначе никак не стать специалистом, наверное.

я на практике
лучший и самый эффективный способ

> Теперь, похоже, я стал стар. Мне уже нужно не учиться, а учить других.

Напиши книжку. Или цикл статей. Доступной для первоначального восприятия информации по Лиспу, в котором ты профи, на русском языке мало. Молодые люди изучением английского языка хоть в сколько-нибудь приемлемом виде себя обычно не утруждают, а непонятные им вещи встречают в штыки.

Интерес к Лиспу есть. В англоязычном сообществе он несравненно более популярен, потому что новички могут прочитать SICP, PCL, ANSI CL, LOL на родном языке, без смысловых деформаций, внесённых переводчиком.

> Напиши книжку. Или цикл статей.

Поддерживаю mv. Вовсе не обязательно цикл. Достаточно одной достаточно объемной статьи с описанием фич лиспа и __очень__ кратким объяснением что это такое на пальцах (даже без кода).

Кстати, вполне возможно для этого подошло бы ЛОР-овское вики?

> В англоязычном сообществе он несравненно более популярен, потому что новички могут прочитать SICP, PCL, ANSI CL, LOL на родном языке, без смысловых деформаций, внесённых переводчиком.

Лисп *бесполезно* толкать новичку. Его имеет смысл объяснять только серьезным программерам.

> Лисп *бесполезно* толкать новичку. Его имеет смысл объяснять только серьезным программерам.

MIT и его SICP говорят об обратном. В дебри макросов и ридтейбла никто же не призывает сразу бросаться?

> надо ли оно вообще, знать все эти мелочи?

Да. Всем кажется что они после прочтения туториала знают питон. А на самом деле это не так и нюансов там куча. Если что-то для себя по мелочи пишешь то пофиг, а вот на работе такое приводит к печальным последствиям. Никогда не думал почему большинство php-программистов не умеют писать? Они беруться за дело даже толком туториал не дочитав.

Чтобы эффективно решать задачи надо знатать все методы её решения чтобы выбрать самый подходящий. А если твои(не конкретно твои, я вообще говорю :)) знания сильно ограниченые несколькими примерами из обзорных статей то так и будешь везде их применять. И тогда другие при взгляде на такой код будут его очень нелестно комментировать.

> MIT и его SICP говорят об обратном. В дебри макросов и ридтейбла никто же не призывает сразу бросаться?

Не вижу *никакого* смысла в лиспе без макросов по сравнению с остальными языками. Может, подскажешь?

> Не вижу *никакого* смысла в лиспе без макросов по сравнению с остальными языками. Может, подскажешь?

А ты Лисп когда учил (если учил вообще...), то сразу с defmacro начал?

> А ты Лисп когда учил (если учил вообще...), то сразу с defmacro начал?

это никак не влияет на предмет обсуждения.

Как же достал распространитель "виагры" для младенцев.

> А ты Лисп когда учил (если учил вообще...), то сразу с defmacro начал?

если очень попросишь, я могу лирическое отступление сделать на тему "изменение моего взгляда на лисп с приобретением знаний", но зачем?

> это никак не влияет на предмет обсуждения.

Я понимаю, что критикам творчества Пастернака не обязательно его читать, но всё же... SICP-то хоть читали? Имхо, одна из самых лучших вводных книжек по теме "как работают программы".

> Как же достал распространитель "виагры" для младенцев.

Я это понял как согласие с моим тезисом "лисп можно оценить только как второй язык"

> Я понимаю, что критикам творчества Пастернака не обязательно его читать, но всё же... SICP-то хоть читали? Имхо, одна из самых лучших вводных книжек по теме "как работают программы".

Попробовал. Вытошнило. Перестал.

Меня метапрограммирование интересует, а не детская азбука.

При чем не просто, а в сравнении с аналогами из плюсов и хаскеля.

Еще интересуют некоторые фичи лиспа, которых я возможно не вижу в обычных языках, типа restart и прочих прыжках по стэку.

сразу начинаю писать маленькую очень нужную программу, которая просто необходима именно на этом языке, походу, матерясь, просматриваю мануал и гугля по проблемам,и да таким образом lisp не выучишь(ИМХО), и еще раз да я не программист ^_^

Я не знаю согласуется это с твоим миропонимаением или нет, просто этот школьник меня лично уже достал :)

> Меня метапрограммирование интересует, а не детская азбука.

Т.е. Лисп в качестве целевого языка для детской азбуки всё-так подходит?

> При чем не просто, а в сравнении с аналогами из плюсов и хаскеля.

Если имеется опыт в плюсах и хаскелле, то можно просто референс по языку читать, и разница сама собой будет видна. Если опыта в плюсах и хаскеллях нет, то зачем вообще проводить сравнения, если читатель не в курсе темы разговора? Если в книжке по лиспу начать объяснять, что там есть в плюсах, то это, опять же, детская азбука, плюс отклонение от основной темы.

> Т.е. Лисп в качестве целевого языка для детской азбуки всё-так подходит? Не писатель дестких азбук. (имхо нет).

> Если имеется опыт в плюсах и хаскелле, то можно просто референс по языку читать, и разница сама собой будет видна.

Референс? Типа стандарта анси? Или даже что попроще?

Не подходит. Слишком много времени читать, и там дохрена ненужных деталей, среди которых самое интересное и не увидишь.

Хотя, за неимением лучшего, можно прочитать оглавление. И по диагонали страницы.

> Я не знаю согласуется это с твоим миропонимаением или нет, просто этот школьник меня лично уже достал :)

Этому школьнику по моей оценке в районе 35 лет.

> Референс? Типа стандарта анси? Или даже что попроще?

[отводя глаза в сторону] Мне "Common Lisp: The Language 2nd" показалась доступнее и приятнее пафосных речей в PCL и On Lisp.... Букварь, всё-так, должен быть сухим и академичным. Для затравки же интереса к теме достаточно было ту самую знаменитую рекламу пера Пола Грэма почитать.

> Этому школьнику по моей оценке в районе 35 лет.

В 35 лет люди более спокойные и пофигистичные (см. на tailgunner'а).

> Народ трахается еще гораздо жестче - вдумчиво читает Стандарт. Лезть во всё это, не имея за плечами хотя бы года практики, нет никакого смысла.

Читается стандарт C++ сравнительно легко, кстати. Как бонус - со временем появляется очень хорошая привычка первым делом лезть в стандарты, если что забыл, и легко в них ориентироваться. Честно говоря, уже забыл сколько лет назад я последний раз заглядывал в книги Страуструпа/Мейерса/Александреску/etc. - когда-то для меня они свою основную задачу выполнили окончательно.

Это от темперамента зависит а не от возраста.

> Это от темперамента зависит а не от возраста.

теперь дурь в голове темпераментом называется? :)

>Читается стандарт C++ сравнительно легко

можно определение типа данных, позволяющего хранить (осуществлять смещение на) ровно один байт? по стандарту ISO/IEC 14882

K&R C - от корки до корки. Остальное - по желанию

А я нашёл там по косвенным признакам что это за тип :).

>А я нашёл там по косвенным признакам что это за тип :).

и который же?

char по стандарту должен быть "достаточно большим чтобы хранить все символы базового набора", этот самый набор гарантированно умещается в байт. но при этом двухбайтный char стандарт не нарушает ни разу

компиляторы ANSI C по непонятным мне причинам (вопреки своему стандарту) считают, что sizeof void == 1, и позволяют выполнять смещение (снова вопреки стандарту) на один байт после приведения к void *. компиляторы C++ этого не позволяют, и хаков для получения гарантированного байта лично я найти так и не смог

вообще говоря, мне из стандарта ни C, ни C++ ответ на поставленный вопрос не очевиден. есть два более-менее корректных подхода - unsigned char как byte (и byte *), либо void *. а так, по существу - implementation-specific. как повезёт, короче говоря

А почему именно unsidned char а не просто char? Я понимаю что он может быть signed, но разве это сильно влияет?

sizeof(char)=1. Так как результат sizeof может быть аргументом malloc а malloc в качестве параметра принимает кол-во байтов то значит char это один байт.

с другой стороны там сказано что любой объект можно представить в виде массива char(пункт 3.9). Т.е. даже те объекты которые занимают несколько байт подряд. Это значит что расстояние между соседними char-элементами равно нулю, иначе бы memcpy не работал так как указано в стандарте.

Притянуто, конечно, за уши :).

>sizeof(char)=1

стандарт этого не гарантирует

>Так как результат sizeof может быть аргументом malloc а malloc в качестве параметра принимает кол-во байтов то значит char это один байт

результат sizeof - константа времени компиляции. и что? вывод насчёт char взят с потолка

>расстояние между соседними char-элементами равно нулю

а расстояние между какими элементами нулю не равно? массив определяется как последовательность в памяти, это ж не список

>иначе бы memcpy не работал так как указано в стандарте

учитывая, что есть системы, на которых sizeof char != 1, утверждение несколько сомнительное

>Притянуто, конечно, за уши

более чем. беда в том, что там или притягивать за уши, или идти против стандарта

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

По поводу одного байта посмотрите stdint.h из C99.

>в стандарте, кстати, ничего не сказано о том как вывести текст на консоль красными буковками

не передёргивай, этого там и не должно быть. а вот аресация байта для языка, позиционируемого как переносной ассемблер (да и просто язык системного уровня) - очевидная необходимость

читая K&R, какого-нибудь Саттера или "stdint.h из C99", решение найти можно. а вот читая стандарт (который якобы читать легко) - хрен там

>В приведенной цитате ничего не говорится о том, что я считаю, что в стандарте C++ каждый человек сможет найти то, что по его мнению обязательно должно быть в любом стандарте

в приведённой цитате говорится, что читать стандарт легко. моё мнение - стандарт что C, что C++ - отвратительные источники базовых знаний о языке, получить с помощью которых нужную информацию практически нереально

>По поводу одного байта посмотрите stdint.h из C99

и что же я там увижу? к слову, стандарт C99 я не смотрел, может там это недоразумение и поправили

Я не передергиваю. Ты просто не понимаешь (или просто решил поспорить на пустом месте) главного: стандарт C++ - это документ, в котором помимо синтаксиса описываются МИНИМАЛЬНЫЕ ГАРАНТИИ касательно тех или иных аспектов языка, поведения функций, алгоритмов и т.д. Ничто не мешает создать полностью соответствующий стандарту компилятор языка C++ на машине, минимальная доступная для адресации единица памяти которой составляет, например, 9 бит. Какие тут байты? Какой "переносной ассемблер"? Причем sizeof(char) на такой машине все равно будет равен 1. Это все описано в стандарте, но ты никогда не найдешь в нем ответа на вопрос "Почему так?", никаких "решений" - для этого существуют другие книги.

Именно поэтому, человеку, полностью не знакомому с языком, прежде чем начать создавать что-то на нем следует для начала почитать более "лирического" Страуструпа, Мейерса или даже что-нибудь попроще. Понять возможности, идеологию, цели, историю языка. А как иначе? Это чрезвычайно сложный и мощный инструмент. Только после этого отпадут обывательские вопросы, а заодно придет понимание, что лучшего источника информации по C++ чем стандарт - не существует. Ты просто заглядываешь в стандарт и смотришь не вышли ли по забывчивости твои предположения за пределы пресловутых минимальных гарантий языка, стандартной библиотеки. Это занимает минимальное время, потому что читается он, бл**ь, легко :)

По существу дискуссии: условие sizeof(char) == 1 всегда и везде истинно (5.3.3 Sizeof), а на системах c 8-битными байтами ты можешь смело приводить указатели к char* и "осуществлять смещение на ровно один байт" (начни с 1.7 The C++ memory model). Только не забывай при этом про ограничения, связанные с выравниванием памяти, т.к. спарки, например, не такие добрые по части адресации как x86.

>Ты просто не понимаешь (или просто решил поспорить на пустом месте) главного

мне регулярно приходится сверятся со стандартом, и сталкиваться с проблемами вроде указанной выше. не от хорошей жизни я его не люблю. и нет, я не решил поспорить на пустом месте,- я просто категорически не согласен с положительной оценкой стандарта C++

>МИНИМАЛЬНЫЕ ГАРАНТИИ

да я не против, лишь бы описывались они лаконично и однозначно

>минимальная доступная для адресации единица памяти которой составляет, например, 9 бит

ок, "возможность адресовать один байт" замени на "возможность адресовать минимальную единицу памяти"

>Причем sizeof(char) на такой машине все равно будет равен 1. Это все описано в стандарте

6.2.5.3: объект типа char должен быть достаточного размера для того, чтобы вместить любой символ из basic execution character set

5.2.1: представление любого символа из source и execution character set должно умещаться в байт

где тут требование равенства одному байту? или у нас какие-то разные стандарты?