Был сегодня на интервью. Компашка занимается софтом для мелких банков. Код - С++,
глубиной в 20-ть лет. Предлагавшаяся позиция - Senior Soft. Dev., 60K..
Интекрвью из двух частей. Первая - тупой тест на базовые знания С++ и SQL (Oracle). Вторая -
собеседование. Обе - без пролем пройдены, причем во второй пытались завалить вопросами
по эмуляции С++ методов средствами простого Си...
Результат: отказ. Мотивация: слишком глубокие знания, компании будет трудно мотивировать...
Так чего же они все же хотят, если собираются искать более тупого? В смешанном коде
разбираться надо уметь... не для тупых...
Есть кто-нибудь из HRM-профи, способный объяснить ньюансы такой мотивации отказа?

в Г. такое называется "überqualifiziert". Вот тут описывается, что за отказом по этой причине кроется набор предрассудков, которые владеют умами HR'щиков: http://inhalt.monster.de/12936_de-DE_p1.asp
Вкратце:
- соискатель идет на эту должность в качестве крайней (временной) меры
- работа ему будет казаться слишком тупой
- рано или поздно она ему надоест
- он будет считать себя лучше других
- будет строить из себ умника
- будет пытаться с течением времени занять чье-нить место повыше

Блин, не туда запостил...
Перекиньте, плс, в Курилку...

Ихь хабе шпрейхен зи дойчь нихт...
Вкратце:
- соискатель идет на эту должность в качестве крайней (временной) меры
------
Тут возникает вопрос - какое время может считаться приемлемым? В моем случае это между 2 и 5 годами. Прямой вопрос не задавался.
- работа ему будет казаться слишком тупой
------
Хороший ИТшник знает, что вся его работа такая.
- рано или поздно она ему надоест
------
Она ему уже налоела... но работать то все одно надо...
- он будет считать себя лучше других
- будет строить из себ умника
------
В минусе - перерос уже давно такие глупости.
- будет пытаться с течением времени занять чье-нить место повыше
------
Без этого нет смысла садится не в директорское кресло. Проблема в том, что в организации выше предлагаемой позиции есть только одно лицо. Дальше - только директорат, который не тут... и это... подчиненных - не обещали...

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

Так самое интересное в том , что Murr плюсы не знает ,
видимо фирма занимается разработкой хеловорлдов .

зачем спрашивали такие продвинутые вещи
-----
Вот и мне не понятно. Написали бы, что требуется "попка" на 35-40К - получили бы кучу приличных исполнителей, не обременных особенностями моделей таблиц указателей виртуальных функций...
Т.е. надо было прикинуться дураком, так выходит?
-----
С этим у меня прокол - привык с универских времен в крайнем случае делить с кем-нибудь первое место... а обычно - брать 29 из 28 возможных...

Так самое интересное в том , что Murr плюсы не знает
------
Мурр, однако, не уверен, что Chipolino правильно оценивает знания Мурр'а.
Что до самого Мурр'а, то Мурр знает где проходит граница его знаний и
это дает ему весьма большое преимущество перед теми, кто думает, что
он что-то знает...

Ну уж извиняй ,я могу оценивать только по твоим постам в этом форуме .

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

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

HR профи тебе уже встретился на собеседовании - тот кто вычислил что у тебя

Это их не устраивает. Точка.
Все остальное - чепуха, надуманные предлоги, в качестве которых в Германии обычно выступают
“заботливые” фразы типа “нам кажется, что эта работа при вашей высокой квалификации
не принесет вам должного удовлетворения”.
Senior Soft. Developer рассматривается не как самый талантливый программист, но как звено
легко управляемое сверху, и умееющее грамотно руководить талантливыми программерами-винтиками снизу.
Самое важное - не умение и стремление пролезть на первое место, а талант организовать работу других,
научить их, в том числе - пролезать на первое место. Этой самопожертвенной готовности у тебя не обнаружили

HR профи тебе уже встретился на собеседовании
-----
Не думаю. По крайней мере тот, кто был там за HR не рассчитывал на обоюдное тестирование
и не был готов отвечать на вопросы по текучке кодров в компании. Вместо нее отвечал начдеп
разработки.
И перечитай, плс, условия - SSD + 60K. При среднем уровне зарплат - ~35K. Ожидать, что при
таких запросах не будет - "брать 29 из 28 возможных" - глупо, неамбициозные не дорастают до
этого уровня.
Этой самопожертвенной готовности у тебя не обнаружили
-----
Это другой уровень запросов и, пожалуй, другая специализавция. Не 60К, а где-то 75-80K в местных
ценах. Такие предложения тоже бывают, но это не мой тип работы. Т.е. делать ее Я могу и весьма
качественно, но без "огонька"... просто не мое.

Мурр, еще раз

------------

Здесь ты продемострировал что ты умный и способен “задавить” собеседника-твоего потенциального коллегу.
Идеальный кандидат ответил бы мне не контр-тестированием, а фразой типа “давно уже этими основами не удавалось позаниматься,
и чтоб сто раз к ним не возвращаться – я вот написал для моих студентов веб-сайт с инструкцией, посмотрите здесь...”
Ты же на форуме Германки чуть раньше на простой вопрос как сделать формулу в Екселе - разлил тараду о глупости этого занятия
и о необходимости учить Аксесс, так и не приведя ни единой конкретной строчки по Екселю.

что и указали – отказом

и умееющее грамотно руководить талантливыми программерами
------
Это _другая_ квалификация. SSD же решает технические проблемы разработки,
а не общие проблемы управления коллективом разработчиков.
И совсем не обязательно, чтобы коллектив был из талантливых программеров.
Этот момент я пробовал акцентировать на интевью, но его просто замяли.
и способен ⌠задавить■ собеседника-твоего потенциального коллегу.
------
Хммм... задавить - могу. Но не делаю. Кроме этого, предпочитаю работать
с профи, умеющими адаптироваться к ситуации. Проблема, на мой взгляд,
в том, что контора работает с _банковским_ софтом. По определению она
должна быть весьма консервативной и в ней действительно сложно работать
людям ориентированным на инновацию. Может мне пора перестать заниматься
инновациями?
а фразой типа
-----
К сожалению такая фраза не дает ответа на вопрос - насколько велика текучесть
кадров в компании. А она - велика, хотя объясняли ее ростом компании. И еще раз
- делал это не HR, а девнеад, что весьма нетипично для консервативной организации...
Ну да бог с ними - в понедельник еще одно интервью и с, примерно, теми же условиями.
так и не приведя ни единой конкретной строчки по Екселю.
-----
Потому, что в правильном месте это делается в одной строке и не упирается
в имеющиеся в Excel'е ограничения. Для программиста Excel скорее вреден,
чем полезен. Это мое частное мнение, никому его не навязываю, но буду советовать
использовать более пригодный инструментарий.

Муррыч, мне самому SSD позарез нужен для Axapta,
посему могу дать совет тебе с другого края переговорного стола :)
рассматривай SSD как многолетнего армейского старшину... и все получится.
Удачи тебе завтра!

Как ты думаешь, кто более непробиваемый: вагант или мурр?

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

Тебе нужно поучиться читать между строк подобных ответов.
По-секрету - там имеется свой, весьма специфический, язык,
при помощи которого HR'ы дают характеристику человеку...
Мне тоже это нужно знать и именно по-этому Я задавал тут этот
вопрос...
отказ нужно мотивировать так
------
Наилучший из отказов, полученных мною в стране где Я родился
и получил пару высших образований, звучит так:
"...в соответствии с законами с(т)раны Вам работать по основной специальности запрещено."
ниже - подпись и круглая гербовая министерская печать... и никаких правовых проблем... :)

Пиши - Мурр - у него практика игнорирования власть имущих куда как более богатая...

Прежде всего спасибо за открытый секрет, польщен оказаным доверием.
без обид. я тебе сказал именно как есть. ничо не придумывал. обясняю тебе на уровне HRM профи : тебе ответили штампом, какой ты можешь встретить в 99% отказов. любой другой ответ мог бы повлечь за собой судебное разбирательство - это не параноя, а немецкая реальность.
если 60 к - это зарплата (она выше в фирмах работающих с банками чем гделибо, помоему) то я думаю, что желающих было более чем достаточно. тебе пришлось поконкурировать с другими.
Так вот давай вот попробуем проанализировать, что им нужно было и как можно было им втюхать себя как именно подходящего человека:
-- опыт - раз; думаю лет 5минимум. сеньйора искали жеж.
-- представительность - два (полюбому, клиенты банки, любят костюмы и скучных типов). Тоесть вести себя спокойно, решать проблемы неспеша, излучая увереность, прежде подавая методику решения: эмуляция в с с++ методов? -- обьяснить им что нет разници на ч╦м программировать ибо главное как программировать. у опытного программера всегда есть примеры. попытка завалить на этом уже настораживает, может ты их не убедил?;
-- три - ты должен был передать ключевую мысль: умеешь работать самостоятельно, можешь себе легко представить когото курировать, распределять задания, видеть ч╦тко концепты решений, быть готовым выслушать в деталях чужую мысль ( посмотри спокойно, на свой предыдущий ответ мне);
--Четыре: я надеюсь ты увидел людей работающих в этой конторе не первый раз в лицо на собеседовании? был до этого под фирмой хотябы чтоб посмотреть на тех кто там работает? Может оказатся очень важным то, вписываешься ли ты в коллектив;
я не пытаюсь тебя както наругать тут, я пытаюсь поучаствовать в дискуссии.

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

то я думаю, что желающих было более чем достаточно.
------
Возможно. С другими кандидатами Я не встречался. Посмотрел сегодня их сайт - вакансия снята, но добавилась аналогичная в другом месте.
это не параноя, а немецкая реальность.
------
Немецкая реальность ко мне относится в очень малой степени - Я живу в другой стране.
-- опыт - в наличии. Их потребности - перекрываются с излишком.
-- представительность - ??? - когда ты видел _разработчика_ банковского софта делающего "клиентфайсинг" или, хотя бы, "онсайт"?
-- три - стоило бы почитать первый пост - С++ код, с предисторией в 20-ть лет - добавить сюда область применения и половина требований поменяется на противоположные, а те, что не поменяются - перейдут к другому лицу.
-- четыре - разумеется нет - контора за глухим забором, на узкой и весьма грязной улице в центре Дублина. И у меня не бывает проблем с вписыванием в коллектив или в работе с любыми коллегами... исключая тупых, но и с ними не бывает конфликтов - просто уровень разъяснений/помощи/затрат им значительно значительно более поверхностный.
может ты их не убедил?;
------
Возможно. Правда это не вопрос убеждения, а вопрос знания техники реализации.
тоесть не написано, что
------
Вопрос в том, сколько вообще характеристик используют HRM для написания характеристик?
1. Пунктуальность
2. Работоспособность
3. Уровень знаний
4. ?
И как из них строится результирующая оценка?
не исключено что тебе придётся писать на нём
------
Маловероятно. Это не мой тип работы. Что Я иногда делаю, так это техническую оценку - по резюме и собеседованию - возможностей кандидата применительно к имеющимся задачам. Результат оценки обычно близок к реалиям.
Я тут подумываю об том, чтобы вернуться к своей старой практике - запрашивать развернутую оценку проведенного интервью независимо от результатов.
Вчера, по результатам интервью в другой конторе, получил от тамошнего HRM через агентство предварительную оценку - "I was imprest with his interview"... но конечного результата пока не имею.

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

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

ну сам прикинь ... что написано - зависит от того кто пишет, на маленькой фирме где шеф попутно чемто важным занят, пишется с одного и того же примерно образца. добавляется фраза-вторая, если хочется плюнуть борщ. насч╦т больших фирм не знаю, може они там раз в месяц ходят на какието ежемесячные курсы по написанию характеристик ). с плохой характеристикой или коряво писаной - естественно предположить ( я не знаю) - большие фирмы связыватся не будут, очкан╦т отдел кадров перед ответственностью за то что не распознали.
вот такая практика в германии.
-----------
>>Возможно. Правда это не вопрос убеждения, а вопрос знания техники реализации.
хз, какая там техника реализации в банковском софте, как ни крути 100% подходящего чела они не найдут - следовательно фраза "я не сталкивался с проблемами которых бы я не решал, в том числе освоение нового" должна бы иметь значение.
тоесть ты имел ввиду что у тебя 20 лет опыта. сорри я не проникся инфой даже перечитывая (
-----------
вроди вс╦

А о чем собственно этот пост? Вы действительно думаете, что здесь смогут дать ответ на этот нелепый вопрос? Не взяли - были на то причины. А причин может быть миллион, начиная с вашего произношения или внешнего вида и заканчивая бог знает чем. Или вы считаете, что вам отказать просто невозможно? Мне кажется, что изюменка этого поста "Результат: отказ. Мотивация: слишком глубокие знания, компании будет трудно мотивировать", именно ее вы хотели показать нам.

с характеристикой у тя в поряде.
------
У меня ее вообще нет. Есть резюме, в котором очень сжато, без детализации, перечислены использованные инструменты и выполненные работы, рассчитанное на оценку техническим специалистом.
то есть ты имел ввиду что
------
Я имел в виду, что время существования С++, как системы разработки, примерно сравнимо с этим периодом. Т.е. есть большой шанс, что часть кода, возможно - значительная, реализована не на С++, а на pure С и за эти 20-ть лет не была переработана в С++. Характер вопросов по технической части свидетельствует об том же.
лет опыта
------
Побольше, пожалуй... :) Особенно учитывая, что первую электросхему Я спаял лет в шесть, а работающие нестандартные механические конструкции собирал еще раньше... :)

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

вопрос с перекидкой кода в си++ это засада. я вот не знаю что сказал бы, даже желая угодить. я се только представил кучу старых комментариев, п╦стро форматированый код, директив прекомпайлера побольше чем кода. а главное людей, которые это делали и свято верят чо оно самое лучшее в мире ...
ты надеюсь не говорил им что ты изменишь их мир к лучшему? 90% народа от таких заявок покрываются красными от раздражения.
-------------------------
конечно офтоп, но интересно, они правда решили переходить на с++ (ну дофига работы, прич╦м для частной фирмы - когда оно окупится то)? или хотят делать и то и другое и ищут решение?

это засада
-----
Для меня - нет. Имею достаточно опыта в интегрировании подобного, правда - своего, кода. Правда это _старый_ опыт, опыт 90-х, не попадающий в последние две страницы резюме. Единственная проблема - Я точно не был готов к тому, что именно это будет основной работой.
ты надеюсь не говорил им что ты изменишь их мир к лучшему?
------
Прямо, разумеется, Я им этого не говорил. Просто из описания работы последних трех лет, а она связана с автоматической генераций приложений, и не учитывая банковской специфики их кода, следует, что повторить наработанное ими за 20-ть лет можно в течении пары-тройки недель.
90% народа от таких заявок покрываются красными от раздражения
------
Я, обычно, работаю с остальными 10%... По крайней мере Я обычно высказываюсь по качеству кода вполне определенно и так же обычно, в местах где мои рекомендации по тем или иным причинам игнорируются, появляются проблемы, на решение которых уходит довольно много времени.

Мне тебя искренне жаль! Ты нихера не понял из сказанного мною. Здесь не гадают на кофейной гуще, и ответить, почему такому красавцу как ты не дали работу (Чего они все же хотят?), здесь никто не сможет.
Прочел некоторые из твоих сообщений на этом форуме и даже прослезился от смеха. Ты сам никогда не задумывался, для чего ты задаешь вопросы, если все ответы на них ты сам потом опровергаешь? В итоге где сели там и слезли!
Извени если обидел. Можешь не отвечать на это сообщение, мне с тобой, вести беседу в тягость!

Ты сам никогда не задумывался, для чего ты задаешь вопросы,
если все ответы на них ты сам потом опровергаешь?
------
Вспоминается такой анекдот:
Разговаривают два профессора об методике преподавания.
Один говорит - у меня - конспект, я его читаю, остальное они найдут в библиотеке...
Второй - выбираю самого тупого в аудитории и разъясняю пока он не поймет...
Подходит третий профессор и спрашивает - Почему вы все время на меня смотрите?..
Мои вопросы в основном для того, чтобы понять что именно Я не правильно оценил или не включил в оценку вообще. Опровергаются ответы на них или принимаются как есть - роли не играет - анализ производится и результаты учитываются в следущей итерации/интервью.
здесь никто не сможет.
------
Ошибаешься. Я уже знаю в чем именно была проблема, что именно Я не доработал. Просто вычислил моменты на которые обращал недостаточное внимание. Т.е. Я получил ответ на заданный вопрос, а значит он был задан в правильной форме и в правильном месте.

Поделись информацией ;-)

Почитай лучше мемуары Наполеона, этот - из палаты номер 6 :-D

Поделись информацией
------
А она тебе будет полезна? Она, в смысле, информация об моих недоработках...
А недоработки были простые - не слишком внимательно отнесся к типу конторы и к их текущей ситуации - больше акцентировал внимание (приводил примеры) на переходе от С++ к ДотНет (С++ vs C#), а не на предыдущей ступени от Си к С++...

Это ты так думашь, а что думали они так и останется тайной. Но для постоянной работы чаще нужны люди, а не специалисты. Кстати, сейчас часто сталкиваюсь с Сишниками, так "умники" им не по нутру, а ООП вообще вреден для С. Если люди там 20 лет на С сидели, то им действительно не нужен сильный спец, потому как сильно отходит от среднего уровня коллектива.
Все это конечно мое личное мнение, ни на что не претендующее.
А вообще то подумай о своем деле.

а что думали они так и останется тайной
------
Это для меня критического интереса не представляет. Знать в деталях - было бы хорошо, но не более. Свое же - Я отловил.
так "умники" им не по нутру
------
Аналогично будет в любой организации, связанной с консервативными системами - банками, страховками, билетами и етц...
К сожалению очень многие другие организации ориентируются на такой же стиль работы, хотя и не имеют для этого оснований.
а ООП вообще вреден для С
------
В живых проектах с объемом кода более 15-20Мб в любом случае будет иметь место ООП концепция, а различия будут определятся доступным инструментарием.
подумай о своем деле.
------
Подумываю. Если за ближайшие три недели не найду что-то подходящее - сяду доводить один из проектов - надо доделать несколько форм и перевести его с DCOM на SOAP... заодно и свой SOAP-генератор форм подновлю... Все одно пару месяцев - до средины Февраля - будет тишина...

Во многих больших сишных библиотеках используется ОО подход .
Самый яркий пример GTK .

А че там ООго-то?

“Умники” - очень даже по нутру, но именно на позицию программера (куда ты сам себя и сваливаешь
своими ответами на интервью – ты закапываешься в подробности языков программирования и т.д.).
От SSD же требуется именно старшинская роль – то есть даже если вся его рота салаг поувольняется
или начнет “умничать” – не беда : опытный старик, пусть и медленнее, пусть с поминутным лазаньем в справочники,
но сам сможет поддержать проект как минимум до подхода новых “умников”, которых, кстати, сам же и обучит в идеале,
чтоб директору компании снова не париться с HR агентствами.
Именно к этому и клонятся разговоры об эмуляции методов – один “умник” ваял в С++, следующий знает только С.
Хорошему SSD наплевать на это – с эмуляцией, пусть и через джёппу, но “умники” смогут использовать
наработки друг друга и проект будет продолжен.
Прямо сейчас, чисто по форумским постингам, взял бы на SSD Дактиля или Леху-Симпла...
тебя - нет (причины уже описал выше)... но удача есть, ее не может не быть :) дерзай!

Ой :-О Пора подниматься по карьерной лестнице, похоже :)
Дактиль - девочка, кстати :))

пусть и через джёппу
------
Предпочитаю просто уходить из конторы, если там соглашаются на "пусть и через джёппу". Ибо в таких конторах проекты все одно разваливаются, независимо от смены/состава разработчиков.
но удача есть, ее не может не быть
------
Разумеется. Иначе бы Я все еще жил в рабстве у потомков недобитых СС-овцев... :)

Могем предложить пока только проект Axapta 4.0

Мне следовало написать ДактилЬЮ? :)

Счастливец.
Надеюсь, не тошнит от посещения этого форума – тут ж, наверное, с половину таких "страдальцев" в рабстве :)

> Могем предложить пока только проект Axapta 4.0
Никогда не слыхал :-о
> Мне следовало написать ДактилЬЮ? :)
Нет, просто Дактиль :)

тут ж, наверное, с половину таких "страдальцев" в рабстве
-----
Тебе стоит обратится к Симплу по вопросу об терминологии.
Бо, если Я называют с(т)рану с марширующими СС-овцами, получающими поздравления от президента, то ее собственным именем, то следует бан... :)

Никогда не слыхал :-о
-----
Ты вообще-то много об чем никогда не слыхал... :)

Я и не 3,14жжу об этом, в отличие от тебя :)

Твое отличие не в этом. Оно в том, что не слышал, не слышишь и слышать не будешь... даже если тебе через матюгальник будут объяснять... ибо такова твоя позиция... :)

Я слышу только то, что нужно для дела, а о том, что не слышал, предпочитаю помалкивать, в отличие от 3,14здоболов, которые не знают, что такое СС :)

Я слышу только то, что нужно
-----
Именно это я тебе и говорю. То, что ты делаешь - не меняется годами, потому все, что ты должен был услышать - уже слышал... а за пределами этого - не слышал, не слышишь и слышать не будешь... :)
Вообщем - собирай ядра... :)

> Именно это я тебе и говорю.
Не именно это, а как всегда переделано по-муррски :) То есть, на 90% бред сивой кобылы. Не пей так много коньяка с утра :)

Наследование например .

В чем это выражается? Забыл уже, как это все на гтк. Помню, что есть гтк--, вот он уже оо-рапер гтк простого.

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

Только непонятно нахрена так было извращаться
------
Есть два момента:
- существует наработанный код, который нужно будет перерабатывать
- кому-то нужен был прямой динамический доступ к vptr, ибо квалификация не позволяла сделать через virtual...

не в этом случае

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

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

Вообще-то полная фраза звучала не так:
"Кстати, сейчас часто сталкиваюсь с Сишниками, так "умники" им не по нутру, а ООП вообще вреден для С."
Кстати, в мануале GTK+ позабавила фраза "Object Hierarchy". Ради этого даже утянул всю библиотеку, завтра гляну как там они структуры наследуют и "Abstract Base Classes" сделали.
Описание здеся нашел
http://antex.ru:8080/doc/gtk2/gtk/index.html

Когда я разбирался с гтк, ничего там такого не было, но это и было давно. А ваще есть оо-рэппер, как я уже писал, нахера изобретать велосипед? Или взять сразу Qt, хотя она мне тоже не по нутру особо.

Ну, у тебя еще есть вопросы к этому гэнию практическава инжиниринга?

Меня тоже некоторые вещи в Qt напрягают , но плюсов намного больше ,
очень нравится логичность библиотеки , ну и документация , лучше доков
я не встречал .
Что тебя именно не по нутру ?

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

У нас гайдлайн - брать все из Qt, а не из STL. Зло вымещаю :) В остальном вроде все ок.

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

Вообще-то мне мне это больше интересно с "научно познавательской" целью. Если надо писать на С то ничего другого просто нельзя использовать. А если можно, то лучше плюсы к готовому С коду прицепить, где имеет смысл.

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

Я бы не сказал, что в Германии любят "средняк". Здесь, как и везде, не любят умников, которые много балаболят, но мало делают.
Что же касается интервью, то я лично согласен с Джоелом -

Что же касается Мурра, то по его постингам на форуме у меня есть определённые сомнения насчёт "Get things done"...

Murr get things done... and in time.
Ну если не сделает - никто в компании не сделает за приемлемое время.

>>В живых проектах с объемом кода более 15-20Мб в любом случае будет иметь место ООП концепция, а различия будут определятся доступным инструментарием.
пять балов.
Для тех кто вс╦ ещ╦ сомневается: ваще язык програмирования не играет роли. ооп концепт не имеет с языком ничего общего. в литературе эта тема широко освещена.

>> У нас гайдлайн - брать все из Qt, а не из STL. Зло вымещаю :) В остальном вроде все ок.
вправду гадлайн.

....ооп концепт не имеет с языком ничего общего.
Концепт да, а вот реализация...

....ооп концепт не имеет с языком ничего общего.
Концепт да, а вот реализация...
------
А что с реализацией? На чем надо - на том и реализуется, в соответствии с имеющимися возможностями.
К примеру, годике этак в 1999, когда меня сильно прижало по срокам, использовал ООП-концепцию при...
только не падать... программировании на ASP... и ничего - все работало как должно... все 5 Мб активного
кода написанные за неполные три месяца... Разумеется, никаких виртуальностей и прямого наследования
не имелось, но это уже детали реализации...

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

А в реализации ни наследования ни полиморфизма.
------
Ну нету. Так что, и реализовать невозможно? Жили же как-то несколько десятков лет без наследования и полиморфизма... :)
Кастрировать дизайн или делать все через жопу?
------
Ну если написание и поддержка ап-то-дэйт одного "метода" через примитивный набор switch-case-case (при отсутствии указателей на функции) есть "делать через жопу", то - "тады ой...". :)

\Жили же как-то несколько десятков лет без....
Да и без Интернета жили тоже поболе, А забери его счас от тебя....
Реализовать то можно, а зачем?
\Ну если написание и поддержка ап-то-дэйт одного "метода" через примитивный набор switch-case-case
Я тута по быстрому примерчик набросал, может и с ошибками, но как тест пойдет. Не знаю как это на С красиво сделать. Не только что бы работало, но и что бы любая обезъяна могла править и добавлять.
Может покажешь как твой волшебный свитч это все сдеалает. И что бы компайлер ругался когда четкую херню порешь. Типа b.Store в майне вызвать. И строки хочу прибавлять а += "Тест".
И "стреам" куда хочу. Да много еще чего . Правда виртуального наследования не прошу у золотой рыбки, тъфу котика.

class A
{
	public:
		A(string Name) {m_Name = Name}
		virtual bool Compare(const a& Cmp) const = 0;
		virtual string GetName() const {return m_Name; }
		StoreToFile(string FileName) 
		{
			...
			Store(FileStream);
		}
	
	protected:
		virtual stream& Store(stream& DataStream)
		{
			DataStream << m_Name;
			return DataStream;
		}
	
	private:
		string m_Name;
};
class B: public A
{
	public:
		B(string Name, int Code): A(Name), m_Code(Code) {}
		static bool operator==(const B& Cmp1, const B& Cmp2 ) const
		{
			...
			Ret = Cmp1.Compare(Cmp2);
			...
		}
		virtual bool  Compare(const a& Cmp) const
		{
			...
		}
		int GetCode() const {return m_Code; }
	protected:
		virtual stream& Store(stream& DataStream)
		{
			A::Store(DataStream);
			DataStream << m_Code;
			return DataStream;
		}
	public;
		int m_Code;
};
class C: public B
{
....
		virtual string GetName() const {... }
}
main()
{
	A* pa = NULL;
	B b("Test",1);
	C c("Test","125");
	pa = &c;
  if(b == c)
  {
....
     x = pa->GetName();
  }
}

Может покажешь как твой волшебный свитч это все сдеалает.
------
В чистом Си это сделается точно так же, как и в С++ - передачей методу дополнительного параметра.
Единственное отличие - параметр передается явно, а не скрыто как в С++. Т.е. вместо
b->GetName() будет GetName(b).
Даже Switch-Case не нужен.
Выше Я (вроде) писал, что Switch-Case нужен там, где нет укзателей на функции.
Не знаю как это на С красиво сделать.
Не только что бы работало, но и что бы любая обезъяна могла править и добавлять.
-----
Реализуешь пару раз подобное на чем-нибудь - помешь что не намного сложнее, чем на плюсах.
И Я говорю вполне серьезно - для реализации в Си там всего то один дополнительный массив указателей на функции,
ну а где указатели недоступны - Switch-Case.
И что бы компайлер ругался когда четкую херню порешь.
Типа b.Store в майне вызвать.
И строки хочу прибавлять а += "Тест".
И "стреам" куда хочу.
Да много еще чего
------
Спроектируй, плс, одну простую и полезную вещь - пусть выдает 6 чисел... которые выпадут в следующем розыгрыше... :)
Ну а то что ты хочешь - реализуемо средствами Си и дисциплиной программирования.

З.Ы. В другой раз попробуй не подменять релизацию ООП-концепта в каком-то языке требованиями выполнить копирование реализации концепта в другом языке.

Ну это я для примера конкретику взял. Можно и более абстрактно оформить.
Ну вот раньше было: структкрный анализ, дизайн, программирование. Ориентировались на процедурную линию. Потом объектно- ориентированный анализ, дизайн и программирование. Ориентируемся на объекты. Вся линейка фактически связанная между собой. Если операции с объектами подменять чем то другим то получится бардак.
Если опять перейти на конкретику. Берем простой случай передачу "this" в Сишную функцию. Передавать надо будет любой "объект" из иерархии, значит тип прийдется два раза \туда и обратно\ принудительно преобразовывать. Как при этом обеспечить безопасность я пока не знаю. При этом вся работа по контролю типов переходит от компилятора к программисту, ну может в лучшем случае на рантайм. То бишь в любом случае мы должны что то потерять при преоразовании и то что получится, я бы в лучшем случае назвал моделью объекта, но никак не объектом.

Если операции с объектами подменять чем то другим то получится бардак.
-----
Получится не бардак, а имплементация ООП-концепта имеющимися средствами используемого языка.
Передавать надо будет любой "объект" из иерархии, значит тип прийдется два раза \туда и обратно\ принудительно преобразовывать.
-----
И это так трудно? VOID укзатель "кастировать" к какому то типу... Ну или добавить небольшой оверхед к реализации каждого объекта и получить хоть RTTY & dinamic_cast...
То бишь в любом случае мы должны что то потерять при преоразовании и то что получится
------
Будешь удивлен, но в С++, который ты позиционируешь на место ООП-концепта, ты имеешь тоже самое. Для примера - реализуй концепцию C#-интерфейсов на С++ или наоборот - множественное наследование в С#...
я бы в лучшем случае назвал моделью объекта, но никак не объектом.
-----
См. п.1. и говори - реализация объекта.

\а имплементация ООП-концепта имеющимися средствами используемого языка.
кому как, при "неподходящем" языке для меня будет именно бардак.
\И это так трудно? VOID укзатель "кастировать" к какому то типу..
Опять таки, с какой стороны посмотреть. Любая дополнительная операция преобразования увеличивает уровень потенциальных ошибок. Да и проверить соответствие указатель-функуция можно будет в лучшем случае на этапе выполнения программы, что совсем не хорошо. Ты просто рассматриваешь проблемы с точки зрения возможности реализации, а меня еще интересует возможность использования в долгом теам проекте.
\Будешь удивлен, но в С++, который ты позиционируешь на место ООП-концепта, ты имеешь тоже самое.
Ну не совсем. Важно что есть база а все остальное просто полезные вкусности. Всегда будет чего то не хватать.
Кстати, шарп я люблю больше чем плюсы.
\См. п.1. и говори - реализация объекта.
Максксмум - моделирование объекта.

кому как, при "неподходящем" языке для меня будет именно бардак.
------
Бардак это не от языка. Бардак это от программера. Я вполне в состоянии устроить бардак в С++, Жабе, C# и писать нормально в Сях, VB, JS и полусотне реликтовых языков... все - от программиста.
дополнительная операция преобразования увеличивает уровень потенциальных ошибок
------
Разумеется. Потому 100% этих операций и доверили строить компилятору.
Да и проверить соответствие указатель-функуция можно будет в лучшем случае на этапе выполнения программы
------
Если забираться в дебри Сей, то там есть возможность указать, что функция доступна в пределах компилируемой единицы. Так что вывалится на этапе линковки. Но опять - ты подменяешь концеп реализацией в конкретном языке.
Ты просто рассматриваешь проблемы с точки зрения возможности реализации, а меня еще интересует возможность использования в долгом теам проекте
------
Это - без разницы, при наличии квалифицированного персонала. Проблема будет при низкой квалификации, но в этом случае проблеммы всеравно будут. :) Недели три назад был на интервью в небольшой конторе. Тамошний шеф честно признался - его людям проще писать на VB6, чем на VB/С#.NET... но в коде у них - полный бардак - спагетти в стиле Аксесса...
Важно что есть база а все остальное просто полезные вкусности.
------
Резервируешь в каждой реализации объекта пару специфических методов - Конструктор и Деструктор и отсутствие базы тебя более не беспокоит.
Всегда будет чего то не хватать.
------
Ну хоть с этим проблем нет - реализация всегда ограничена используемым языком.

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

Обыкновенные там зарплаты , в районе 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 центов сказать сколько денег у него было в кошельке каждый день, в течении прошлого месяца.
В принципе имея ехсел, я бы мог тоже это сказать, но для чего мне это нужно. Мне достаточно знать, что там что-то есть и того что есть хватит на то что мне сегодня понадобится.

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

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

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

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

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

Да, я девочка (ну женского пола вернее) ... в програмировании ни бум бум . Я гуманитарий , свободно говорю, и вообще на 5 ти языках (человеческих , не компьтерных), по шабатам не работаю. Дактиль не склоняется .... Что такое SSD ? Куда присылать резюмэ ?
ЗЫ по теме: Мур мне тебя жаль но сэляви ... сколько раз уже наблюдала - иннициатива наказуема, а причин для отказа может быть множество. Вплоть до того, что человек на это место был уже намечен , но начальству нужно было создать видимость, провести пару собеседований и в конце - концов просто продвинуть своего.

Не жалей - Я довольно тяжелый тип... и меня надо уметь правильно использовать... так что Я их понимаю... :)

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

EN,DE,IL,UA,RU ?

Эх, вот в бытность мою сисадминскую – все бы гуманитарии были бы способны
линукс самостоятельно поставить, да еще дистрибутив грамотно выбрать

Senior Software Developer

“Личка” всегда открыта. На Axapta уже трудится человек,
но расширяется отдел продаж запчастей – там надо “свободно говорю”
Пы.Сы. Линукс используем... но только на моих личных компьютерах