bialix (16.12.2007 22:57, просмотров: 208) ответил Evgeny_CD на Вау! Вот оно! Тоже самое можно и на пЫтоне! ->-
- Ну это тоже парадоксы познания. :) Размышляя о системах написания документации, вкуривая (и чертыхаясь) книжки по LaTeX, я что-то понял в мире документации. До этого, я не знал, как может выглядеть то, что я хочу. :) Потом в башке выстроилась Evgeny_CD(297 знак., 16.12.2007 23:05)
- Господи, да что такого с ООП нотацией? То, что func(&obj, param) меняется на obj.func(param) ? Или то, что классы могут надстраиваться один над другим? Или перегрузка операторов? Виртуальные (вызываемые через таблицу указателей) функции? =AlexD=(130 знак., 17.12.2007 08:52)
- Дело не в нотации, а в методологии. В башке выстраивалась именно она. После этого можно и осознанию нотаций переходить :) - Evgeny_CD(17.12.2007 13:47)
- В том и беда, что методология в большинстве книг по Си++ хромает на обе ноги. Отсюда и невразумительный код во многих проектах, помноженный на сложность самого языка :-( - =AlexD=(17.12.2007 14:08)
- а оправданна ли она -- эта сложность? вот в чем вопрос. - bialix_(17.12.2007 14:50)
- Отож. Я этих буков прочитал некоторое количество. Пока буквально несколько дней назад у меня в башке что-то не замкнуло - для меня они были тарабарщиной (именно посему мне интуитивно и не нравился С++ - неизведанное пугает). Теперь перешел на другой Evgeny_CD(11 знак., 17.12.2007 14:15)
- Весьма забавный и поучительный сайт -> - =AlexD=(17.12.2007 14:21, ссылка)
- must read!!! -> - Evgeny_CD(17.12.2007 15:05, ссылка)
- Особенно понравилось - Tумблер(17.12.2007 21:15, ссылка)
- на 100% сотвествует моим мыслям! "Американцы пишут в инструкциях к микроволновым печам «В печи нельзя сушить кошку». Я бы предложил на всех книгах по C++ писать «В C++ нельзя программировать на C». Большинство программистов, считающих себя «программистам Evgeny_CD(61 знак., 17.12.2007 15:01)
- Unix и Linux — вообще отдельная песня. Заставлять пользователя собственноручно скомпилировать программу перед ее использованием — верх бескультурия и безответственности. Операционная система с таким подходом не может быть ориентирована на нормального Ruslan(133 знак., 17.12.2007 15:14)
- В самой компиляции ничего неразумного нет. Наоборот, это грамотный способ выжать все именно из вашей системы. Но!!! Этот процесс должен быть 100% одинаковый везде (как расположение кнопок на клаве)и должен быть полностью автоматическим (make файл юзер и Evgeny_CD(17 знак., 17.12.2007 15:55)
- Линукс давно ставил? "Откинтесь на спинку кресла..." - Vit(17.12.2007 15:22)
- как бы они уже от этого давно отошли. линуксовые юзеры уже давно больше полагаются на готовые пакеты (по виндузному -- это значит на инсталляторы). для меня самого это было открытием годик назад. - bialix_(17.12.2007 15:20)
- Пакет, который в том числе проводит самокомпиляцию - это грамотно. - Evgeny_CD(17.12.2007 15:56)
- Есть и бинарные и сорцовые пакеты. - Vit(17.12.2007 16:17)
- Сорцовые - сильно интересно понять, как у них там все устроено. Когда вся ОСь крутится вокруг некоей суперсистемы на пЫтоне (Gentoo ->) - это понятно. А иначе - слабопонятно. - Evgeny_CD(17.12.2007 16:28, ссылка)
- Есть пакеты, а есть порты. Я их не особенно разделяю, но формально это разные вещи. - Vit(17.12.2007 16:47)
- Почитайте о LFS - Ruslan(17.12.2007 16:33)
- Занятный проект. Давно хотелось бы сним разобраться, да руки не доходят/ -> - Evgeny_CD(17.12.2007 16:36, ссылка)
- Сорцовые - сильно интересно понять, как у них там все устроено. Когда вся ОСь крутится вокруг некоей суперсистемы на пЫтоне (Gentoo ->) - это понятно. А иначе - слабопонятно. - Evgeny_CD(17.12.2007 16:28, ссылка)
- Есть и бинарные и сорцовые пакеты. - Vit(17.12.2007 16:17)
- Пакет, который в том числе проводит самокомпиляцию - это грамотно. - Evgeny_CD(17.12.2007 15:56)
- Unix и Linux — вообще отдельная песня. Заставлять пользователя собственноручно скомпилировать программу перед ее использованием — верх бескультурия и безответственности. Операционная система с таким подходом не может быть ориентирована на нормального Ruslan(133 знак., 17.12.2007 15:14)
- must read!!! -> - Evgeny_CD(17.12.2007 15:05, ссылка)
- Весьма забавный и поучительный сайт -> - =AlexD=(17.12.2007 14:21, ссылка)
- В том и беда, что методология в большинстве книг по Си++ хромает на обе ноги. Отсюда и невразумительный код во многих проектах, помноженный на сложность самого языка :-( - =AlexD=(17.12.2007 14:08)
- Иерархия классов - одна из самых сильных сторон ООП (для меня в текущий момент понимания). Это то, чего мне сильно не хватает в plain C. - Evgeny_CD(17.12.2007 11:09)
- Впрочем, иерархия пространств имён - тоже кульно. - =AlexD=(17.12.2007 12:18)
- иерархия? хотя бы просто пространства имен использовать. а то в плюсах они есть, но их как-то вяло пользуют. все стараются по сишной привычке все скопом свалить из заголовка в си-код. - bialix_(17.12.2007 12:31)
- Дык класс и создаёт пространство имён внутри себя. Что ужЕ хорошо. Ну а издержки похожести Си и Си++ сам автор плюсов предвидел. - =AlexD=(17.12.2007 12:39)
- только внутри класса почемуто никто явно пространства имен не пользует. поэтому оно как бы есть и как бы нема. вместо того, чтобы явно писать this->var, придумывают всякие нотации типа m_var. bialix_(263 знак., 17.12.2007 14:50)
- Я не всегда понимаю, о чём ты говоришь, и это тот самый случай :-). this - это указатель на экземпляр, который скрытно передаётся в методы класса, и заменить его ничем низя. Разве что дублировать в параметрах методов, что будет уже маразмом. - =AlexD=(17.12.2007 15:46)
- Вся фишка в том, что в Питоне этот указатель передается явно. И его нужно все время использовать. В плюсах же ты внутри тела метода волен использовать его или нет. Это не есть гуд. Это нарушение идеи пространства имен. Получаются какие-то магические bialix_(83 знак., 17.12.2007 16:41)
- Ну точно, на разных языках говорим :-). Я не понимаю проблемы , о которой ты говоришь. Честно. Возможно это какие-то чисто питоновские боли. Или кривизна извилин у меня не та. Не знаю. - =AlexD=(18.12.2007 10:08)
- если ты ее не понимаешь, значит ты с ней не сталкивался. возможно, это хорошо для тебя. я не хочу убеждать тебя, что ложка существует. это будет просто напрасная трата времени для нас обоих. По ссылке сравнение объектной модели двух языков, если интересно - bialix_(18.12.2007 15:55, ссылка)
- Я вижу отличия, но я не вижу ПРОБЛЕМЫ. =AlexD=(1026 знак., 19.12.2007 08:19)
- ложки не существует. - bialix_(19.12.2007 12:49)
- Я вижу отличия, но я не вижу ПРОБЛЕМЫ. =AlexD=(1026 знак., 19.12.2007 08:19)
- если ты ее не понимаешь, значит ты с ней не сталкивался. возможно, это хорошо для тебя. я не хочу убеждать тебя, что ложка существует. это будет просто напрасная трата времени для нас обоих. По ссылке сравнение объектной модели двух языков, если интересно - bialix_(18.12.2007 15:55, ссылка)
- Непонятно, в чем именно - нарушение ? Tумблер(377 знак., 17.12.2007 19:34)
- Ну точно, на разных языках говорим :-). Я не понимаю проблемы , о которой ты говоришь. Честно. Возможно это какие-то чисто питоновские боли. Или кривизна извилин у меня не та. Не знаю. - =AlexD=(18.12.2007 10:08)
- Вся фишка в том, что в Питоне этот указатель передается явно. И его нужно все время использовать. В плюсах же ты внутри тела метода волен использовать его или нет. Это не есть гуд. Это нарушение идеи пространства имен. Получаются какие-то магические bialix_(83 знак., 17.12.2007 16:41)
- Я не всегда понимаю, о чём ты говоришь, и это тот самый случай :-). this - это указатель на экземпляр, который скрытно передаётся в методы класса, и заменить его ничем низя. Разве что дублировать в параметрах методов, что будет уже маразмом. - =AlexD=(17.12.2007 15:46)
- только внутри класса почемуто никто явно пространства имен не пользует. поэтому оно как бы есть и как бы нема. вместо того, чтобы явно писать this->var, придумывают всякие нотации типа m_var. bialix_(263 знак., 17.12.2007 14:50)
- В том то вся жопа и есть. Т.е. если даже сильно продвинутый чувак читает буку по С++, он быстро охренеет от количества фич, что-то поймет, на остальное забьет болт, и как-то будет программить. ВНАЧАЛЕ ему надо в самом обобщенном виде объяснить методолгию Evgeny_CD(161 знак., 17.12.2007 12:35)
- Дык класс и создаёт пространство имён внутри себя. Что ужЕ хорошо. Ну а издержки похожести Си и Си++ сам автор плюсов предвидел. - =AlexD=(17.12.2007 12:39)
- Любая иерархия - это способ не сойти с ума и добиться результата в более менее сложном проекте. В голове любого продвинутого человека она есть. Вопрос в том, чтобы с минимальными издержками перенести ее в тулчейн. - Evgeny_CD(17.12.2007 12:20)
- иерархия? хотя бы просто пространства имен использовать. а то в плюсах они есть, но их как-то вяло пользуют. все стараются по сишной привычке все скопом свалить из заголовка в си-код. - bialix_(17.12.2007 12:31)
- О да, приведение типов указателей от больших структур к более мелким подструктурам, полностью контролируемое, надёжное, и скрытое от глаз - это весчь. Сам пользую с удовольствием. - =AlexD=(17.12.2007 12:16)
- +1 - Evgeny_CD(17.12.2007 12:21)
- Впрочем, иерархия пространств имён - тоже кульно. - =AlexD=(17.12.2007 12:18)
- +1. ООП можно на чём угодно делать, даже на asm. Чем ниже, тем бОльший уровень контроля со стороны программиста, за счёт усложнения кода. - VVB(17.12.2007 09:00)
- Дело не в нотации, а в методологии. В башке выстраивалась именно она. После этого можно и осознанию нотаций переходить :) - Evgeny_CD(17.12.2007 13:47)
- Господи, да что такого с ООП нотацией? То, что func(&obj, param) меняется на obj.func(param) ? Или то, что классы могут надстраиваться один над другим? Или перегрузка операторов? Виртуальные (вызываемые через таблицу указателей) функции? =AlexD=(130 знак., 17.12.2007 08:52)
- Ну это тоже парадоксы познания. :) Размышляя о системах написания документации, вкуривая (и чертыхаясь) книжки по LaTeX, я что-то понял в мире документации. До этого, я не знал, как может выглядеть то, что я хочу. :) Потом в башке выстроилась Evgeny_CD(297 знак., 16.12.2007 23:05)