vsev

О! Мой список вопросов "услышал-дай-стулом-в-лоб-собеседующему" только что пополнился еще одним. Спасибо. А в чем проблема? Что UML никто не использует? Очень занятно выглядит - когда в ответ на архитектурный вопрос человек пытается писать ворох кода на C++ и не может нарисовать диаграмму... Да ладно бы нарисовать - но хоть читать то можно наверное, нет? Или это так сложно и тоже ненужный "сфероконь"? Как с таким специалистом работать в коллективе при случае? Если человек не умеет читать UML - это означает что он совершенно далек от ООАД, уж извините, и современных книг он не читал, а лишь чему-то где-то нахватался.

Напоминает. Математику. :) Мне представляется, что на ММФ и ФФ учат учиться (во всяком случае, раньше было так), а на ФИТ, судя по всему, учат работать. Ну и славно. Вполне вероятно, что выпускники ФИТ в среднем ближе к сферическим коням в вакууме т.н. "готовым специалистам", чем в среднем же выпускники ММФ/ФФ, но через год хорошей, плотной работы разницы уже не будет. И что-то я не уверен, у кого будет преимущество при решении нестандартных задач. Впрочем, в ИТ полно задач стандартных (97% ИТ-бюджетов в крупных западных компаниях тратится на поддержание существующих систем в адекватном состоянии), так что "мамы разные нужны, мамы всякие важны". (С) С чего возникло предположение, что на ФИТ не учат учиться а учат только работать? Школа преподавания на ФФ ММФ и ФИТ очень схожая, многие преподаватели одновременно ведут на обоих факультетах, ровно как и очень многие преподаватели ФИТ окончили ФФ. ФИТ вобрал в себя все лучшее что было в свое время на ФТИ ФФ, многие курсы были разработаны специально для ФИТ. ФИТ учит ИТ системно, в отличие от скажем ММФ, где выпускники в основной массе имеют очень отдаленное представление об устройстве ОС, теории ООАД и т.п. Особенно впечатлил меня в свое время первый выпуск (2005) ФИТ, где было очень много сильных специалистов, и многие из которых сделали блестящие карьеры очень быстро (стали архитекторами и менеджерами в первые 2-3 года), хотя курсы тогда были весьма несовершенны (например лекции ООП я вел первый год, и все писал мелом на доске). Те выпускники, с которыми я работал в одном коллективе (правда это были в основном одни из лучших студентов своих выпусков), росли в профессиональном плане очень быстро и с ними лично мне было очень легко работать в силу хорошего багажа знаний полученных во время обучения. Я смело доверял им очень сложные, инновационные задачи и их решениями был доволен. Зачастую достаточно было накидать им основные идеи и направления, которые они уже раскрывали сами. Выпускники ММФ, напротив, оставили не лучшее впечатление, часто зацикливались при решении нетрадиционных задач. За последние 4 года я проводил собеседования несколько сотен человек на должности программистов C++/Java и в большинстве своем выпускники ФИТ показывают лучшие знания предмета чем выпускники ФФ или ММФ, это банальная статистика. Большинство кандидатов, закончивших ММФ и претендующих на должность программистов, с которыми я беседовал, имели очень поверхностные знания по C++, Java и ООП, не умели читать диаграммы на UML, плохо знали SQL, и в этом ничего удивительного нет. Везде есть уникумы, никто не спорит, я знаю много хороших специалистов закончивших в свое время ММФ и ФФ, когда ФИТ (не путаем с ТехФаком) даже не было. Вот буквально на неделе был свидетелем личной драмы человека (на собеседовании), который бросил ФФ после второго курса, из за того что его неправильно сориентировали добрые "шефы" ФМШ. Напели ему в уши песни что на ФИТ учат плохо - а настоящее образование - это ФФ и ММФ. Он их на беду послушал.... А потенциал его меня очень впечатлил, он самостоятельно смог неплохо (на сколько это было возможно в его условиях) освоить C++, очень быстро схватывал когда я ему объяснял на собеседовании глубокие нюансы C++ и объектного подхода, указывал на основные пробелы в его знаниях, и если бы он учился на ФИТ то был бы одним из лучших вне всякого сомнения! Сошлись на том что ему стоит не отчаиваться я поступить снова, уже на ФИТ. Надеюсь его увидеть среди студентов.

Выпускники, которые это говорили, наверное ММФ или ФФ заканчивали, и по-видимому программу ФИТ в глаза не видели? Или смотрят по отделению которое является ТехФаком (тот что на базе ВКИ, и который скоро, слава богу, отделится)? Так это отделение вообще за ФИТ считать сложно - на метод. комиссиях о нем и его программах вообще ни слова как правило не звучит и его проблемы никак не обсуждаются, как будто его и нет вовсе. Если основную математику на ФИТ (алгебра, логика, мат-ан, основы функ. анализа, диффуры, урматы и т.д.) почти по программе МехМата, то как он (ФИТ) может дать меньше навыков для решения задач в области ИТ если та же школа преподавания что и на МехМат? Как человек, который закончил магистратуру ФТИ ФФ и активно участвующий в преподавании на ФИТ с момента его основания, а также в формировании программ ИТ курсов в составе метод-комиссии, могу четко сказать, что ФИТ дает ОГРОМНОЕ преимущество перед выпускниками ФФ и тем более МехМата в области ИТ. На ФФ сильный недостаток специализированной математики, гораздо меньше теоретических курсов по ИТ. Физика, в том объеме, что дается на ФФ в ИТ даром не нужна, и ее в таком объеме нет на ФИТ. Почти никому из моих одногруппников окончивших ФТИ ФФ она не пригодилась, и ее уже практически никто не помнит (за исключением одного человека который после бакалавратуры ФТИ пошел в магистратуру ФЭЧ и стал элементарщиком), хотя у всех в дипломе стоит специальность "Физик". А вот недостаток мат.логики, дискретного анализа и теории алгоритмов, которых нет на ФФ, но есть на ФИТ бьет порой очень сильно. Практические курсы на ФИТ и кафедре ФТИ, например, один-в один в большинстве своем (ООП, ООАД, Сети, БД, графика), так как ведут одни и те же преподаватели. С МехМат так вообще сравнивать смешно - там просто нет нормальных курсов по программированию, архитекутре, базам данных и сетям. Какие задачи в области ИТ решают студенты МехМат пока учатся? На ФИТ - задачи решаются постоянно и помногу, с первого по 6-й курс , пишутся курсовые. По выпуску ФИТ средний студент (ели не законченный разгильдяй) знает и умеет: - Язык С - ООП (основы С++ и как правило неплохо Java) - Архитектуру ОС, системные вызовы Unix, многопоточное программирование - Базы данных, SQL - Сети и протоколы - Основные понятия графики - Объектно-ориентированный анализ, дизайн и проектирование, паттерны проектирования - Основы проектного управления - Имеет представление и кругозор по основным теоритическим напавлениям ИТ (data-mining, информационный поиск, гриды, теория управления и др.) Все данные курсы подкреплены практическими навыками (на них нужно решать задачи и писать курсовые). Как правило студент 4 курса ФИТ уже где-то работает, как минимум, на пол-ставки и к выпуску из магистратуры, например, уже имеет не только профильное образование, но и реальный опыт в производстве коммерческого ПО. А теперь скажите где все это можно изучить, попробовать и получить опыт, скажем, на МехМате?

На программистов не учат, по крайней мере у нас. Можно поступить на какой-нибудь ит-ориенированный факультет, но если вы будете просто ходить в универ и учиться, то закончите обучение перспективным, но никому не нужным человеком с дипломом, который вообще никак не ценится в программировании. Универ - это конечно хорошо, но знания по интересующей тематике вам придется добывать самому (было бы чего добывать - в интеренете полно манов для начинающих). Я бы посоветовал одновременно с обучением начинать фрилансить (как только начнете, так сразу и поймете, что вам нужно изучить), глядишь - к диплому уже и какой-никакой опыт работы будет, а это даст вам просто космическое преимущество по сравнению с товарищами без опыта. "У нас" это где? В Новосибирске? Чем ФИТ НГУ не устраивает как факультет выпускники которого в большинстве своем находят работу по специальности, в том числе программистами, еще ДО ОКОНЧАНИЯ и получения диплома? Добывать знания самому - это долго и не каждый на это достаточно мотивирован, кроме того такой подход оставляет много "мифов" и заблуждений, которые потом трудно искоренить. На ФИТ учат, в том числе и программированию, СИСТЕМНО. "С дипломом который вообще никак не ценится в программировании", простите, кем не ценится? Если говорить о заочном обучении, то действительно, ситуация весьма плачевна, в НГТУ точно не научат.

О! А в каком отделе/проекте в Новософте? Ну в принципе в ответах по использованию UML нет ничего удивительного. Сейчас я и сам использую его только для Use-Case диаграмм на стадии анализа (в основном для подсчетов по метрикам) или документирования идей, ибо постоянно поддерживать соответствие кода модели невозможно да и не нужно. Про Rational Rose - это я в свое время пытался разреверсить проект "Этап", чтобы хоть с какой-то точки зрения на него посмотреть и проанализировать что с ним делать вообще... Такого клубка ужасов я не видел ни до, ни после, хотя Skype плагин для IE меня тоже жестко поразил когда смотрел на его внутренности.

Пусть так. Но для тех, кто предпочитает добавлять cv квалификаторы с помощью const_cast, использование const_cast является валидным и не говорит об ошибках в дизайне. И я ещё раз хочу почеркнуть, что const_cast может использоваться не только для вызова константного метода, т.к. вы все почему-то сосредоточились именно на этом. Можно и не для константного метода разрешать неоднозначность: void f(const int&); void f(int&); void foo(int &i) { f(const_cast<const int&>(i)); } Да не важно - константный метод или константный аргумент - речь идет о том чтобы явно помочь компилятору разрешить параметрический полиморфизм (собственно static_cast для этого обычно и используется). В принципе, с учетом новых реалий, я соглашусь что использование const_cast для добавления константности более строго чем static_cast, которая может говорить об изменении самого типа. Но вот в саму такую ситуацию (с f(int&) и f(const int&)) , на мой взгляд, лучше не попадать. Если функции существенно различаются по своей логике/наполнению (раз не хватило одной функции с const int& аргументом), то на мой взгляд лучше сделать либо разные названия функций, либо для функции, которая потенциально может изменить передаваемый аргумент ( f(int&)) использовать в качестве аргумента указатель f(int*). Т.е. если мы хотим просто оптимизировать передачу аргумента - то нужно использовать константную ссылку, а если мы хотим менять содержимое, то передавать лучше по указателю, чтобы сразу было видно что состояние передаваемого объекта может быть изменено. Тогда в точке вызова сразу будет видно, что объект может измениться: int a; f( &a); //так лучше f (a); // чем так для функции f(int&) , где изменение a может стать сюрпризом для вызвавшего

Это да, тут typedef спасет конечно, но стоит ли оно сильного снижения наглядности? Ведь если мы видим vector<Something> то сразу понятно что это за тип и что с ним можно делать. А если мы видим, скажем Things вместо vector<Thing> - то минимум придется идти и смотреть на typedef чтобы понять что это за Things такие, а это сильно напрягает. Вообще говоря, в C++ рефакторинг делать очень сложно, по сравнению с .NET и Java, поэтому лучше в самом начале 10 раз подумать какой контейнер или паттерн использовать. Помнится в свое время ни один мало-мальски серьезный проект на C++ не удавалось "зареверсить" в Rational Rose, которая тупо умирала после пары часов страданий, в то время как проекты на java сравнимого размера "реверсились" "на ура".

Долго не мог понять про какой квантор всеобщности... Видимо я не точно выразился, или меня не правильно поняли... Я имел ввиду не то, что такое преобразование встречается редко в реальном коде, увы, очень даже часто и повсеместно. Я имел ввиду что если использовать его, то такие места потом очень трудно искать, если задаваться такой целью, в отличие от преобразований xxx_cast. А спорить на тему того как правильно приводить тип чтобы вызвать константный метод (по сути разрешить неоднозначность) - с помощью const_cast или static_cast можно долго, но это бессмысленно. Можно делать и так и так, но мне лично больше нравится подход при котором const_cast используется для снятия константности, а static_cast для разрешения неоднозначности, чтобы именно это "подчеркнуть". В нормально спроектированном коде необходимость в static_cast и const_cast должна возникать очень редко. В C++ можно найти много таких спорных мест, по которым можно очень долго ломать копья с пеной у рта. Кстати, очень часто вижу что многие любят делать подобные вещи: typedef list<Thing> Things; Вот этого категорически не могу понять и принять. Зачем плодить лишние абстракции и типы? Неужели отсохнут пальцы написать list<T> или list<T>::const_iterator ?? Видимо это идет от Microsoft, которая очень любит плодить сущности и разные типы вида LPZSTR. Ладно если оригинальный тип очень длинный - ну там скажем 40-50 символов, тогда еще понятно было бы...

Однако. Откуда вы знаете сколько и какого кода я видел? Считаете себя, видимо, "мегагуру" относительно которого все остальные ничего в жизни не видели? Вы не думали о том, что форум в общем и данную ветку в частности могут читать в том числе и начинающие разработчики на C++? Или форум существует только для того чтобы "отцы" могли "меряться длинной..." ? Иногда лучше лишний раз более подробно объяснить, не закладываясь на высокую квалификацию собеседника. Опытным программистам такие объяснения могут быть и не нужны, но топикстартер, например, захотел узнать как и почему ведет себя компилятор в той или иной ситуации, что я и попытался сделать. Вы же. как я смотрю, очень любите переходить на личности и вешать ярлыки. Можете указать место в моих сообщениях где я себя выделю из толпы относительно других (не важно обоснованно или нет)? Я лишь высказывал свое мнение и те доводы на основании которого оно сформировано.

// Test2.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include<iostream> using namespace std; class A { int a; public: A(int v = 0) : a(v){} A(const A& r):a(r.a) { cout<<"A(const A&)"<<endl; } void f () const { cout<<"f const, a=="<<a<<endl; } void f () { cout<<"f not const a=="<<a<<endl; } }; int main() { A a(1); const A a2(2); a.f(); a2.f(); static_cast<const A>(a).f(); ((const A)a).f(); ((const A&)a).f(); static_cast<const A&>(a).f(); const_cast<const A&>(a).f(); } Рассмотрим данную программу. Допустим задача состоит в том, чтобы у не константного объекта вызвать константный метод. Посмотрим что происходит при разных вариантах преобразования (вывод программы): f not const a==1 f const, a==2 A(const A&) f not const a==1 A(const A&) f not const a==1 f const, a==1 f const, a==1 f const, a==1 Для продолжения нажмите любую клавишу . . . Преобразование к const A дает вызов конструктора копии и в результате вызов не константной функции - нам не подходит. Правильный результат достигается, если мы используем преобразование к константной ссылке с помощью трех способов: - функционального (const A&) - статического static_cast<const A&> - константного const_cast<const A&> Первый способ в C++ считается устаревшим, имеет более низкий приоритет и его трудно найти в коде. Второй способ предназначен для приведения совместимых типов на стадии компиляции - в том числе и для разрешения неоднозначностей. Третий способ формально работает, но const_cast тут используется не по назначению, так как изначально задумывался автором как метод снятия константности и volatile. (См. Б.Страуструп, "Дизайн и эволюция C++", параграф 14.3 "Новая нотация для приведения типов".) В двух словах, static, dynamic и reinterpret не затрагивали константности и для снятия const был введен const_cast. Дословно в русском переводе: "Нотация const_cast<T>(e) призвана заменить (T)e для преобразований, которым нужно получить доступ к данным с модификатором const или volatile". Преобразования вида xxx_cast хороши тем, что их всегда легко найти обычным текстовым поиском в коде программы, и если их использовать по назначению, то можно поймать все интересующие разработчика преобразования. P.S. Если кого-то обидел своим "учительствующим" тоном, то прошу меня извинить - в мыслях не было. Я обычно очень терпимо отношусь к пробелам в знаниях окружающих людей и стремлюсь их по возможности заполнить, если у них есть на то желание...

Что-то, однако, начались переходы на личности. Это вас совершенно не красит. По своему опыту часто наблюдаю, что опытным программистам на C++ часто свойственна заносчивость и высокомерие по отношению к коллегам, что отнюдь не добавляет радости начинающим разработчикам, которые работают с такими "отцами". Даже Страуструп по отношению к C++ как-то говорил что он настолько стал сложным, что даже он его не знает на 100%, хотя казалось-бы кому как не ему... Основное назначение const_cast - это снятие CV квалификаторов (const и volatile). Если необходимо обеспечить разрешение перегрузки, то гораздо уместнее воспользоваться static_cast<const T> () чем добавлять константность с помощью const_cast. Вообще говоря, следует избегать ситуаций, когда такое может понадобиться, так как преобразование из любого T в const T является тривиальным и должно происходить само собой. Упомянутый vector::cbegin (который, кстати появился только в Visual Studio 2010 и в стандарте отсутствует) - сразу показывает что мы хотим получить константный итератор на неконстантный объект вектора и в принципе повышает наглядность, но убивает переносимость.

Лекции призваны, прежде всего, дать общее представление, указать основные ориентиры, типичные грабли, сформировать системный взгляд, что в последствии позволит экономить время при самостоятельной работе. Сами по себе лекции без закрепления практических навыков ничего не дадут. Но, например в Университете, кроме лекций есть еще практические занятия, на которых нужно делать и сдавать задания, а также итоговый экзамен, к которому нужно готовиться. Основное усвоение материала обычно происходит при подготовке к экзамену и при сдаче зачета перед этим. Я в свое время все изучал практически сам, на лекции по ИТ ходил редко (да тогда и проекторов не было, только доска и мел), но глубоко проникся предметом (особенно C++), только после того как начал его преподавать. Самый мрак был когда в магистратуре читал спецкурс по Java (тогда еще была 1.1) собственным одногруппникам, и в результате мне не хватало одного зачета, так как поставить сам себе его не мог :). Не даром говорят, что если хочешь чему то научиться сам, то попробуй научить этому других.

В том, что компилятор вполне может получить значение a перед циклом и больше не перезапрашивать. Это же константа. Это не вспоминая о всяких экзотических архитектурах, типа с тегированной памятью. :) Я тоже сразу подумал о чем-то таком, но однако VC9 тут отработал аккуратно. На g++ не проверял, но думаю будет также. А вообще таких ситуаций и конструкций, безусловно, следует избегать. Не даром говорят что в C++ есть 1001 способ выстрелить себе в ногу. Кстати очень много интересного о таких вот тонких моментах C++ можно прочесть в книге Страуструпа "Дизайн и эволюция C++".

Честно говоря, необходимость в использовании const_cast говорит о серьезных проблемах в дизайне приложения. С точки зрения правильной программы такой необходимости не должно возникать. Однако, к сожалению, стандарт написан очень тяжелым языком, а учитывая что его полностью не поддерживает ни один компилятор, в сложных и спорных моментах лучше написать тест и посмотреть что происходит на той или иной платформе. Более менее сложные программы на C++ обычно, в общем случае, очень плохо переносимы.

#include "stdafx.h" #include<iostream> using namespace std; struct opa; void change_a(const opa&); struct opa { const int a; opa() : a(1) {} void test() { for (int i = 0; i < a; ++i) { change_a(*this); cout<<"test"<<endl; } } }; void change_a(const opa& x) { const_cast<int&>(x.a) = 2; } int main() { opa().test(); } Данная программа выполнит цикл 2 раза, как и должно быть. на первой итерации цикла opa.a == 1 после вызова change_a(*this) значение opa.a станет равно 2 и поэтому цикл выполнится второй раз. а в чем собственно проблема или подвох?

Да, можно. Лекции по ООП обычно проходят в к.223 нового спортивного комплекса НГУ и туда можно пройти свободно. Я каждый раз стремлюсь выбить именно эту аудиторию, чтобы у всех желающих была возможность послушать лекции. Но иногда первый семестр проходит в главном корпуса в БФА (сейчас БА), в принципе туда можно пройти по паспорту если записаться на вахте. Если просто хочется познакомиться с содержимым курса, то все материалы доступны по адресу: http://ccfit.nsu.ru/~rylov

реально когда вы чему-то присваиваете константное поле, если посмотреть ассемблерный код то там идет не присвоение переменных а запись констант, поэтому поменять константное поле, по крайней мере примитивных типов вроде int и float ну нельзя никак при всем желании кроме того подобные штуки (аналогично с const_cast<float*> ) static const float C = 1.0f; float &y = const_cast<float&>( C ); y = 2.0f; - вылетают const_cast хорош тогда когда у нас есть const & или const * на обьект и хочется вызывать не только const-методы и иметь право записи в не-const поля Хм, данный фокус с static const float C не проходит, потому что у страницы памяти в которой она содержится стоит флаг read-only. Однако, следующая программа работает прекрасно: #include "stdafx.h" #include <iostream> using namespace std; const double d = 3.14159; class WithConst { int a; const double d; public: WithConst() : a(0), d(0.0) {} WithConst(int aa, double dd): a(aa), d(dd) {} WithConst& operator=(const WithConst& another) { if (&another == this) return *this; a = another.a; const_cast<double&>(d) = another.d; return *this; } friend ostream& operator << (ostream&, const WithConst&); }; ostream& operator<<(ostream &os, const WithConst& c) { return os<<"WithConst("<<c.a<<", "<<c.d<<")"; } int _tmain(int argc, _TCHAR* argv[]) { const double *pd = &d; cout<<"pd: "<<pd<<endl; double *pd2 = const_cast<double*>(pd); cout<<"pd2: "<<pd2<<endl; //this string will cause error if uncommented //*pd2 = 5.0; cout<<"*pd2: "<<*pd2<<endl; WithConst wc1(1,1.0); WithConst wc2(2,2.0); cout<<"wc1:"<<wc1<<endl; cout<<"wc2:"<<wc2<<endl; wc1=wc2; cout<<"wc1 after = "<<wc1<<endl; WithConst *pwc = new WithConst(3,3.0); cout<<"*pwc: "<<*pwc<<endl; *pwc = wc2; cout<<"*pwc after = "<<*pwc<<endl; return 0; } И дает следующий результат (на Windows XP SP3, VC 9.0): pd: 00402148 pd2: 00402148 *pd2: 3.14159 wc1:WithConst(1, 1) wc2:WithConst(2, 2) wc1 after = WithConst(2, 2) *pwc: WithConst(3, 3) *pwc after = WithConst(2, 2) Для продолжения нажмите любую клавишу . . . Если раскомментировать строчку //*pd2=5.0; то будет ошибка, но именно по тому что pd2 указывает на адрес, где хранится const double d; Однако, когда мы работаем с объектами на стеке (wc1,wc2 в примере) или в динамической памяти (*pwc) константные поля можно изменить через const cast;

А зачем учиться ездить на болиде, если человеку нужен самокат и в гробу он видал конкурентно-способность ? Да и значимость питона для совеременного программирования вы принижаете. Видимо, по незнанию. Вообще-то, если посмотреть на начало темы, то видно, что человек хотел изучить именно C++, что уже указывает на серьезность намерений - т.е. желание учить один из mainstream языков. Но, по моему личному опыту, и по опыту обучения студентов, видно, что C++ учить самостоятельно очень сложно, и главное не очень понятно - почему именно C++? Я посоветовал изучить Java, так как это можно сделать самостоятельно, язык строгий, объектно-ориентированный, с очень развитой библиотекой. Изучив Java, человек познакомится: 1. Со всеми 7 принципами (элементами, как угодно называть можно) объектного подхода/модели 2. Получит знание языка основанного на синтаксисе C, что облегчит адаптацию в будущем к .NET и, при необходимости, C++ 3. Получит знания, которые реально конвертируемы на рынке и помогут ему в дальнейшем при обучении в институте/университете 4. Сможет при желании освоить дополнительно весь спектр от программирования для телефонов до распределенных Enterprise систем. 5. Учить java легко, потому что есть огромное количество tutorials, хороших книг (например написанных Эккелем, Шилдтом) 6. Вокруг есть большое количество программистов и специалистов по Java, у которых можно спросить совет. А теперь скажите, способен ли в контексте данных соображений Python составить конкуренцию Java?

Дайте конкретную ссылку где он это определил, а то получится как по 9-му правилу Чапека: Г.Буч, Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание, Пер. с англ. Невский диалект, издательство Бином, 1998 г. Глава 2. Объектная модель. Параграф 2.2 Составные части объектного подхода. Если говорить о первоисточнике, то вот: Object Oriented Analysis and Design with applications, third edition, Chapter 2 Object Model, 2.3 Elements of the Object Model, p.43 - 71. The Addison-Wesley Object Technologies series. Данная книга является хорошим примером компиляции и осмысления идей. В ней есть ссылки на огромное количество источников. Идеи и нотация Буча были признаны и одобрены в последствии консорциумом Object Management Group, а сам Буч в соавторстве с другими грамотными людьми разрабатывал UML и методологию RUP. Если у кого-то есть сомнения в квалификации Буча, то вот что о нем обычно пишут издатели: Grady Booch is an IBM fellow and author of six best-selling books on object-oriented programming. He is world-reknowned as an originator of OO and founder of UML. Именно такая классификация была выбрана при создании курса ООП для ФИТ, одобрена на ученом совете факультета, согласуется с последующим курсом ООАД. Оба курса читаются уже 10 лет, и требований по их переработке, ровно как и критики теоритических основ не поступало. В конце 90-х хороших книг по этой теме на русском языке было очень мало, и как показала дальнейшая история, более стройного изложения теории ООП найти не удалось, хотя были проанализированы труды Мейера, Грэхема, Элиенса, Мартина, Фаулера, Страуструпа, Мейерса. Все почерпнутое из этих трудов хорошо согласовывалось с принятой изначально классификацией и позволило лишь дополнить и обогатить курс, но не потребовало его переработки. Выбран базис был не случайно, а ввиду чрезвычайного удобства для демонстрации приемов и возможностей основных платформ и языков. До принятия базиса я пробовал читать C++ по Страуструпу и стандарту, а Java по Java Language Specification и труду Ноутона и Шилдта. Сильно не хватало теоритического каркаса, который и удалось найти у Буча. Но, как я говорил, базисов может быть много, упрощенный из четырех принципов тоже можно использовать при изучении C++, но для Java и .NET его маловато.

Буч определил эти принципы как принципы объектного подхода, но да не в этом суть. Методика преподавания на базе рассмотрения поддержки этих принципов в современных языках и платформах себя оправдала. Если хотите познакомиться с таким рассмотрением поближе - можете походить на лекции по ООП в НГУ для ФИТ и ФТИ ФФ, начать лучше с осеннего семестра. Спорить и расписывать философию ОО подхода, что считать, а что не считать принципами ОО программирования - форума не хватит. Грань между ОО дизайном и ОО программированием очень тонка - просто акцент делается на разных вещах. ООП упор делает на взаимодействие отдельных объектов и выражении отношений между классами, а дизайн делает упор на рассмотрении систем и их частей на макро уровне. Принципы же можно отнести и туда, и туда. Подход основанный всего на 4 принципах имеет право на существование и был актуален во времена расцвета С++. Ровно как и структурные и алгоритмические принципы не потеряли свою актуальность на уровне внутреннего устройства классов. Современные системы и языки нельзя рассматривать без особенностей модульности, параллелизма и сохраняемости. А вот Интуит и Wiki не могут являться авторитетами и законодателями в какой либо области. Они могут дать только общее, верхнеуровневое представление. Например интересен тот факт что теорию ООП можно построить вообще без классов - на основе прототипов и иерархии объектов.

Да, кстати вспомнил тут.... Недавно пристально выяснял алгоритмы и стратегию управления динамической памятью (кучей) среды исполнения в современной Windows (с целью рассказа студентам) и выяснил ряд интересных особенностей. Довольно давно менеджер (начиная с VC 7.0) динамической памяти для выделения и высвобождения, а также создания и удаления кучи использует HeapAlloc, HeapFree и иже с ними. Т.е. обращается к операционной системе. Однако, раньше при выделении памяти размером менее 128 байт использовалась служебная область по мере необходимости увеличиваемая но без обращения к Win32 API, с целью уменьшения фрагментации кучи. Для каждого процесса программы откомпилированной Visual Studio по старту выделяется 4 кучи, одна из которых отводится для CRT (malloc, free, new, delete). Начиная с Vista, Microsoft наконец сподобилось реализовать алгоритм корзин (как давно существует в Unix) , в результате чего предел в 128 байт был убран.... НО..... По умолчанию куча работает по старой стратегии - т.е. на каждый чих идет HeapAlloc. Для изменения ситуации можно либо поменять стратегию для кучи CRT для использования "алгоритма корзин" либо поставить вручную предел в 128 байт. Как я подозреваю, Java активно может использовать кучу CRT (если не использует собственный менеджер, честно говоря в исходниках современной машины не рылся), ибо сама реализована на C++. И возможно часть проблем с производительностью, которые отчасти решаются увеличением доступной памяти VM, дополнительно кроется именно в этой особенности.

В нашем проекте используется кодогенерация в большом количестве. Когда мы пытались бороться с тормозами при сборке а также при работе в IDEA под Vista, то что только не перепробовали. И память виртуальной машине увеличивали, и режимы GC переключали, и сервисы индексации вместе с антивирусом глушили, UAC отключали. Что-то помогало, что-то - не очень, картина оставалось удручающей. По воплям возмущения на висту, идею, и java в частности можно было определить кто в текущий момент занимается сборкой или открытием проекта. При этом под XP при той же версии Java машины от того же производителя (Sun) и тех же настройках VM все было относительно нормально и сравнимо с Linux. Панацеей оказался уход всех разработчиков под Ubuntu, где все проблемы исчезли, производительность сборки и индексации в среде выросли в разы. Видимо есть какая-то родовая травма в реализации файловой подсистемы Vista, возможно причина в большом количестве внутренних проверок безопасности и доступа, сбора статистики использования и т.п.

Современные ОО системы, платформы и языки удобно рассматривать в контексте семи принципов (их определяет Буч, ЕМНИП), а именно: 1. Абстракция - собственно выделение классов и интерфейсов (абстракций), где первично поведение а не данные 2. Инкапсуляция - сокрытие особенностей реализации абстракций, в том числе состояния объектов в виде полей-членов 3. Иерархия - упорядочивание абстракций и объектов по уровням ("is a" - наследование, "is like" - родовые компоненты, шаблоны, generics, "part of" - агрегация, композиция), причем наследование лишь частный случай иерархии ("is a") 4. Модульность - разбиение системы на сильно связанные внутри и слабо связанные между собой части. Модульность является краеугольным камнем Объектно-ориентированного дизайна 5. Типизация - проверка типа объектов и защита от неправильного использования а также правила преобразования и приведения типов объектов. Бывает строгой (C++, Java, C#) и слабой (Python, Smalltalk, JavaScript, Perl), статической (на стадии компиляции) и динамической - на стадии исполнения. Так, например, С++, Java, C# - строго типизированные языки с поддержкой статической и динамической типизации Smalltalk, Python - слабо типизированные языки с динамической типизацией. 6. Параллелизм - реализация механизмов синхронизации активных объектов (потоков) при взаимодействии с объектами-серверами, которые могут быть "последовательными", "защищенными", "синхронными" 7. Сохраняемость - механизмы сохранения и восстановления иерархий объектов, а также передача в другое адресное пространство (сериализация-десериализация, ОО базы данных, объектно-реляционные отображения и т.д.) C++ поддерживает 5 прицнипов (все без параллелизма и сохраняемости), а вот C# и Java - все 7. "Полиморфизм" бывает в свою очередь параметрическим (выведение параметров шаблонов, разрешение перегрузки функций) и виртуальным (союз типизации, наследования (иерархии) и динамического связывания).

Distance dist2(5, 10.25); Объект проинициализирован конструктором, конструктор вызвался один раз. далее dist2 = mtrs; Работает, как правильно сказал MuratMusic, не конструктор, а именно оператор присваивания, который в классе явно не задан, поэтому его код генерируется компилятором. По сути в этой точке происходит следующий вызов: dist2.operator=(Distance(mtrs)); Однако та версия что сгенерирована компилятором, почленно присваивает/копирует содержимое и ошибка получается при попытке присваивания константного поля-члена MTF. В случае статической константы поле выводится из объекта в область статической памяти и инициализируется один раз при запуске программы до начала работы main. Для решения проблемы достаточно реализовать оператор присваивания вручную, не забывая проверить на присваивание самому себе, например так: Distance::operator=(const Distance& another) { if( this == &another) return; feet = another.feet; inches = another.inches; } А вообще, в приведенном классе, с точки зрения дизайна, константа MTF должна быть статической. Если таки нужно, по каким-то крайним соображениям, изменить константное поле, то можно воспользоваться const_cast

Проблема скорее не в Eclipse как таковой, а именно в Vista Home, у которой очень медленные файловые операции при указанных условиях (много файлов и каталогов). Причем Vista с файлами работает сильно медленнее чем XP при тех же условиях. Разница во времени сборки большого проекта, особенно если при этом задействована кодогенерация, на Vista (причем не важно на NTFS или FAT32) и Linux (ext3, ext4) очень велика и доходит до 3-5 раз. Причем отключение параметра в реестре, который отвечает за запись информации последнего обращения к файлу в Vista мало помогает. Отключение антивируса улучшает картину, но незначительно. Как автор пишет, под Kubuntu все нормально - что указывает на проблемы именно с OS и FS.