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

Обыкновенные там зарплаты , в районе 2000 вечнозеленых(обычный шарповый или джавовский быдлокодер).
Murr за такие бабки даже переменную не объявит .

чем сложности трудоустройства в Москве
------
Да никакой сложности. Берем текущую стоимость трехкомнатной квартиры в 20 минутах от места работы, делим на пять и как только предлагается работа с такой зарплатой - так и устраиваемся... ну еще добавим мелочевку - подъемных на начальный взнос за квартиру и пятилетний трудовой договор с обязательной выплатой всей зарплаты и возможностью расторжения, если условия работы изменяются и изменения не устраивают... Пока таких работодателей там не видно...
Кстати, у меня за окном - +12С... :)

Ну да ладно... не объявит... объявит... может даже десяток... :)
А вот чувствовать себя быдлокодером он явно не любит... :)

\Бардак это не от языка. Бардак это от программера.
Видимо я не совсем првильное слово употребил. У тебя возникла ассоциация с плохо написанной программой. Может тогда извращение?
\Разумеется. Потому 100% этих операций и доверили строить компилятору.
Так я о чем, зачем от этого отходить
\Если забираться в дебри Сей, то там есть возможность указать, что функция доступна в пределах компилируемой единицы.
если ты имеешь в виду static то это совсем другое. Это фактически прайвед функции. Я имел виду публик. Если фукция А не определена в классе В то ты ее по недосмотру не вызовешь.
\Но опять - ты подменяешь концеп реализацией в конкретном языке.
Я только хочу сказать, что от этого концепта нифига не останется, кроме структур данных \которые к тому же доступны откуда возможно\
\Это - без разницы, при наличии квалифицированного персонала.
Разница все равно будет, какая бы квалификация не была бы, от ошибок никто не застрахован. Чем раньше они выявляются тем лучше. Тем более в чужом коде ты почти всегда в потемках. Даже в тех же плюсах реализация дополнительного кода в неправильном месте, может привести к "непонятным" ошибкам.
\Резервируешь в каждой реализации объекта пару специфических методов - Конструктор и Деструктор и отсутствие базы тебя более не беспокоит.
Угу, а потом думать как и когда их вызвать.
Мне вот пришлось поработать с не микрософтовским компилятором С++. Так долго не мог понять почему одна часть кода абсолютно неправильно себя ведет. Оказалось что для статически определенных объектов конструкторы просто не вызываются.

Может тогда извращение?
Так я о чем, зачем от этого отходить
-----
Такое словосочетание как - регламент заказчика - наверное знаешь.
У меня, при той реализации на ASP, была возможность сделать реализацию на JSP, но у заказчика не было возможности пользовать JSP.
Если фукция А не определена в классе В то ты ее по недосмотру не вызовешь.
-----
Дисциплина, еще раз дисциплина и квалификация. Что эмулировать вкусные виртуальности в языке не имеющем оных сложнее принимем как аксиому... В помощь можно, за пару дней, написать простенькую прожку, вычленяющую функции из реализации и делающую примитивный анализ на предмет отсутствия необходимых в имплементации...
Я только хочу сказать, что от этого концепта нифига не останется
-----
Опять тоже самое - тебе нужны рееплементации концепта выполненные средствами другого языка...
от ошибок никто не застрахован.
-----
Разумеется. Но при квалифицированном персонале вероятность ошибок меньше. А как именно производится реализация - действительно не столь существенно - совершенно незначительный овехед в коде, данных и трудозатратах на поддержание при нормально обученном персонале. Скажем примерно так - реализация виртуального метода в С++ требует его декларации в заголовке и написания соответствующего кода в реализации, реализация аналогичного "метода средствами" Сей - инициализации одного/двух элементов статического массива и написания иплементации... эквивалентные (примерно) по сложности задачи.
Тем более в чужом коде ты почти всегда в потемках.
-----
Заметь - тут ты абстрагировался от конкретного Языка и приблизился к ООП-концепту...
Угу, а потом думать как и когда их вызвать.
-----
Точно там же и точно так же, где и как ты вызываешь new & delete. Плюс, разумеется, дополнительный вызов базового в потомке. Это же обычное дублирование С++ поведения.
кроме структур данных, которые к тому же доступны откуда возможно
-----
??? - Изолируйся в реализации. Никто же не принуждает тебя работать со статически размещенными структурами. В идеале в реализации будет всего одна доступная переменная - указатель на приложение... точно так же как в жабе. :)
Оказалось что для статически определенных объектов конструкторы просто не вызываются.
-----
Угу... В Борланде - так же... для невиртуальных конструкторов.
Дополнительно - при Сишной эмуляции не будет подобных ошибок - сишные функции всегда вызываются по месту... Ну инлайновые опустим...

\Такое словосочетание как - регламент заказчика - наверное знаешь.
Ну если требует С, то всяких "извращений" обычно низзя.
\Дисциплина, еще раз дисциплина и квалификация.
Это не спасает. Двольно известно высказывание, что если ошибка может появится то рано или поздно она появится.
\В помощь можно, за пару дней, написать простенькую прожку,
тогда уж лучше С плюсный компайлер выдающий результат на С.
\рееплементации концепта выполненные средствами другого языка
Но это будет уже другой концепт.
\эквивалентные (примерно) по сложности задачи.
Но совсем не эквивалентные ао суппорту и развитию.
\Точно там же и точно так же, где и как ты вызываешь new & delete
А если я их не вызываю?
\Никто же не принуждает тебя работать со статически размещенными структурами
И как ты при динамическом размещении запретишь доступ к отдельным полям в сях? Кстати, был проект где динамическое выделение памяти было просто напросто запрещено.
\Угу... В Борланде - так же... для невиртуальных конструкторов.
А чем это мотивировано, и каким образом конструктор может быть виртуальным?
\Дополнительно - при Сишной эмуляции не будет подобных ошибок
Но там будет валом других ошибок, ведь многие вещи, которые делаются "автоматом" нужно будет ручками делать.

Но это будет уже другой концепт.
-----
Ну хорошо. Возьмем следующий концепт:
- абстрактный класс
- грязный класс
- чистый виртуальный метод
- виртуальный метод
Концепт предполагает простое наследование.
Абстрактный класс - наследуется, если нужно, от другого абстрактного класса, не содержит полей данных, содержит по крайней мере один чистый виртуальны метод.
Грязный класс - класс наследуемый от абстрактного класса или от другого грязного класса, обязан содержать локальные поля данных.
Чистый виртуальный метод - виртуальный метод изначально определенный в абстрактном классе и имплементируемый в каждом наследующем классе.
Вируальный метод - классический (плюсовый) виртуальный метод.
Разница между чистым виртуальным методом и виртуальным методом.
Концепт требует имплементации чистого виртуального метода в каждом классе иерархии, исключая абстрактные, в случае отсутствия имплементации должна возникать отслеживаемая ошбочная ситуация.
Для виртуального метода не требуется имплементация в каждом классе, при отсутствии имплементации вызывается соответствующий метод базового класса.
Суть этих требований - чистый виртуальный метод используется в ситуациях, когда необходима операция, эквивалентная сериализации/десериализации, на каждом уровне наследования, а виртальные метод - отрисовка объекта (см. ниже Draw()).
Этот концепт ты в состоянии реализовать на С++, хотя будеш ругаться на необходимость отслеживать чистые виртуальные методы и писать заглушки на каждом уровне...
Продолжение концепта.
- чистый класс - класс, наследуемый от грязного класса и не имеющий полей данных.
- пустой виртуальный метод - метод не содержащий в себе полезной функциональной нагрузки, кроме вызова аналогичного метода базового класса или обработки ошибочного вызова и их комбинации с условиями.
Чистый класс вводится чтобы исключить необходимость переделывать код на уровне приложения, оперирующего конкретными понятиями. Например, есть ряд классов
ПроизвольнаяЛоманая->ЗамкнутаяПроизвольнаяЛоманная->ВыпуклыеМногоугольники,
ВыпуклыеМногоугольники->Треугольник,
ВыпуклыеМногоугольники->Прямоугольник,
ВыпуклыеМногоугольники->Трапеция,
ВыпуклыеМногоугольники->Пятиугольник и etc...
Классы Треугольник, Прямоугольник, Трапеция, Пятиугольник являются чистыми, т.е. не содержат никаких элементов данных, но позволяют проверить и ограничить количество рисуемых отрезков.
Последняя имплементация виртуального метода Draw() определен на уровне ЗамкнутаяПроизвольнаяЛоманная и позволяет отобразить заданную ломаную как замкнутую фигуру.
Пустой виртуальный метод введен для уменьшения объема кодирования. Поскольку метод не содержит полезной функциональной нагрузки его имплементация запрещена в данном концепте.
В данном месте у тебя должны возникнуть вопросы:
- Как имплементировать заглушки в грязных классах, все данные которых не используются в сериализации/десериализации?
- Как имплементировать заглушки для чистых виртуальных методов в чистых классах, если их имплементация одновремнно требуется и запрещена концептом?
Собственно, над вопросами работать тебе. Ответ можно дать в двух вариантах:
- найти нелогичность в концепте,
- указать подходящее средство имплементации...
А если я их не вызываю?
-----
Тогда ты их имплементируешь и не вызываешь.
И как ты при динамическом размещении запретишь доступ к отдельным полям в сях?
-----
Недоступностью указателя на структуру. Просто физической невозможностью его получить.
Кстати, был проект где динамическое выделение памяти было просто напросто запрещено.
------
Ну и как, при наличии таких требований в концепте, ты его будешь реализовывать при использовании С++ объектов? Плюсовый new в обязательном порядке выполняет динамическую аллокацию.
А чем это мотивировано, и каким образом конструктор может быть виртуальным?
------
А что он может быть виртуальным - само по себе не проблема.
Чем мотивировано - не знаю, надо спрашивать у разработчиков, но скорее всего тем, что используемая в Билдере VCL написана на (Б)Паскале, а в нем конструкторы могут быть виртуальными и при наследовании с этой виртуальностью надо что-то делать.
Но там будет валом других ошибок
------
Смотри заданный выше концепт и выбери наименее глючный тоолс для реализации... :)

\Ну хорошо. Возьмем следующий концепт:
Для чего?
\Собственно, над вопросами работать тебе
Зачем? Чисто поиграться?
Для меня правда понятие концепт больше похож на УМЛ диаграмму, чем на сборник неизвестных словосочетаний.
\В данном месте у тебя должны возникнуть вопросы
Ничего не возникло, надо вначале в концепт въехать.
\Как имплементировать заглушки в грязных классах, все данные которых не используются в сериализации/десериализации?
Никто не определял ,что у нас только сериализации/десериализации. Но если "все данные которых не используются в сериализации/десериализации" то эти данные не "нужны" они не определяют состояние нашего объекта.
\Как имплементировать заглушки для чистых виртуальных методов в чистых классах, если их имплементация одновремнно требуется и запрещена концептом?
Если разрешено то делаем, если не разрешено то не делаем, если непонятно спрашиваем автора\шефа как требуется\хочется.
\А если я их не вызываю?
\-----
\Тогда ты их имплементируешь и не вызываешь.
Я имел в виду, что их компайлер их за меня вызывает.
\Недоступностью указателя на структуру. Просто физической невозможностью его получить.
Так а если структура мне нужна, точнее только часть структуры? Все запрятать можно, это скажем аналог прайвед. Либо скажем я делаю структуру снаружи, а не внутри.
\Плюсовый new в обязательном порядке выполняет динамическую аллокацию
А почему я обязан использовать динамическую аллокацию? Есть еще стек и статика. Конечно это прибъет хорошенько, но если низзя.
\А что он может быть виртуальным - само по себе не проблема.
Смотря как это определить. Если конструктор должен создать конкретный объект, а виртуальная фунция использует данные уже созданного объекта, то это проблематично уже по определению.
Можно правда определить "виртуальный" конструктор как конструктор создающий объекты "неизвестные" на этапе компиляции.
В любом случае, я не вижу причины почему для статически создаваемых объектов не должен вызываться конструктор, ведь при создании объекта нам просто нужен конструктор по определению. Другое дело, что для их вызова нужно хорошо извратится.
\Смотри заданный выше концепт и выбери наименее глючный тоолс для реализации... :)
Я знаю :) Кодогенератор мурра!
\Этот концепт ты в состоянии реализовать на С++, хотя будеш ругаться на необходимость отслеживать чистые виртуальные методы и писать заглушки на каждом уровне...
Не буду, я сам так иногда делаю, правда абстрация заканчивается на первом же уровне и это мне кажется это более правильным.
\Классы Треугольник, Прямоугольник, Трапеция, Пятиугольник являются чистыми, т.е. не содержат никаких элементов данных, но позволяют проверить и ограничить количество рисуемых отрезков.
Зачем? У меня есть Н выпуклый многоугольник он уже знает количество отрезков пусть и проверяет, в крайнем случае можно еще один класс заделать, а не новый на каждую фигуру. Вот если каждая фигура имеет специфические аттрибуты\операции тогда можно подумать.
\указать подходящее средство имплементации...
Обычно когда делается концепт имплементация уже известна. Иначе какой смысл проектировать то, что нельзя нормально реализовать. Хотя на первом этапе итерации этот вопрос и может возникнуть.

Для меня правда понятие концепт больше похож на
-----
Как определен концепт - совершенно не принципиально. Могу накидать хоть заголовоки классов с комментариями в качестве определений.
Если разрешено то делаем, если не разрешено то не делаем, если непонятно спрашиваем автора\шефа как требуется\хочется.
-----
Именно это и написано в концепте. Одновременно - требуется и запрещено. Требуется, потому что для чистой виртуальной функции концептом требуется обязательная имплементация. И - запрещено, потому что чистый класс не имеет полей и имплементация вырождается в пустую виртуальную функцию. Требование, кстати, совершенно логичное, при условии что чистый класс всегда агрегируется.
то эти данные не "нужны"
------
Угу... именно по-этому концепт запрещает создание пустых виртуальных методов, требуя, однако, наличия метода или обработки ошибки вызова в контексте объекта. Фактически, наличие этой ситуации определяет, что в построении иерархии классов допущена ошибка.
Я знаю :) Кодогенератор мурра!
------
Кодогенератор Мурр'а тебе тут не поможет. Ищи другой тоолс... :)
Вот если каждая фигура имеет специфические аттрибуты\операции тогда можно подумать.
-----
Имеет. Но это не поля(аттрибуты) так как поля не разрешены концептом для чистых классов. Она определяет необходимое и достаточное условие существования фигуры. В противном случае тебе придется определять их во внешнем коде, что концепт косвенно запрещает, требуя использования чистых классов на уровне приложения.
Обычно когда делается концепт имплементация уже известна.
-----
Концеп для того и делается, чтобы оценить требования и выбрать подходяций инструментарий. Бо, если есть имплементация, то написать всеохватывающий концепт практически невозможно из-за различий в деталях имплементации отдельных элементов.
Иначе какой смысл проектировать то, что нельзя нормально реализовать
------
Ну хотя бы чтобы оценить ограниченность С++ концепта... :)
Заодно - имплементация указанного концепта средствами Сей, отличается от имплементации эмуляции виртуальных функций всего в двух местах - одно дополнительное поле - признак чистой виртуальной функции - в таблице виртуальных функций и дополнительная проверка этого поля при отработке ошибочного вызова... Собственно для демонстрации этого Я и написал концепт, не вписывающийся в С++ реализацию, но без проблем реализуемый в Сях. :)
===========
\Тогда ты их имплементируешь и не вызываешь.
Я имел в виду, что их компайлер их за меня вызывает.
-----
И new & delete ты сам никогда не пишешь? ;-) Вот их и заменяешь на вызовы.
Так а если структура мне нужна, точнее только часть структуры?
-----
В ООП? ;-)
А почему я обязан использовать динамическую аллокацию?
------
А у тебя есть выбор при использовании new & delete ?
я не вижу причины почему для статически создаваемых объектов не должен вызываться конструктор
------
А он "вызывается". На этапе трансляции. В результате объект полностью определен и аллоцирован. Виртуальность конструктора в данном случае как раз запрещает это делать и принуждает выполнять реальный вызов.
это проблематично уже по определению
------
И тем не мение даже в C# можно в конструкторе ссылаться на себя, хотя объект еще не готов, все транслируется... и валится на выполнении.

\Как определен концепт - совершенно не принципиально
Да, в принципе это дело привычки. Хотя я бы это назвал требованиями к ПО.
\Именно это и написано в концепте. Одновременно - требуется и запрещено.
Тогда это либо неправильный концепт, либо нужно найти обходной маневр.
\Концеп для того и делается, чтобы оценить требования и выбрать подходяций инструментари
Опять таки завит от того что вкладывать в значение слова концепт.
Можно говорить как об инновационном концепте, так и о концепте конкретной реализации, так и о еще чем-то.
\Ну хотя бы чтобы оценить ограниченность С++ концепта..
Любая реализация имеет ограниченность. Но если мне это ограниченность не сильно мешает то почему бы не пользоваться ей. /реализацией/
\Заодно - имплементация указанного концепта средствами Сей,
Да я так и думал, что ты к этому клонишь. Но нафига это делать. Ну получим мы требуемое поведение, но имплементация и получится то что я называю бардаком. Кроме автора никто не разберется. Да и все будет отлавливаться на этапе выполнения, а не компиляции. То бишь плюсы сомнительны, а минусы очевидны. Лучше концепт подогнать под удобную реализацию.
\Так а если структура мне нужна, точнее только часть структуры?
\-----
\В ООП?
Не, в сях. Кпроме как упаковывать данные в структуртуру я не вижу другого выхода. Но в этом случае части структуры должны быть недоступны для доступа.
\А почему я обязан использовать динамическую аллокацию?
\------
\А у тебя есть выбор при использовании new & delete ?
Что мешает мне записать А а; вместо A* рa = new A;
\А он "вызывается". На этапе трансляции. В результате объект полностью определен и аллоцирован.
Чего - то я не понимаю, каким образом компилятор может проинициализировать объект, если конкретная память под него выделится только на этапе запуска программы.
\Виртуальность конструктора в данном случае как раз запрещает это делать и принуждает выполнять реальный вызов.
Может я забыл уже чего-то. Но разве Мелкософт пользует виртуальные конструкторы? Во всяком случае ихнии стабы отрабатывали конструкторы и деструкторы как ожидалось.
\И тем не мение даже в C# можно в конструкторе ссылаться на себя, хотя объект еще не готов, все транслируется... и валится на выполнении.
Дрессировка не позволяла это пробовать, но будем это считать ограничением текущей реализации.

Тогда это либо неправильный концепт, либо нужно найти обходной маневр.
-----
Да нет, концепт - правильный. По крайней мере ты не указал ни одной нелогичности в концепте.
Просто данный концепт требует иметь в реализации два типа виртуальных функций с различным поведением. Примеряя его на С++ ты получаешь проблему - С++ предоставляет только один тип.
так и о концепте конкретной реализации
-----
Ты уверен, что сможешь создать концепт по конкретной реализации? Это примерно тоже, что по значению 4 обосновать что это было 2 + 2...
то почему бы не пользоваться ей.
------
Я уже предлогал оценить возможный тоолс для реализации заданного концепта. Прими как аксиому - Концепт - первичен, имплементация - вторична. И - имплементация, не соответствующая концепту не является имплементацией концепта.
То бишь плюсы сомнительны, а минусы очевидны.
------
Пока имеется обратная ситуация - концепт, как он определен, дает ощутимые преимущества, принуждая делать корректную имплементацию и позволяя превентивно избегать части архитектурных ошибок и быстро отслеживать часть ошибок имплементации. Очевиден только один минус - трудозатраты в реализации на С++ сравнимы с трудозатратами в Сях... :)
Лучше концепт подогнать под удобную реализацию.
-----
В Генераторе была сделана одна маленькая инновация - концептуально было установлено, что любая пара - источник данных + визуальный контрол - должены быть совместимы по обмену данными. Т.е. в любом месте пишем - контрол.значение = данные.значение - получаем отображение, пишем - данные.значение = контрол.значение - получаем сохранение пользовательского ввода. Объем кода, как шаблонов, так и продуцированного существенно снизился. Косвенно, отпала необходимость изменять шаблоны при введении новых контролов и источников данных, появилась возможность не думать об том как заменить тип контрола. Будем подгонять или делать имплементацию? :)
Но в этом случае части структуры должны быть недоступны для доступа.
-----
Перекрой доступ к структуре. Это же основная практика ООП - все через методы, никакого прямого доступа к данным.
Что мешает мне записать А а; вместо A* рa = new A;
-----
Ах, это... отвык - в СБилдере это просто не разрешается для копонентных классов. Придется писать вызовы, явно определяя время существования. Что поделаешь - небольшие издержки системы имплементации.
каким образом компилятор может проинициализировать объект, если конкретная память под него выделится только на этапе запуска программы
-----
Память под статический объект выделяется на этапе трансляции - размер области данных под класс компилятору известен, размещение таблицы виртуальных функций - тоже. Выделяется точно так же, как для любых статических переменных. Проблема только в одном - если внутри конструктора используется дополнительное, не С++, аллоцирование памяти, то оно не выполняется. Собственно отсюда появлся концепт синглентона в части замены статических элементов.
Но разве Мелкософт пользует виртуальные конструкторы?
-----
Понятия не имею. По возможности держусь... держался - до С#... подальше от поделок билли...

\Да нет, концепт - правильный.
Смотря с какой стороны посмотреть. Если есть взаимоисключающие правила, то это уже неправильно. Пусть даже по отдельности эти правила верны.
\Просто данный концепт требует иметь в реализации два типа виртуальных функций с различным поведением.
Ну тогда это просто просто разные дороги и функции должны называться как то по другому что бы не вводить в заблуждение.
\Ты уверен, что сможешь создать концепт по конкретной реализации?
Ты не так меня понял. Я имел в виду что у меня была задача и я набросал концепт ее реализации.
\Прими как аксиому - Концепт - первичен, имплементация - вторична.
Можно согласится, с тем условием, что если концепт нельзя реализовать нормально в желаемой реалиции, то такой концепт нам нафиг не нужен.
\Пока имеется обратная ситуация - концепт, как он определен, дает ощутимые преимущества
Вполне возможно, что для построения компилятора С+++ это был бы и неплохой концепт, но если мне надо сделать прогу для рисования многоугольников то ну его нафик.
\Будем подгонять или делать имплементацию?
Ну не стричь же всех под одну стрижку. Считаем плюсы, минусы данного требования концепта против сложности реализации.
\Перекрой доступ к структуре.
Каким образом? Когда мне ее как параметр в функцию передавать.
\Память под статический объект выделяется на этапе трансляции
Я бы сказал резервируется место требуемого объема. А конкретный адрес будет задействован когда система загрузит нашу программу. Но мне никто не запрещает вызввать в конструкторе оператор нью или другие фунции. Кроме этого поведение конструктора может зависеть от входных параметров, которые могут быть просто неизвестны на этапе компиляции.
Хотя в стандарте я не нашел прямого указания \может и есть где-то\ когда вызывается конструктор но 12.1.2 я могу интерпретировать только как непосредственный вызов конструктора, как иначе мне проиницилизировать память конкретными значениями. Ну и кстати, виртуальных конструторов быть не должно.
12.1 - Constructors [class.ctor]
2- A constructor is used to initialize objects of its class type.
4- A constructor shall not be virtual (class.virtual) or static (class.static).
\СБилдере это просто не разрешается для копонентных классов
Ну это уже издержки конкретной реализации.
\По возможности держусь... держался - до С#... подальше от поделок билли
Знаешь, когда надо было только на МС работать тоже кляли его со всех сторон. Когда попробовал другие продукты, тоже по нужде, то стал уже жалеть по нему. По крайней мере, лучше МСДН я ничего не знаю.
Хотя что было было бы с конторой Била если бы они не сманили архитетора с Борланда. Не знаю застал, ли ты Турбо Визион , но идея Студио Нета сильно его напоминат. По крайней мере визуальное наследование форм там было лучше реализовано лет еще 20 назад.

Если есть взаимоисключающие правила, то это уже неправильно.
------
Там _нет_ взаимоисключающих правил. Проблема не в концепте, а в выборе инструмента реализации.
Ну тогда это просто просто разные дороги и функции должны называться как то по другому что бы не вводить в заблуждение.
-----
Потому и описано что их две и как каждая из них должна функционировать...
с тем условием, что если концепт нельзя реализовать нормально в желаемой реалиции, то такой концепт нам нафиг не нужен.
-----
Упсс... возвращаемся к ассемблеру, а то и машинному коду... Бо, все остальное - ограниченные концепты, не позволяющие получить "желаемые реализации".
но если мне надо сделать прогу для рисования многоугольников то ну его нафик.
-----
Ну вот... опять возвращаемся к базовым моментам - ответ принимается в двух вариантах
- предлагаемый тоолс реализации
- нелогичность концпта.
Пока же, все что ты сказал, что задачу ты в состоянии реализовать с использованием другого концепта, но не сказал в чем его преимущества перед данным.
Считаем плюсы, минусы данного требования концепта против сложности реализации.
-----
Так практически одни минусы... за исключением того, что с шаблонами для сотни-другой типов контролов справится будет весьма проблемматично. Меня бошльше интересует, почему билли, имея перед глазами примеры подобных концептов не пожелал наработать что-то подобное, вводя ДотНет? Там ведь не так много работы - Я управился за три недели...
Каким образом?
-----
Ну хотя бы парой ключ-ссылка.
Ну это уже издержки конкретной реализации.
-----
Разумеется. Просто мне больше приходится работать именно с этой реализацией... и ее нарушениями стандарта.
Знаешь, когда надо было только на МС работать тоже кляли его со всех сторон.
Когда попробовал другие продукты, тоже по нужде, то стал уже жалеть по нему.
Хотя что было было бы с конторой Била если бы они не сманили архитетора с Борланда.
------
Нее, спасибки... от работы на всем что до ДотНет - отказываюсь, если это основной инструмент. Мне там просто неудобно т.к. привык к Борландовским примочкам.
Помнится, надо было переделывать уже начатый тяжелый проект... людей - всего ниченого - сам, консультант, менеджер на полставки и студент на полставки... все. Т.е. либо делать все самому, либо брать подходящий инструмент и всю мелочевку сваливать на студента с консультантом... через 2-3 недели они это и делали... на БСБ 5.0... Сколько бы Я им должен был объяснять как тоже самое делать на ВС6.0 - не знаю...
По крайней мере, лучше МСДН я ничего не знаю.
-----
Это - да. Но только пока не начинаешь вникать достаточно глубоко. Когда начинаешь - выясняется сколько именно нужной информации там отсутствует.
Не знаю застал, ли ты Турбо Визион , но идея Студио Нета сильно его напоминат.
-----
Застал. Даже то, что было до него застал... Первая система - ОСРВ СМ-1 и Фортран-2...
А с ТВ... когда-то делел порт, базирующийся на том, что сейчас называется интерфейсами... Правда не через абстрактные классы, а через дефайны, но кода там существенно поубавилось... хотя сложность восприятия архитектуры вроде возросла...

\Там _нет_ взаимоисключающих правил. Проблема не в концепте, а в выборе инструмента реализации.
Сам же писал
"Как имплементировать заглушки для чистых виртуальных методов в чистых классах, если их имплементация одновремнно требуется и запрещена концептом?"
\Потому и описано что их две и как каждая из них должна функционировать...
Надо будет ще раз перечитать, не помню, что бы про две было.
\возвращаемся к ассемблеру, а то и машинному коду.
В ассемблере или машинном коде он мне тем более не нужен.
\но не сказал в чем его преимущества перед данным.
Только то , что он будет проще в реализации.
\Ну хотя бы парой ключ-ссылка.
А подробней можно? Чего-то сразу не дошло. Что еще один промежуточный слой делать?
\Мне там просто неудобно т.к. привык к Борландовским примочкам.
Дело привычки. Я тоже в сыое время плевался. А вот недавно надо было простую формочку сделать и на компе ничего не было кроме борланда и МСДН. Застрял на каком- то простом месте и выхода так и не нашел. Не помню уже точно что, но вроде текст надо было взять с контрола.
\Меня бошльше интересует, почему билли, имея перед глазами примеры подобных концептов не пожелал наработать что-то подобное, вводя ДотНет
Так они делают токи для себя, а не для пользователей. Все классы и библиотеки части развития студии и возможно виндов.
Предствляешь, как я матерился, когда диалог на бордланде можно было за полчаса сбацать, а на билле целый день надо было сидеть.
\Это - да. Но только пока не начинаешь вникать достаточно глубоко. Когда начинаешь - выясняется сколько именно нужной информации там отсутствует.
Это всегда так, чем больше знаешь, тем больше понимаешь сколько еще не знаешь. Уж не помню кто сказал.
\Первая система - ОСРВ СМ-1 и Фортран-2
Я помню только названия: СМ2 и Фортран 4, правда как ос называлась на громадной ИБМ не помню уже.

"Как имплементировать заглушки для чистых виртуальных методов в чистых классах, если их имплементация одновремнно требуется и запрещена концептом?"
-----
Я писал, что у тебя должен возникнуть такой вопрос. И писал именно потому, что знал, что ты будешь оценивать концепт с позиции С++-имплементации. В самом концепте такого противоречия нет.
Только то , что он будет проще в реализации.
-----
Да ну? У меня вот получается, что будут весьма приятные преимущества, при реализации которых трудозатраты будут примерно одинаковы у С и С++...
В ассемблере или машинном коде он мне тем более не нужен.
-----
Разве? Эти две позиции всего лишь индицируют, что ниже спустится уже нельзя, а не отсутствие концепта. А вот чтобы перейти хотя бы к Фортрану - нужен новый коцепт.
Что еще один промежуточный слой делать?
-----
Так ведь сам же говоришь - хочу изолировать. Вот и изолируй, оперируя, как в шарпе, лишь дескрипторами (не указателями)... Про то, что можно докапаться спорить не буду - докопаться всегда можно, вопрос затрат на это дело. А под изоляцией надо понимать организацию системы при которой прямой доступ к данным более сложен, чем использование предоставляемой функциональности.
правда как ос называлась на громадной ИБМ не помню уже
-----
OS IBM 360/370... Ну и в зависимости от комплектации сверху всякие приятности типа Примус-а...
Я тоже много чего позабыл... Но юстировку головок на накопителе еще в состоянии сделать... :)
Как, в прочем, и осознанно написать BALR USING 15 или SYSIN DD *... в прочем - это к соседней
ветке по поводу качества обучения - учили на совесть...

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

\В самом концепте такого противоречия нет.
Так вот, это и видно. В чистом классе нет данных но нужна имплементация чистого виртуального метода. Но если он у меня работает только с данными,а новых данных нет \согласно концепта\, то в этом классе он мне нафиг не нужен, но обязан что-то сделать \согласно концепта\, могу сделать только пустой, что видимо нельзя. Чем не противоречие?
\Да ну? У меня вот получается, что будут весьма приятные преимущества
Не вижу ни одного преимущества, по той причине что чистые вирткальные методы просто "вредны". Ну есть у меня один объект, который уже реализует требуемую абстрактную операцию. Хочу наследовать от него еще один объект, которого вполне удовлетворяет реализация операции. Зачем мне определять такую-же операцию в наследуемом объекте?
\при реализации которых трудозатраты будут примерно одинаковы у С и С++
но пользоваться с удовольствием нельзя будет ни тем ни другим.
Я вообще то имел в виду, убрать с концепта ту часть которая осложняет реализацию.
\В ассемблере или машинном коде он мне тем более не нужен.
-----
\Разве? Эти две позиции всего лишь индицируют, что ниже спустится уже нельзя, а не отсутствие концепта.
Я говорил не об отсутствии,а о том что его реализация мне не нужна на этих позициях. То есть любая реализция любого концепта мне не нужна, если писать на классическом ассемблере или машинных кодах.
\Так ведь сам же говоришь - хочу изолировать. Вот и изолируй, оперируя, как в шарпе, лишь дескрипторами.
Да хочу, но хочу иметь их уже изолированными, а не заниматься этим самому.
\А под изоляцией надо понимать организацию системы при которой прямой доступ к данным более сложен
Но не потребляет ресурсов при выполнении программы.
\.. IBM 360/370
Вроде так называлась сама машина с которой все было украдено. Казалось что ОС называлась как-то по другому. Хотя в то время меня это не очень интересовало. Жрет перфокарты, принтер печатает и хорошо. Если, что в соседней комнате начальник машины, пусть разбирается. А то потом скажут что сам сломал.
\Ну и в зависимости от комплектации сверху всякие приятности типа Примус-а
Оо, знакомое слово услышал. Была такая буква
\Но юстировку головок на накопителе еще в состоянии сделать
надеешься что кому- то еще понадобится?
\учили на совесть
ну и куда ты сейчас это засунешь? Я как вспомню, сколько разной ерунды нам давали, которая мне ни разу не понадобилась и уж точно не понадобится. А нахрен было заучивать метровые формулы, которые забывались сразу после выброса ненужных шпор.

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

\Угу... в имплементация чистого абстрактного метода в чистом классе запрещена концептом, имплементация "грязного" (по диаграмме) - допускается.
Ну такого я не заметил. В принципе, это было согласно:
"Концепт требует имплементации чистого виртуального метода в каждом классе иерархии, исключая абстрактные, в случае отсутствия имплементации должна возникать отслеживаемая ошбочная ситуация."
относительно запрещения нашел только следущее:
- пустой виртуальный метод - метод не содержащий в себе полезной функциональной нагрузки, кроме вызова аналогичного метода базового класса или обработки ошибочного вызова и их комбинации с условиями.
...Поскольку метод не содержит полезной функциональной нагрузки его имплементация запрещена в данном концепте.
\У тебя не должно быть пустого метода, но должна быть отслеживаемая ошибка при его вызове.
А каким образом я узнаю, что метод пустой во время выполнения программы? Да и при компиляции, надо уже семантику отслеживать.
\Определять такую же операцию в наследующем объекте нет никакой необходимости
Ну а тогда зачем вообще нужны чистые виртуальные методы?
\Ну а Я говорю об том, что надо имплементировать именно то, что задано.
Хотя солдатом я быть не люблю, но если шеф так хочет пусть сам потом мучается.
Я бы назвал этот концепт - концептом бога. Потому как есть некто проверящий классы во время рождения и определяющий их дефективность\пригодность.
Фактически примочка чисто архитектурная. Поэтому, лучше всего проверять это дополнительной программой типа "линт". Если же хочется в рантайме делать, то нужен доступ к списку функций членов класса. Проше всего это делать в шарпе. Кстати, как сделать это в плюсах на переносимом уровне я не знаю. Ручную поддержку списка я отметаю сразу.
\Угу... начинаются проблески понимания...
Кстати, подобные комментарии мне кажутся недопустимыми. Ладно, я понимаю это как шутку. Но некоторые это могут понять прямо. И тут могут начаться различные конфликты.
\Т.е. ты говоришь, что использование асмового концепта тебя не устраивает.
\И в тоже время, ты говоришь, что тебе не нужен более сложный концепт.
асмовская реализация. Ты же не будешь утверждать что 2+5*3 будет проще реализовать на асме,чем на С
\т.к. чистый Си не имеет языковых средств для этого
так я с намого начала и говорил - бардак.
\Правда, если вдаваться в детали, то там была не одна операционка
К деталям доступа не имел.Чего то помню из СМ4, но весьма смутно.
\У меня пока еще есть ленты
Ленты у меня тоже есть, но куда их засунуть я не имею никакого понятия. \Только без пошлостей, плиз \
\А не заучивать, но выводить необходимые формулы не учили?
пытались, но когда доску стирали в третий раз я уже засыпал.
Скажем так, если мне нужно будет посчитать объем шара, то формулу я могу найти в справочнике.
А если я еще помню что е=м*с(квадрат), то она мне нафиг не нужна
Либо вот у меня есть знакомый, который может с точностью до 10 центов сказать сколько денег у него было в кошельке каждый день, в течении прошлого месяца.
В принципе имея ехсел, я бы мог тоже это сказать, но для чего мне это нужно. Мне достаточно знать, что там что-то есть и того что есть хватит на то что мне сегодня понадобится.

Ну такого я не заметил.
-----
Добавь снизу, что чистые классы не содержат полей данных и все будет как надо - чистый виртуальный метод не имплементируется в чистых классах и его вызов дает отслеживаемую ошибку. Если по-другому, то поскольку чистые классы всегда агрегируются, они должны иметь специальный невиртуальный метод для операций типа сериализации/десериализации.
Хотя, да, определение должно быть изменено - "Концепт требует имплементации чистого виртуального метода в каждом классе иерархии, исключая абстрактные и те, где имплементация запрещена, в случае отсутствия имплементации должна возникать отслеживаемая ошбочная ситуация."
А каким образом я узнаю, что метод пустой во время выполнения программы?
-----
Ну наконец-то... :) Используя С++ - никак. Для Сей - дополнительное поле таблице виртуальных функций и проверка поля перед "выбросом исключения"...
Ну а тогда зачем вообще нужны чистые виртуальные методы?
-----
В купе с чистыми классами - для редуцирования ошибок в архитектуре классов.
Ручную поддержку списка я отметаю сразу.
-----
Это уже от выбранного тоолса...
Ты же не будешь утверждать что
-----
Это - нет, но Я буду утверждать, что С++-концепт не есть наипоследнее и совершенное творение, и что есть необходимость анализировать задачу и разрабатывать концепт под задачу до выбора средства имплементации.
так я с намого начала и говорил - бардак.
-----
Ну а С++ реализация чистого виртуального метада как определено в концепте что даст? :)
пытались, но когда доску стирали в третий раз я уже засыпал.
если мне нужно будет посчитать объем шара, то формулу я могу найти в справочнике.
-----
Ну а меня все же научили. Итого: вторая производная пути есть ускорение...
Аналогично - объем шара - поверхностный (двойной) интеграл...
Эээ... последний раз понятие третьей производной использовал на этой неделе - вправил мозги одному туповатому экономисту по вопросу сокращения роста объема инвестиций... при заявленной положительной третьей производной... и, как следствие, продолжающемся ухудшении общей ситуации т.к. рост инвестиций уходит в основном в потребление... т.е. инвестировать туда нет никакого резона - все одно гавкнется в обозримом будущем.