Re[2]: Тесты и с++ - О работе

Прочитав предыдущий "http://www.rsdn.ru/forum/message/2635383.aspx" пост по поводу тестирования нового сотрудника возникло
несколько вопросов . На самом деле в вопросах никакого прикола нет , просто я собираюсь скоро сменить работу и ессно буду проходить собеседование и наверняка тестирование ( это не первое тестирование в моей жизни поэтому я в курсе что и как , но , опятьже почитав пост, есть непонятки).

1.Неужели в реальном программинге так часто используються шаблоны?
Я имею гдето 5-6 законченных проектов от начала до конца и хренову кучу доработок и только раз использовал шаблоны , да и то от скуки.
Мне казалось что шаблоны нужны для использования в системных библиотеках а ля буст стл и т.д. .
Неужели так много народу пишет системные библиотеки ?
Я не утверждаю что это нужно не знать , но думаю что в большинстве случаев в шаблонах нет необходимости.

2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?
Если пишу под вин msvc если под nix — gcc типы и размерность данных известны ... BCE.
Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
Много ли кросплатформенных проектов пишуться на сях ?

3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция подсчета
битов — она же подсчитывает (что еще надо?) ...
И тут все полезли меряться пи...ками , типа можно так , а можно и так
, а типа если под такой проц так загнуть а под другой этак ( я думаю и теорию графов тут можно как нибудь прикрутить

).
Мне кажеться — если у тебя есть гвоздь и молоток и тебе надо забить гвоздь — берешь гвоздь
и х..шь по нему молотком пока не забьешь ... ВСЕ ... не надо плясать у молотка
полчаса и обклеивать его стразами для красоты ( поэтому иногда не люблю
когда критикуют типа индийский код ( индийцы в программинге как хохлы в строительстве

быстро и недорого ( не очень красиво , но недорого) ))
... если надо оптимизировать — полчаса в гугле и готово ...
ну или в книге ... В ТОМ СЛУЧАЕ — ЕСЛИ НАДО.
Как часто вам приходиться оптимизировать алгоритмы для работы с битами
если вы пишете софт для обработки данных с какого нибудь мускуля ?

4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30 строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под отладчиком дошлифовываю.
Ебстественно я также пишу на бумаге на собеседовании

. (ну это так — личное)

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

Из последнего собеседования — думаю большинство знает как выяснить —
являеться ли переменная степенью двойки (имееться в виду быстрый алгоритм
if(i & (i-1)) но если нет — реально ли до этого дотумкать в течении пары минут ?
( не взяли , но не изза этого вопроса ( я так думаю )).

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

п.с. и вооще ухожу под С#

все равно еще стандарта через два они с С++ будут похожи ...

01.09.07 14:25: Перенесено из 'C/C++'

C>>эффективность — почему в примере он использует для проверки последнего элемента функцию end()
C>>почему бы не объявить vector<blblabla>::interator end = vec.end();
C>>или же как я — int size = vec.size();
C>> for(int i =0;i<size;i++) // здесь конечно должен быть преaиксный инкремент но поскольку это простой тип я не иду на уступки красивости

C>>чем этот вариант менее эффективен вызову предиктата , учитывая накладные расходы на вызов лишней функции ?
C>>Я не оспариваю что для контейнеров не имеющих произвольного доступа вариант с алгоритмами имеет смысл , но писать везде
C>>по обезьяньи не понимая зачем , а только потому что так надо ...
По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...

Здравствуйте, Uzumaki Naruto, Вы писали:

UN>Потому что, описанные механизмы — потеря производительности и не эффективное использование CPU.
как обычно от вас кроме высокопарных слов опять ничего не увидел...

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

Здравствуйте, kaa.python, Вы писали:

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

Ну если он меня поймает я думаю что он сам не будет знать что ему делать — я вешу 120 и не только сала

а по поводу вышесказанного — И Я О ТОМ ЖЕ-
если например нужно инкрементировать инт — то можно его просто ++ ...
а можно создать класс обертку , ессно лучше шаблонную ( етж круто )
переписать все мыслимые немыслимые конструкторы , операторы приведения типов ,
ессно определиться с операторами сравнения и присваивания , конструктор копий
, нельзя обойтись без обработки исключений в конструкторе , кданить пихнуть смарт поитеры (ессно лучше буст ),
деструктор ессно должен быть виртуальный ... и т.д и т.д.

ааааа ... главное — перегрузить постфиксный и преф ++
неплохо сделать частичную спец шаблона .....

а потом написат суперпуперобъект КУУЛ_ОБЖ(5);
КУУЛ_ОБЖ++;

и че проще поддерживать?

Здравствуйте, Smal, Вы писали:

S>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...
А шаблоны, прям вот, не дополнительный?

Только труднее посмотреть "чего там нагенерилось и почему"

ИМХО это такой спциальный способ улучшить скилы в медитации...

трагично в общем...

_>>>А производительность — то же ключевое слово, тк в некоторых ситуациях именно она является узким местом
C>Да и , к стати , — одна довольно известная фирма по работе с системами реального времени
C>пишет программы на басике ... и ничего ... утверждают что производительность не страдает ...
C>басик .нет разумеется ...
А вы хоть в курсе что такое realtime OS и что винда не является таковой?

А>>А вы хоть в курсе что такое realtime OS и что винда не является таковой?
C>Я в курсе , но хотелось бы узнать Ваше каноническое описание системы реального времени ...

Я лучше проведу аналог чтоб было понятнее что RT OS это совсем ек аналог СВЕРХБЫСТРАЯ OS

Есть в US много служб доставки. Есть и обычная почта. Так вот если заказать товар на ebay обычной почтой с другого побережья то скорее всего он придет к вам дня за два... Но никто ничего не гарантирует и в принципе он может придти и за месяц, хотя про такие случаи мне никто не расказывал. А если воспользоваться службами доставки типа UPS то вам гарантируют что за неделю товар будет у вас. И он в самом деле будет, а иначе вам компенсируют.
Так вот RT OS это OS которая исполняет системные запросы (создание файлов, выделение памяти и тп) за строго оговоренное время, которое обычно медленнее чем на не-RT OS. Но гарантируется что во время создания файла ОС не вздумает посвопиться минутку-другую.
А все остальные определения — это лишь маркетинговые понятия.

Здравствуйте, Smal, Вы писали:

WH>>ИМХО былобы сильно проще написать и поддерживать да и проект компилировался бы сильно быстрее.
S>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...

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

Здравствуйте, Кодт, Вы писали:

К>Дукха — в переводе с санскрита и пали — страдание.
Я не злой. Если говорить о пали, то дукха -- это не просто страдание, а страдание вызванное пристрастиями, жаждой человека к чему-то. Либо жаждой удовольствия, либо жаждой жизни либо жаждой смерти. Так что дукха -- всегда является выбором человека, который не хочет равть связи с миром.

Так что, имхо, пожелание не злое. На русский оно переводится как-то так: "Раз уж тебе нравится геморроиться, таким способом, то геморроиться тебе не перегеморроиться"

Здравствуйте, Erop, Вы писали:

E>Так что, имхо, пожелание не злое. На русский оно переводится как-то так: "Раз уж тебе нравится геморроиться, таким способом, то геморроиться тебе не перегеморроиться"

"В русском языке слова геморрой и головняк — синонимы"

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Erop, Вы писали:
"Да пребудет с тобой дукха"

Зачем ты такой злой, Доцент? Зачем, как собак?

Дукха — в переводе с санскрита и пали — страдание.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, carpenter, Вы писали:

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?

К кроссплатформенности, даже если она реально не нужна, все равно стоит стремиться.

Во-первых все может измениться и когда она вдруг потребуется,
может быть уже поздно. Как пример, см. тут

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

Так же тебе придется избегать платформенно-зависимых хаков...

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

на остальное отвечать не буду, да и это уже скатывание во флейм...

_>>Еще есть ключевое слово везде. Под все ли платформы доступны фреймворки ?
C>MONO ?
ДА что вы говорите ?

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

Есть С и С++. Часто последний с ограничениями. Вы забываете про огромные рынки не PC электроники и микросхем. Возмите хоте бы различные коммутаторы, хот споты итд. Там своя OS, которая иногда, в чем то, может быть похожа на что то линуксовое. И что? Кто туда портировал JVM или MONO ?

Все, замолкаю

Здравствуйте, Erop, Вы писали:

E>Вот именно коробочные продукты мы и пишем. Недавно вышла 12 версия одного из них, например.
E>А прямо сейчас выходит 9-я другого...

Ну прямо ABBYY какой-то.

... << RSDN@Home 1.2.0 alpha rev. 730>>

1. Постоянно. К системным библиотекам этот вопрос не имеет никакого отношения.
2. Постоянно, что бы потом не чесать репу и тратить человеко-ресурсы (время) для получения тоже самого, но под другой платформой или архитектурой (особенно для системных вещей). Есть вещи, где Java не уместна и подобные заявления говорят о слабом знании как с C/C++, так и Java в плане реального применения.
3. Цитата: "Мне кажеться — если у тебя есть гвоздь и молоток и тебе надо забить гвоздь — берешь гвоздь" — вот именно этим и определяется уровень обычного кодера, а не высококвалифицированного разработчика.
3.5. Писать грамотный и оптимизированный код — это умение, такие люди ценнятся, ибо потом не надо тратить человеко-часы (т.е. деньги) компании на оптимизацию. Да и потом это облегчение работы оптимизацтора — не надо заниматься review кода, а портирование наиболее затратных методов под машинный код конкретной платформы.
4. Любому человеку свойственно ошибаться, вопрос в виде ошибок.

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

C>1.Неужели в реальном программинге так часто используються шаблоны?

Достаточно часто. Случаи когда необходимо написать обобщенную логику очень распространены.

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?

Крайне важный момент. и не стоит забывать что есть 32 битные винды и 64 битные.

C>Хотите кросплатформенности — пишите на жабе — в чем проблемы ?

В том что она медленная, не везде это приемлимо.

C>Много ли кросплатформенных проектов пишуться на сях ?

много. очень много.

C>3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция подсчета
C>битов — она же подсчитывает (что еще надо?) ...

Тут я согласен. Хотя, в алгоритме есть явные недочеты.

C>Мне кажеться — если у тебя есть гвоздь и молоток и тебе надо забить гвоздь — берешь гвоздь
C>и х..шь по нему молотком пока не забьешь ... ВСЕ ... не надо плясать у молотка

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

C>п.с. и вооще ухожу под С#

все равно еще стандарта через два они с С++ будут похожи ...

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

A>>(ну, если не требуют в точности написать сигнатуру конструктора копирования

)
L_L>А какую из них ты пишешь?

того который виртуальный

... << RSDN@Home 1.2.0 alpha rev. 673>>

C>Всем спасибо — все что надо -выяснил

C>есть два варианта ... первый — через for и []
C>второй — то ли for_each то ли transform (не часто пользую поэтому не помню) ...
C>я говорю — что пользую for потому что это проще и наглядней и понятней человеку незнакомому с контейнером
C>мне — фи это моветон ... почему не объяснили ... только потому что показывает незнание как писать и использовать
C>предиктаты ( т.е. я то знаю но не вижу смысла) ?
Почему, и в чем смысл давно и аргументированно написано у Скотта Майерса, в книге "Эффективное использование STL". У Вас есть чем опровергнуть то, что там утверждается ?

C>п.с. и за что это вы так шарп не любите ?
C>потому что на нем можно делать то же самое что на цпп только с меньшими знаниями и затратами ?
C>ну только если небольшая потеря производительности ...
Вот. Да же вы сами не написали ключевое слово все. На шарпе/яве нельзя делать всего, что можно на С/С++.
Еще есть ключевое слово везде. Под все ли платформы доступны фреймворки ?
А производительность — то же ключевое слово, тк в некоторых ситуациях именно она является узким местом

PS Боюсь опять все свалится во флейм

Здравствуйте, Аноним, Вы писали:

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

.
Но я не считаю это определение окончательным ибо если исходить из него — то с достаточно
большой долей вероятности можно утверждать что обычная венда тоже хард реал поскольку она наверняка отработает прерывание
в течении суток (что можно гарантировать ) ... исходя из этого следует таки упомянуть время реакции системы на внешние раздражители,
вот здесь и актуально понятие СВЕРХБЫСТРАЯ ОС (в плане реакции, разрешения таймеров , а также переключения контекстов потоков),хотя это и не является каноническим определением...

A>А если воспользоваться службами доставки типа UPS то вам гарантируют что за неделю товар будет у вас.

А если этот товар резиновая женщина , а жена у вас уезжает РОВНО через неделю , а доставили вам за 6 дней ...

как это соотноситься с реалтайм ? ...

А>>>А вы хоть в курсе что такое realtime OS и что винда не является таковой?
C>>Я в курсе , но хотелось бы узнать Ваше каноническое описание системы реального времени ...

А>Я лучше проведу аналог чтоб было понятнее что RT OS это совсем ек аналог СВЕРХБЫСТРАЯ OS

А>Есть в US много служб доставки. Есть и обычная почта. Так вот если заказать товар на ebay обычной почтой с другого побережья то скорее всего он придет к вам дня за два... Но никто ничего не гарантирует и в принципе он может придти и за месяц, хотя про такие случаи мне никто не расказывал. А если воспользоваться службами доставки типа UPS то вам гарантируют что за неделю товар будет у вас. И он в самом деле будет, а иначе вам компенсируют.
А>Так вот RT OS это OS которая исполняет системные запросы (создание файлов, выделение памяти и тп) за строго оговоренное время, которое обычно медленнее чем на не-RT OS. Но гарантируется что во время создания файла ОС не вздумает посвопиться минутку-другую.
А>А все остальные определения — это лишь маркетинговые понятия.

Здравствуйте, Аноним, Вы писали:

А>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
зачем

А>>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
C>зачем

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

Здравствуйте, Smal, Вы писали:

S>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...
Если кодогенератор генерит человекочитаемый код то отладить его гораздо проще чем шаблонные извращения.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, Erop, Вы писали:

E>Ну компилятор C++ + boost::mpl -- это тоже подобное приложение. Только не очень удобное, как в работе, та ки в отладке.
Это так же относится и к кодогенератору.

E>Коенчо очень может быть, что на шаблонах написать было легко, а на кодогенераторе трудно,
E>но в описанном случае мне так кажется, что это не тот случай.
Возможно, что с кодогенератором было бы проще. Мы не пробовали.

E>>>Только труднее посмотреть "чего там нагенерилось и почему"

S>>Некоторые вещи лучше не знать

E>Даже если надо отлаживать?

А чего там отлаживать? Клиентский код остается без изменения. Отлаживайте сколько хотите.
А сами шаблоны отлаживать не нужно. Компилятся, значит работают. Функциональное программирование, однако.

E>>>ИМХО это такой спциальный способ улучшить скилы в медитации...

S>>Скилы в медитации, ИМХО, не так уж плохи

. Не все же время молотком гвозди забивать.
E>Ну да, особенно если приятно и есть богатый инвестор. От чего бы за его счёт не повтыкать?

Да ладно, эта система позволяет очень быстро реализовать новый тип объектов на основе существующих "кубиков".

Здравствуйте, Smal, Вы писали:

S>Сами шаблоны отлаживать нет смысла — они уже работают

.
А это:

По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы

святой дух чтоли делает?

S>К тому же, при не котором понимании, шаблоны перестают быть малопонятными.
Меташоблонные извращения я знаю не хуже тебя.

S>Ну, дык, он должен стоять на компьютере каждого разработчика. Хотя, ИМХО, эту проблему я выдумал — можно положить в репозиторий.
Не можно, а нужно.
И не просто положить, а прописать в системе сборки чтобы она его собирала и если нужно запускала.

S>Именно так работает у нас один кодогенератор (он правда, почему-то не OCaml-e

).
Ну это уже извращения.

S>А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.
Кодогенераторы проще, гибче, быстрее, переносимее...

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

S>>Хорошо вам. Сильно на системы с Лиспом смахивает.
E>Нет. Чистый C++

E>Ну вам тоже могло бы быть хорошо, если бы вы не mpl пользовались, а удобный визуальный редакор заботали

А кто сказал, что нам плохо. И редактор прикрутить не проблема. Только вот на это время нужно.

Здравствуйте, Аноним, Вы писали:

RO>>Может ли компилятор понять, что ++*i не изменяет _M_last? В отсутствие правил strict aliasing — не может. Поэтому он должен вызывать end() каждый раз. И inlining здесь ни при чем. Если вынести вызов end() из условия цикла, это может дать чуточку прироста скорости.
А>Вызов end() это лишь обращение к одному полю структцры c. Самого вызова (call) в асм коде вообще не будет соответственно и экономии никакой не будет при копировании той переменной из структуры на стек.

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

Здравствуйте, Аноним, Вы писали:

У меня шестерка тупо развернула цикл ( благо небольшой ) но тут как говориться —
На компилятор надейся , а сам не плошай

Ибо оптимизация негарантирована ...

А>И где тут вызов end() кторого вы так боялись?

Может он будет если ввести некоторые операции с элементами ?...

C>У меня шестерка тупо развернула цикл ( благо небольшой ) но тут как говориться —
C>На компилятор надейся , а сам не плошай

C>Ибо оптимизация негарантирована ...
А может просто выключена?
Про существование в меню таких пунктов "Build -> Set Active Configururation -> *** — Win32 Release" в курсе?

Здравствуйте, carpenter, Вы писали:

C>1.Неужели в реальном программинге так часто используються шаблоны?
C>Я имею гдето 5-6 законченных проектов от начала до конца и хренову кучу доработок и только раз использовал шаблоны , да и то от скуки.
C>Мне казалось что шаблоны нужны для использования в системных библиотеках а ля буст стл и т.д. .
C> Неужели так много народу пишет системные библиотеки ?
C>Я не утверждаю что это нужно не знать , но думаю что в большинстве случаев в шаблонах нет необходимости.

IMHO, Template Metaprogramming — это "штука посильнее, чем "Фауст" Гете".

Рукава кителя крупным планом. Пальцы ломают "Герцеговину Флор" и
шарят по столу. Голос:
— Ви не видылы маю трубку, таварыщ Горький?
— Я ее выбросил, товарищ Сталин.
— А пачэму?
— Потому, товарищ Сталин, что у вождя мирового
пролетариата может быть только трубка "Тринитрон-плюс"!

Виктор Пелевин. Generation "П"

C>1.Неужели в реальном программинге так часто используються шаблоны?

шаблоны в тривиальном их варианте — часто. навороченные шаблонные конструкции (метапрограммы) —
мне встречались очень редко, и то в основном в коде фреймфорков/библиотек которые написаны раз и навсегда.

C>Я не утверждаю что это нужно не знать , но думаю что в большинстве случаев в шаблонах нет необходимости.
шаблоны ради шаблонов "чтоб было" городить конечно смысла нет, но разные паттерны(стратегия,команда,и т.д.), на с++
часто реализуются с участием шаблонов.

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок >должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?
C>Много ли кросплатформенных проектов пишуться на сях ?

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

C>4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
C>чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30 строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под C>Ебстественно я также пишу на бумаге на собеседовании

. (ну это так — личное)

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

)

C>п.с. и вооще ухожу под С#

все равно еще стандарта через два они с С++ будут похожи ...

A>(ну, если не требуют в точности написать сигнатуру конструктора копирования

)
А какую из них ты пишешь?

Здравствуйте, carpenter, Вы писали:

C>1.Неужели в реальном программинге так часто используються шаблоны?
Да. Используем очень часто. Вся наша математическая библиотека построена на шаблонах. (Там много геометрии)
В обычном коде шаблоны так же используются, но меньше. Просто шаблоны в основном нужны для того, чтобы шарить код.
А если код шарится — он помещается в библиотеку.
+ к этому у нас есть проект на boost::mpl. Там все на шаблонах

.

C>Я имею гдето 5-6 законченных проектов от начала до конца и хренову кучу доработок и только раз использовал шаблоны , да и то от скуки.
C>Мне казалось что шаблоны нужны для использования в системных библиотеках а ля буст стл и т.д. .
C> Неужели так много народу пишет системные библиотеки ?
Почему обязательно системные?

C>Я не утверждаю что это нужно не знать , но думаю что в большинстве случаев в шаблонах нет необходимости.
Необходимости нет (можно вообще все писать на асме). Но с ними многое становится проще.

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?
А зачем использовать непереносимые хаки, если всего можно добиться законными и переносимыми способами?

C>Если пишу под вин msvc если под nix — gcc типы и размерность данных известны ... BCE.
C>Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
К сожалению, жаба не так хороша

.

C>Много ли кросплатформенных проектов пишуться на сях ?
Достаточно. MySQL, Apache, Scintilla, Boost....

C>3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция подсчета
C>битов — она же подсчитывает (что еще надо?) ...
C>И тут все полезли меряться пи...ками , типа можно так , а можно и так
C>, а типа если под такой проц так загнуть а под другой этак ( я думаю и теорию графов тут можно как нибудь прикрутить

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

C>Мне кажеться — если у тебя есть гвоздь и молоток и тебе надо забить гвоздь — берешь гвоздь
C>и х..шь по нему молотком пока не забьешь ... ВСЕ ... не надо плясать у молотка
C>полчаса и обклеивать его стразами для красоты ( поэтому иногда не люблю
C>когда критикуют типа индийский код ( индийцы в программинге как хохлы в строительстве

быстро и недорого ( не очень красиво , но недорого) ))
C>... если надо оптимизировать — полчаса в гугле и готово ...
C>ну или в книге ... В ТОМ СЛУЧАЕ — ЕСЛИ НАДО.
Ты прав. Оптимизировать нужно только тогда, когда это действительно надо. Хотя параллель с молотком мне не нравится.
Не нужно писать априори неоптимальный код.

C> Как часто вам приходиться оптимизировать алгоритмы для работы с битами если вы пишете софт для обработки данных с какого нибудь мускуля ?
Не пишу я такой софт. Но и оптимизировать работу с битами мне не приходилось. Обычно оптимизации подвергаются довольно высокоуровневые алгоритмы.

[...]

C>п.с. и вооще ухожу под С#

все равно еще стандарта через два они с С++ будут похожи ...
Ты заблуждаешься. C# и C++ — очень разные. Похожи они врядли будут.

> 1.Неужели в реальном программинге так часто используються шаблоны?
> Я имею гдето 5-6 законченных проектов от начала до конца и хренову кучу доработок и только раз использовал шаблоны , да и то от скуки.
> Мне казалось что шаблоны нужны для использования в системных библиотеках а ля буст стл и т.д. .
> Неужели так много народу пишет системные библиотеки ?

Не то чтобы слишком часто (если не принимать во внимание библиотеки), но встречаются. Изредка даже для метапрограммирования. Например, у меня в текущем проекте в GUI оказалось удобным добавить компайл-тайм проверку наличия у наследников некоего "визуального объекта" функций Show и Edit, и по результатам проверки показывать соответствующие пункты контекстного меню.

> Я не утверждаю что это нужно не знать , но думаю что в большинстве случаев в шаблонах нет необходимости.
>
> 2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?
> Если пишу под вин msvc если под nix — gcc типы и размерность данных известны ... BCE.

Щаз. Вин у нас бывает еще и x64. Как и лин.

> Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
> Много ли кросплатформенных проектов пишуться на сях ?

Достаточно 1 раз перенести 1 средних размеров проект с VC 6 на VC 7, чтобы появилось стойкое желание давать по рукам за допущения типа vector<T>::iterator == T* и т.п.

Posted via RSDN NNTP Server 2.1 beta

S>Да. Используем очень часто. Вся наша математическая библиотека построена на шаблонах. (Там много геометрии)
S>В обычном коде шаблоны так же используются, но меньше. Просто шаблоны в основном нужны для того, чтобы шарить код.
S>А если код шарится — он помещается в библиотеку.
S>+ к этому у нас есть проект на boost::mpl. Там все на шаблонах

.

Мне вот, увы, приходится иметь дело с достаточно стремным С++ кодом (это скорее С с классами даже, и это не мой код

C>Если пишу под вин msvc если под nix — gcc типы и размерность данных известны ... BCE.
Угу. Все известно. До переползания на 64 бита.
C>Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
Есть мнение, что ява медленней

C>4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
C>чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30 строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под отладчиком дошлифовываю.
C>Ебстественно я также пишу на бумаге на собеседовании

. (ну это так — личное)
На это обычно не обращают внимания

Здравствуйте, Аноним, Вы писали:

S>>Да. Используем очень часто. Вся наша математическая библиотека построена на шаблонах. (Там много геометрии)
S>>В обычном коде шаблоны так же используются, но меньше. Просто шаблоны в основном нужны для того, чтобы шарить код.
S>>А если код шарится — он помещается в библиотеку.
S>>+ к этому у нас есть проект на boost::mpl. Там все на шаблонах

.

А>Мне вот, увы, приходится иметь дело с достаточно стремным С++ кодом (это скорее С с классами даже, и это не мой код

— это тенденция проекта). Использование шаблонов в силу определенных причин ограничивается использованием стандартных библиотек (и даже это вызывает критику). Твой пример мне показался интересным — нельзя ли чуть поподробнее о том, как вы используете шаблоны и boost::mpl ? Т.е. это у вас просто обобщенный код для разных типов или метапрограммирование и т.п. ?
Там именно мета-программирование. Если упрощенно, то несколько mpl::vector-ов (около 10), описывают класс.
По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы
поддерживаются необходимые интерфейсы (генерится QueryInterface), проверяются различные зависимости, поддерживается управление через скрипт, ...
В результате получается класс, отвечающий некоторым заранее заданным свойствам.
То есть создание нового объекта в этой системе сводится к описанию его свойств, состояний и поведений (которые уже предопределены).

Здравствуйте, Smal, Вы писали:

А>>Мне вот, увы, приходится иметь дело с достаточно стремным С++ кодом (это скорее С с классами даже, и это не мой код

— это тенденция проекта). Использование шаблонов в силу определенных причин ограничивается использованием стандартных библиотек (и даже это вызывает критику). Твой пример мне показался интересным — нельзя ли чуть поподробнее о том, как вы используете шаблоны и boost::mpl ? Т.е. это у вас просто обобщенный код для разных типов или метапрограммирование и т.п. ?
S>Там именно мета-программирование. Если упрощенно, то несколько mpl::vector-ов (около 10), описывают класс.
S>По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы
S>поддерживаются необходимые интерфейсы (генерится QueryInterface), проверяются различные зависимости, поддерживается управление через скрипт, ...
S>В результате получается класс, отвечающий некоторым заранее заданным свойствам.
S>То есть создание нового объекта в этой системе сводится к описанию его свойств, состояний и поведений (которые уже предопределены).

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

Здравствуйте, Smal, Вы писали:

S>Там именно мета-программирование. Если упрощенно, то несколько mpl::vector-ов (около 10), описывают класс.
S>По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы
S>поддерживаются необходимые интерфейсы (генерится QueryInterface), проверяются различные зависимости, поддерживается управление через скрипт, ...
S>В результате получается класс, отвечающий некоторым заранее заданным свойствам.
S>То есть создание нового объекта в этой системе сводится к описанию его свойств, состояний и поведений (которые уже предопределены).

гы .... прикольно ... надо позырить

Здравствуйте, carpenter, Вы писали:

Имею ввиду boost::mpl
C>гы .... прикольно ... надо позырить

Здравствуйте, carpenter, Вы писали:

C>Здравствуйте, Smal, Вы писали:

S>>Там именно мета-программирование. Если упрощенно, то несколько mpl::vector-ов (около 10), описывают класс.
S>>По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы
S>>поддерживаются необходимые интерфейсы (генерится QueryInterface), проверяются различные зависимости, поддерживается управление через скрипт, ...
S>>В результате получается класс, отвечающий некоторым заранее заданным свойствам.
S>>То есть создание нового объекта в этой системе сводится к описанию его свойств, состояний и поведений (которые уже предопределены).

C>гы .... прикольно ... надо позырить

Прикольно-то прикольно, но нужны очень хороше знание и понимание шаблонов, что бы разобрать сообщение об ошибке на сотню метров %).
(Мой личный рекорд 239 метров

239-тники молчать!!!

)

Здравствуйте, Uzumaki Naruto, Вы писали:

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

Дык он же написал, что в дровосеки переквалифицируется.

Здравствуйте, Uzumaki Naruto, Вы писали:

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

Да уж ... приходиться писать всякую херню для реалтайм систем работающую 1000/60/60/24/365(6)
и топор за спиной ни ... не мешает

а людей не лечу

Здравствуйте, Smal, Вы писали:

S>Прикольно-то прикольно, но нужны очень хороше знание и понимание шаблонов, что бы разобрать сообщение об ошибке на сотню метров %).
S>(Мой личный рекорд 239 метров

239-тники молчать!!!

)

Я не говорил что я их не знаю ... просто хотел посмотреть распространенность применения ...
но 239 — это жесть

C>Да уж ... приходиться писать всякую херню для реалтайм систем работающую 1000/60/60/24/365(6)
C>и топор за спиной ни ... не мешает

C>а людей не лечу

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

Кстати вот тебе вопросик — раз ты пишешь всякую хрень 1000/60/...: опиши потоковую модель выскопроизводительного application серевиса, обрабатывающую по сети запросы от клиентов.

Здравствуйте, Uzumaki Naruto, Вы писали:

UN>Кстати вот тебе вопросик — раз ты пишешь всякую хрень 1000/60/...: опиши потоковую модель выскопроизводительного application серевиса, обрабатывающую по сети запросы от клиентов.

Я правда такие сервисы не писал —
но если касаеться никсов — то это либо классическая паралельная либо префоркнутая .
для венды — то же самое только с использованием потоков , а не форка ( к тому же на соединение можно поставить один поток).
Пулы потоков использовать ( по крайней мере на qnx ) не очень выгодно (хотя многое зависит от количества соединений и
времени обслуживания соединения т.е. количества траффика и т.д.).
От протокола обмена данными сильно зависит использование блокирующих\неблокирующих сокетов ...
мне больше нравяться блокирующие

( при таком подходе соединение можно разбить еще на два потока —
принимающий и передающий )

Здравствуйте, carpenter, Вы писали:

C>Здравствуйте, Uzumaki Naruto, Вы писали:

C> Я правда такие сервисы не писал —
C>но если касаеться никсов — то это либо классическая паралельная либо префоркнутая .
C>для венды — то же самое только с использованием потоков , а не форка ( к тому же на соединение можно поставить один поток).
C>Пулы потоков использовать ( по крайней мере на qnx ) не очень выгодно (хотя многое зависит от количества соединений и
C>времени обслуживания соединения т.е. количества траффика и т.д.).
C>От протокола обмена данными сильно зависит использование блокирующих\неблокирующих сокетов ...
C>мне больше нравяться блокирующие

( при таком подходе соединение можно разбить еще на два потока —
C>принимающий и передающий )

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

Здравствуйте, carpenter, Вы писали:

C>но если касаеться никсов — то это либо классическая паралельная либо префоркнутая .
Тута я мальца погорячился — классическая паралельная на основе форка не канает
вот с предварительным создание потоков самое оно ... но опять же в зависимости от
количества клиентов размера передаваемых данных возможно имеет смысл и пул ..

S>Там именно мета-программирование. Если упрощенно, то несколько mpl::vector-ов (около 10), описывают класс.
S>По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы
S>поддерживаются необходимые интерфейсы (генерится QueryInterface), проверяются различные зависимости, поддерживается

как интересноооо!

хотел бы я на такой код посмотреть.

Здравствуйте, Uzumaki Naruto, Вы писали:

патамучто гладиолус

UN>трагично в общем...

Потому что, описанные механизмы — потеря производительности и не эффективное использование CPU.

Здравствуйте, carpenter, Вы писали:

C>1.Неужели в реальном программинге так часто используються шаблоны?

У меня используются и довольно часто. Причем чаще всего не на уровне "хаков" a-la Александреску, а несколько более мирно. Очень часто шаблоны у меня получаются в результате рефакторинга, обычно исходный код сокращается где-то в половину, очень удобно.
Единственный раз, когда я немного переборщил с шаблонами, можно увидеть здесь.

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?

Тут к сожалению у меня плохо. Пишу практически только под Win32, очень древние поделки под линукс — что называется "давно и неправда". Так что в этом вопросе я некомпетентен.

C>3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция подсчета
C>битов — она же подсчитывает (что еще надо?) ...

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

C>4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
C>чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30 строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под отладчиком дошлифовываю.

Обычно 20-30 строк у меня компилятся нормально с первого раза. Вот >100 строк, уже да, могут быть какие-то косяки. А вообще я сначала какое-то время думаю, прежде чем начинать кодить. Так что у меня сначала появляется довольно много практически готового кода, а потом идёт мелкая шлифовка и тестирование. Правда иногда бывает, что архитектура классов меня не устраивает, и я могу их все переписать заново практически с нуля. А вот так, чтоб по 20-30 строчек добавлять — это довольно редко.

C>Из реального — мне очень понравился такой метод тестирования —
C>дали проект , компилер и мсдн и попросили убрать при компиляции все ошибки и
C>варнинги и сказать свое мнение по части пары классов ( после тестирования меня брали но на предыдущей работе перебили цену).

Ну, не знаю. Лично мне такой метод не очень нравится, субъективно он значительно легче, чем когда надо самому с нуля код писать.

C>Из последнего собеседования — думаю большинство знает как выяснить —
C>являеться ли переменная степенью двойки (имееться в виду быстрый алгоритм
C>if(i & (i-1)) но если нет — реально ли до этого дотумкать в течении пары минут ?

Не знаю, этот факт уже давно лежит в подсознании. Думаю, за пару минут я бы его оттуда достал.

Если только не заклинит на чём-нибудь.

C>п.с. и вооще ухожу под С#

все равно еще стандарта через два они с С++ будут похожи ...

Удачи на новом поприще

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?
C>Если пишу под вин msvc если под nix — gcc типы и размерность данных известны ... BCE.
C>Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
C>Много ли кросплатформенных проектов пишуться на сях ?
Насчет виндов. Они ведь тоже есть разные. Win32, Win64, WinMobile...

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

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

C>1.Неужели в реальном программинге так часто используються шаблоны?
C>Я имею гдето 5-6 законченных проектов от начала до конца и хренову кучу доработок и только раз использовал шаблоны , да и то от скуки.
C>Мне казалось что шаблоны нужны для использования в системных библиотеках а ля буст стл и т.д. .
C> Неужели так много народу пишет системные библиотеки ?
C>Я не утверждаю что это нужно не знать , но думаю что в большинстве случаев в шаблонах нет необходимости.
А у нас во многих проектах шаблоны есть. Ненавороченные, по сути небольшие хелперы. Но есть — мне они упрощают жизнь. Кстати раньше я их тоже не понимал и писал код без них нифига не понимая зачем нужны эти треугольные скобочки когда можно сделать ctrl+c/ctrl+p и усе будет ок...

C>3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция подсчета
C>битов — она же подсчитывает (что еще надо?) ...
C>И тут все полезли меряться пи...ками , типа можно так , а можно и так
C>, а типа если под такой проц так загнуть а под другой этак ( я думаю и теорию графов тут можно как нибудь прикрутить

).
C>Мне кажеться — если у тебя есть гвоздь и молоток и тебе надо забить гвоздь — берешь гвоздь
C>и х..шь по нему молотком пока не забьешь ... ВСЕ ... не надо плясать у молотка
C>полчаса и обклеивать его стразами для красоты ( поэтому иногда не люблю
C>когда критикуют типа индийский код ( индийцы в программинге как хохлы в строительстве

быстро и недорого ( не очень красиво , но недорого) ))
C>... если надо оптимизировать — полчаса в гугле и готово ...
C>ну или в книге ... В ТОМ СЛУЧАЕ — ЕСЛИ НАДО.
C> Как часто вам приходиться оптимизировать алгоритмы для работы с битами
C>если вы пишете софт для обработки данных с какого нибудь мускуля ?
Если бы да кабы. Мы вот например — системшики-безопасники... И тут даже математика бывает нужна.

C>4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
C>чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30 строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под отладчиком дошлифовываю.
C>Ебстественно я также пишу на бумаге на собеседовании

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

C>Из реального — мне очень понравился такой метод тестирования —
C>дали проект , компилер и мсдн и попросили убрать при компиляции все ошибки и
C>варнинги и сказать свое мнение по части пары классов ( после тестирования меня брали но на предыдущей работе перебили цену).
нуну... Не сомневаюсь что понравился

C>п.с. и вооще ухожу под С#

все равно еще стандарта через два они с С++ будут похожи ...
А кто держит? Скатертью дорожка. Чем меньше конкурентов на рынке труда тем лучше

Здравствуйте, carpenter, Вы писали:

Всем спасибо — все что надо -выяснил

Хочу внести только некоторые пояснения —

1. Я имел в виду не использование а написание собственных шаблонов ...
использование это само собой ...практически все библиотеки их юзают даже мфц ... и кудауж без вектора

и стрингов

2 64 бита не учел ... но гуи ? эт так риторически ...

3. Самый больной моя мозоль —
Я просто имел в виду — что не вижу смысла в преждевременной оптимизации или излишнем усложнении кода
только ради того чтобы показать свои знания.
Из реального — на собеседовании
нужно было сделать обход вектора с выполнением к каждому члену какойто операции —
есть два варианта ... первый — через for и []
второй — то ли for_each то ли transform (не часто пользую поэтому не помню) ...
я говорю — что пользую for потому что это проще и наглядней и понятней человеку незнакомому с контейнером
мне — фи это моветон ... почему не объяснили ... только потому что показывает незнание как писать и использовать
предиктаты ( т.е. я то знаю но не вижу смысла) ?
Это то что я имел в виду.

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

Здравствуйте, Uzumaki Naruto, Вы писали:

UN>Потому что, описанные механизмы — потеря производительности и не эффективное использование CPU.

обоснуйте

C>п.с. и за что это вы так шарп не любите ?
C>потому что на нем можно делать то же самое что на цпп только с меньшими знаниями и затратами ?
C>ну только если небольшая потеря производительности ...

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Smal, Вы писали:

S>>Там именно мета-программирование. Если упрощенно, то несколько mpl::vector-ов (около 10), описывают класс.
S>>По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы
WH>Я бы написал внешний кодогенератор.
WH>ИМХО былобы сильно проще написать и поддерживать да и проект компилировался бы сильно быстрее.
Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...

Здравствуйте, dip_2000, Вы писали:

C>>Всем спасибо — все что надо -выяснил

_>Почему, и в чем смысл давно и аргументированно написано у Скотта Майерса, в книге "Эффективное использование STL". У Вас есть чем опровергнуть то, что там утверждается ?

Опровергать не буду ... но ... есть некоторые замечания —

эффективность — почему в примере он использует для проверки последнего элемента функцию end()
почему бы не объявить vector<blblabla>::interator end = vec.end();
или же как я — int size = vec.size();
for(int i =0;i<size;i++) // здесь конечно должен быть преaиксный инкремент но поскольку это простой тип я не иду на уступки красивости

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

правильность — я не делаю ошибок

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

_>Вот. Да же вы сами не написали ключевое слово все. На шарпе/яве нельзя делать всего, что можно на С/С++.
Так ли сильно это надо ? в конце концов критическую часть кода можно писать и на цпп

опять же есть unmanaged
_>Еще есть ключевое слово везде. Под все ли платформы доступны фреймворки ?
MONO ?
_>А производительность — то же ключевое слово, тк в некоторых ситуациях именно она является узким местом
см выше ...

_>PS Боюсь опять все свалится во флейм

may be ... may be

A>того который виртуальный

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

Здравствуйте, carpenter, Вы писали:

_>>А производительность — то же ключевое слово, тк в некоторых ситуациях именно она является узким местом

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

Здравствуйте, carpenter, Вы писали:

C>эффективность — почему в примере он использует для проверки последнего элемента функцию end()
C>почему бы не объявить vector<blblabla>::interator end = vec.end();
C>или же как я — int size = vec.size();
C> for(int i =0;i<size;i++) // здесь конечно должен быть преaиксный инкремент но поскольку это простой тип я не иду на уступки красивости

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

size можно написать, но vec.end() использовать как-то привычнее. Я не думаю, что это является сложной задачей для компилятора — сгенерировать для такого случая оптимальный код.
Преждевременную оптимизацию не люблю тоже.

C>удобство сопровождения — с моим кодом позже будут работать люди , которые возможно и не слышали слова stl

Плохой аргумент, вполне возможно, что с вашим кодом будут работать люди, которые вообще не слышали о С++ и программировании. Но это не повод писать код на самом низком уровне. stl уже давно часть С++, поэтому можно предполагать, что либо человек знает stl, либо не пишет на С++.

C>опять же есть unmanaged
_>>Еще есть ключевое слово везде. Под все ли платформы доступны фреймворки ?
C>MONO ?

Какая-то она сырая ещё. Тут лучше в пример Java привести — реализации есть под гораздо большее количество платформ.

Здравствуйте, Аноним, Вы писали:

А>А вы хоть в курсе что такое realtime OS и что винда не является таковой?

На самом деле winCE позиционируеться как softrealtime что и являеться правдой
поскольку при постоянном цикле в 10 мсек таймер выдерживает погрешность около 5 мсек
(qnx себе такого не позволяет ) , но для большинства задач управления
сия погрешность незначительна .
Латентность прерываний не проверял .
В перспективе перехода на двухядреные процессоры — операционка будет исполняться на одном
реалтайм на другом , так что есть перспективы , что СЕ станет хардреалтайм
а под 2000 венду уже существуют расширения позволяющие реализовать подобную
функциональность —
Насколько это работоспособно сказать не могу — не тестировал , но дуиаю в системах реального времени
вполне и вполне перспективно ...

Здравствуйте, Аноним, Вы писали:

А>А вы хоть в курсе что такое realtime OS и что винда не является таковой?

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

Здравствуйте, Аноним, Вы писали:

А>>>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
C>>зачем

А>гг... Затем что в реальных проектах такие вещи очень часты, и над реальными проектами работают с одним и тем же кодом десятки и сотни человек.

Обычно когда меняется контейнер, меняются также способы и алгоритмы работы с ним.

А>>>>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
C>>>зачем

А>>гг... Затем что в реальных проектах такие вещи очень часты, и над реальными проектами работают с одним и тем же кодом десятки и сотни человек.

AJD>Обычно когда меняется контейнер, меняются также способы и алгоритмы работы с ним.
А почему НЕ писать так, что бы ваш способ работы с ним(обход и спользованием итератора) оставался рабочим ? Я не говорю стремиться во всем к этому, это утопия. Но когда нужно обойти все элементы вектора, почему не применять итераторы(алгоритмы) которые останутся валидными при смене контейнера?

Здравствуйте, dip_2000, Вы писали:

Не ссорьтесь горячие финские парни

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Smal, Вы писали:

S>>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...
WH>Если кодогенератор генерит человекочитаемый код то отладить егогораздо проще чем шаблонные извращения.
Я имел ввиду, что кодогенератор — это тоже отдельный проект, который будет требовать написания, отладки, должной инсталляции и поддержки.

Здравствуйте, carpenter, Вы писали:

C>2.Кросплатформенность – опять тотже вопрос – неужели так много народу пишет на С++ кросплатформенные приложения , которые еще вдобавок должны компилиться любыми компиляторами под любые операционки и под любые архитектуры процессоров?
C>Если пишу под вин msvc если под nix — gcc типы и размерность данных известны ... BCE.
Пишешь для реалтайм-систем и пренебрегаешь кросплатформенностью...
А если придется переходить на другую железку?

C>Из реального — мне очень понравился такой метод тестирования —
C>дали проект , компилер и мсдн и попросили убрать при компиляции все ошибки и
C>варнинги и сказать свое мнение по части пары классов ( после тестирования меня брали но на предыдущей работе перебили цену).
Если ищешь работу — ориентируйся не на те тесты, которые нравятся, а на те — которые популярны.
Вряд ли кто-нибудь будет использовать такой тест, не очень это серьёзно как-то.

Здравствуйте, Smal, Вы писали:

S>Я имел ввиду, что кодогенератор — это тоже отдельный проект, который будет требовать написания, отладки, должной инсталляции и поддержки.
А гора мутных меташаблонов которая очень медленно компилируется и выдает огромные и малопонятные сообщения об ошибках типа написания, отладки и поддержки не требует?
Про инсталяцию вобще не понял ибо кодогенератор работает на этапе сборки проекта.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, R.O. Prokopiev, Вы писали:

ROP>А если придется переходить на другую железку?
Эт совершенно маловероятно ...

C>>Из реального — мне очень понравился такой метод тестирования —
C>>дали проект , компилер и мсдн и попросили убрать при компиляции все ошибки и
C>>варнинги и сказать свое мнение по части пары классов ( после тестирования меня брали но на предыдущей работе перебили цену).
ROP>Если ищешь работу — ориентируйся не на те тесты, которые нравятся, а на те — которые популярны.
ROP>Вряд ли кто-нибудь будет использовать такой тест, не очень это серьёзно как-то.

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

Если немного усложнить тест и привнести багу — дать отладчик и исходники и посмотреть как человек найдет и как
решит — я думаю это покажет более реальные знания и умение обращаться с инструментами чем теоретические тесты ...
ИМХО конечно

Здравствуйте, Аноним, Вы писали:

А>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
Почему так скромно? От чего не на XXX::BTree?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Smal, Вы писали:

S>>Я имел ввиду, что кодогенератор — это тоже отдельный проект, который будет требовать написания, отладки, должной инсталляции и поддержки.
WH>А гора мутных меташаблонов которая очень медленно компилируется и выдает огромные и малопонятные сообщения об ошибках типа написания, отладки и поддержки не требует?
Сами шаблоны отлаживать нет смысла — они уже работают

. К тому же, при не котором понимании, шаблоны перестают быть малопонятными.

WH>Про инсталяцию вобще не понял ибо кодогенератор работает на этапе сборки проекта.
Ну, дык, он должен стоять на компьютере каждого разработчика. Хотя, ИМХО, эту проблему я выдумал — можно положить в репозиторий.
Именно так работает у нас один кодогенератор (он правда, почему-то не OCaml-e

).
Правда там средствами языка было не обойтись — нужно генерировать параллельные структуры на C++ и C#.
А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.

WH>А гора мутных меташаблонов которая очень медленно компилируется и выдает огромные и малопонятные сообщения об ошибках типа написания, отладки и поддержки не требует?

Есть ли ссылка, где можно посмотреть на реальное использование кодогенератора (желательно для "чайников") или to google?

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

S>>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...
E>А шаблоны, прям вот, не дополнительный?

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

E>Только труднее посмотреть "чего там нагенерилось и почему"

Некоторые вещи лучше не знать

E>ИМХО это такой спциальный способ улучшить скилы в медитации...

Скилы в медитации, ИМХО, не так уж плохи

. Не все же время молотком гвозди забивать.

Здравствуйте, Smal, Вы писали:

S>Под дополнительным уровнем косвенности я подразумевал дополнительное средство разработки.
S>Т.е. в добавок к компилятору появляется еще одно приложение, которое обрабатывает код.

Ну компилятор C++ + boost::mpl -- это тоже подобное приложение. Только не очень удобное, как в работе, та ки в отладке.
Коенчо очень может быть, что на шаблонах написать было легко, а на кодогенераторе трудно, но в описанном случае мне так кажется, что это не тот случай.

E>>Только труднее посмотреть "чего там нагенерилось и почему"

S>Некоторые вещи лучше не знать

Даже если надо отлаживать?

E>>ИМХО это такой спциальный способ улучшить скилы в медитации...

S>Скилы в медитации, ИМХО, не так уж плохи

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

Здравствуйте, Smal, Вы писали:

S>А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.
Не, ну если вы там медитацией наслаждаетесь, а от разработки простого довольно сишного проекта мучаетесь, и есть деньги на все эти удовольствия, то от чего бы и нет.

А если серьёзно, то свой кодогенератор имеет такое преимущество, что входной язык можно сделать весьма адекватным задаче, что позволит использовать на программировании "метакода" спецов в предметной области, а не в boost::mpl и продвинутых шаблонах C++. Например метакод можно локализовать, или вообще приделать визуальный редактор...

Здравствуйте, WolfHound, Вы писали:

Нашел достаточно простой http://eao197.narod.ru/rucodegen/index.html от eao197

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

Здравствуйте, Alexander Pazdnikov, Вы писали:

AP>Есть ли ссылка, где можно посмотреть на реальное использование кодогенератора (желательно для "чайников") или to google?

Насколько я понял речь шла о декларативном описании GUI, составленного из разнообразных компонент.
Смотри, например, как под классической MAC OS писался гуй под Powr Plant'ом.

Здравствуйте, Smal, Вы писали:

S>Скилы в медитации, ИМХО, не так уж плохи

. Не все же время молотком гвозди забивать.

Млин докопались до молотка

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

Можно еще позаимствовать фразу у WolfHound точнее у Энштейна ...

(она мне нравиться даже больше чем предыдущее сравнение)
где то я ее уже упоминал на рсдн

—

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Alexander Pazdnikov, Вы писали:

AP>>Есть ли ссылка, где можно посмотреть на реальное использование кодогенератора (желательно для "чайников") или to google?

E>Насколько я понял речь шла о декларативном описании GUI, составленного из разнообразных компонент.
E>Смотри, например, как под классической MAC OS писался гуй под Powr Plant'ом.
Спасибо.

А что можете сказать про embbeded системы? Про гуй и Power Plant почитаю на выходные.
Как использовать кодогенераторы для системных задач?

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

Здравствуйте, Erop, Вы писали:

E>А если серьёзно, то свой кодогенератор имеет такое преимущество, что входной язык можно сделать весьма адекватным задаче, что позволит использовать на программировании "метакода" спецов в предметной области, а не в boost::mpl и продвинутых шаблонах C++.
Весь метакод спрятан в макросы, так что непосредственно сложные mpl-ные шаблоны наружу не лезут.
Таким образом, можно человеку, плохо знающему шаблоны, просто сказать, что дык вот так записывается необходимый набор свойств.
Вот сюда писать интерфейсы. И т.п. Т.е. конечные пользователь может (в идеале) и не знать, что происходит внутри компилятора.

E>Например метакод можно локализовать, или вообще приделать визуальный редактор...
Визуальный редактор, это хорошо. Мы об этом думали. Эту проблему можно решить и без кодогенератора.
Опять же редактор просто расставляет необходимые макросы по "галочкам". И все.

Здравствуйте, Alexander Pazdnikov, Вы писали:

AP>А что можете сказать про embbeded системы? Про гуй и Power Plant почитаю на выходные.
AP>Как использовать кодогенераторы для системных задач?

У нас в конторе есть много кодогенераторов. Верне не так. Используется много входных языков, оптимизированных под какие-топрикладные задачи.
Обычно такое решение состоит из трёх частей.
1) Поддержка сгенерированного кода из C++
2) Собственно кодогенератор
3) Простая среда разработки/отладки (можно ME например использовать или VS закастомайзить)
Ну и справка ко всему этому.

Это позволяет заниматься разработкой текстов, на входном языке кодогенератора, людям, которые хорошо разбираются в вопросе, который прогается, а не в шаблонах там или кодогенераторах...

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

Здравствуйте, WolfHound, Вы писали:

S>>Сами шаблоны отлаживать нет смысла — они уже работают

.
WH>А это:
WH>

По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы

WH>святой дух чтоли делает?
Это все уже внутри библиотеки делается. Конечному пользователю туда лезть незачем.

S>>К тому же, при не котором понимании, шаблоны перестают быть малопонятными.
WH>Меташоблонные извращения я знаю не хуже тебя.
Спорить не буду. Только интересно, откуда дровишки.. тьфу.. сведения?
Скорей всего ты знаешь даже лучше меня, ибо опыт у меня не большой. Но ИМХО, такие заявления бессодержательны.

S>>Ну, дык, он должен стоять на компьютере каждого разработчика. Хотя, ИМХО, эту проблему я выдумал — можно положить в репозиторий.
WH>Не можно, а нужно.
WH>И не просто положить, а прописать в системе сборки чтобы она его собирала и если нужно запускала.
Угу, согласен.

S>>Именно так работает у нас один кодогенератор (он правда, почему-то не OCaml-e

).
WH>Ну это уже извращения.
Почему? Парень набросал этот генератор за вечер. С тех пор и живем — забот не знаем.
Больше времени на разговоры потратили.

S>>А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.
WH>Кодогенераторы проще, гибче, быстрее, переносимее...
В нашем случае о переносимости на другую операционку речи не идет (много COM-а).
К том уже, мы можем себе это позволить, ибо поставляем железо вместе с начинкой.
А под виндой, MSVC шаблоны и так прилично поддерживает.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Alexander Pazdnikov, Вы писали:

AP>>А что можете сказать про embbeded системы? Про гуй и Power Plant почитаю на выходные.
AP>>Как использовать кодогенераторы для системных задач?

E>У нас в конторе есть много кодогенераторов. Верне не так. Используется много входных языков, оптимизированных под какие-топрикладные задачи.
E>Обычно такое решение состоит из трёх частей.
E>1) Поддержка сгенерированного кода из C++
E>2) Собственно кодогенератор
E>3) Простая среда разработки/отладки (можно ME например использовать или VS закастомайзить)
E>Ну и справка ко всему этому.

E>Это позволяет заниматься разработкой текстов, на входном языке кодогенератора, людям, которые хорошо разбираются в вопросе, который прогается, а не в шаблонах там или кодогенераторах...

E>Ну и поддержка сильно удешевляется, так как хорош разграничены зоны ответсвенности и компетенции...
Хорошо вам. Сильно на системы с Лиспом смахивает.

Здравствуйте, Smal, Вы писали:

Вау!

Так у вас там ещё и макросы наверчены!!! Круть!!!

S>Таким образом, можно человеку, плохо знающему шаблоны, просто сказать, что дык вот так записывается необходимый набор свойств.
S>Вот сюда писать интерфейсы. И т.п. Т.е. конечные пользователь может (в идеале) и не знать, что происходит внутри компилятора.

Ну и он где-то чего-то не так напишет и дальше все пытаются понять что за фигня случилась.
Был у меня например один проект, где надо было описывать какие-то хитрые лингвистические конструкции, сначала это сделали на макросах, как ты и описал примерно. Только без шаблонов. Ну был там такой лиспоподобный уродский относительно синтаксис описателей, посадили спеца писать эти описания. Ну писал он их, получалочсь через раз. Он даже научился отлаживать большинство ошибок компиляции, но семантические ошибки уже не понимал как находить. Ему же его сложную довольно метапрограмму надо было отлаживать!!!
Так что её отлаживал я

Когда меня это допекло (проект было очень низкоприоритетный), я таки сделал довольно простой кодогенератор, и две версии C++ интерпретатора. Во второй омжно было записывать дебажную информацию.
Соответсвенно, кодогенератор стал выдавать все ошибки связанные с несовместностью заданного описания, а дебажная версия кода (включалось флажком в генераторе) ещё и описывало дебажную инфу о сбое, в отдельном окошке. И всё, после этого я поправил там две ошибки. Специалист всё сделал сам

E>>Например метакод можно локализовать, или вообще приделать визуальный редактор...
S>Визуальный редактор, это хорошо. Мы об этом думали. Эту проблему можно решить и без кодогенератора.
S>Опять же редактор просто расставляет необходимые макросы по "галочкам". И все.
Ну да, но редактор может расставлять и "просто С++ классы" ничуть не хуже

Здравствуйте, Smal, Вы писали:

E>>Ну компилятор C++ + boost::mpl -- это тоже подобное приложение. Только не очень удобное, как в работе, та ки в отладке.
S>Это так же относится и к кодогенератору.
Не, ну это уже как напишите

E>>>>Только труднее посмотреть "чего там нагенерилось и почему"

S>>>Некоторые вещи лучше не знать

E>>Даже если надо отлаживать?

S>А чего там отлаживать? Клиентский код остается без изменения. Отлаживайте сколько хотите.
S>А сами шаблоны отлаживать не нужно. Компилятся, значит работают. Функциональное программирование, однако.

Ну а там вот ты описывал сложные всякие конструёвины, которые рожаются всей этой хреновиной. Вот если "а включаешь -- не работает", что происходит дальше?

S>Да ладно, эта система позволяет очень быстро реализовать новый тип объектов на основе существующих "кубиков".
А если что-то сразу не складывается, то что происходит?...

Здравствуйте, Smal, Вы писали:

S>Хорошо вам. Сильно на системы с Лиспом смахивает.
Нет. Чистый C++

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

E>Вау!

Так у вас там ещё и макросы наверчены!!! Круть!!!
ИМХО, ничего страшного в них нет, если они не заменяют функцию, а позволяют декларировать некоторые свойства.
Вроде THIS_CLASS_IS_POD(SomeStruct).

S>>Таким образом, можно человеку, плохо знающему шаблоны, просто сказать, что дык вот так записывается необходимый набор свойств.
S>>Вот сюда писать интерфейсы. И т.п. Т.е. конечные пользователь может (в идеале) и не знать, что происходит внутри компилятора.
E>Ну и он где-то чего-то не так напишет и дальше все пытаются понять что за фигня случилась.
Возможно. В данном случае помогают осмысленные static-assert-ы.

E>Был у меня например один проект, где надо было описывать какие-то хитрые лингвистические конструкции, сначала это сделали на макросах, как ты и описал примерно. Только без шаблонов. Ну был там такой лиспоподобный уродский относительно синтаксис описателей, посадили спеца писать эти описания. Ну писал он их, получалочсь через раз. Он даже научился отлаживать большинство ошибок компиляции, но семантические ошибки уже не понимал как находить. Ему же его сложную довольно метапрограмму надо было отлаживать!!!
E>Так что её отлаживал я

E>Когда меня это допекло (проект было очень низкоприоритетный), я таки сделал довольно простой кодогенератор, и две версии C++ интерпретатора.
Две версии интерпретатора С++?

E>>>Например метакод можно локализовать, или вообще приделать визуальный редактор...
S>>Визуальный редактор, это хорошо. Мы об этом думали. Эту проблему можно решить и без кодогенератора.
S>>Опять же редактор просто расставляет необходимые макросы по "галочкам". И все.
E>Ну да, но редактор может расставлять и "просто С++ классы" ничуть не хуже

Но тогда придется программировать то, что уже есть в компиляторе C++.

Здравствуйте, Smal, Вы писали:

S>Это все уже внутри библиотеки делается. Конечному пользователю туда лезть незачем.
Ну и в кодогенератор ему лезть незачем.

S>Почему? Парень набросал этот генератор за вечер. С тех пор и живем — забот не знаем.
S>Больше времени на разговоры потратили.
А нафига сюда еще и OCaml тащить?
Его же отдельно ставить надо.

WH>>Кодогенераторы проще, гибче, быстрее, переносимее...
S>В нашем случае о переносимости на другую операционку речи не идет (много COM-а).
Видишь только то что хочешь? А как насчет остального?

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, Erop, Вы писали:

E>Вау!

Так у вас там ещё и макросы наверчены!!! Круть!!!
Ну квадратные глаза делать не стоит.
Даже плюсовые макросы и шаблоны в определенных рамках работают лучше внешних кодогенераторов. (А если писать на немерле... то про внешние кодогенераторы вобще можно забыть

)
Например я кроме конкретного кода генерирую кучу вызовов макросов (таким образом генерируемый код получается сильно читабельнее).
А еще я генерирую 2 макроса которые дергаю из рукописного кода.
Да и в качестве входного языка я использую код на С++... кодогенератор выцепляет вызовы некоторых макросов и на информации полученой из иргументов макросов генерит код.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

E>>>Ну компилятор C++ + boost::mpl -- это тоже подобное приложение. Только не очень удобное, как в работе, та ки в отладке.
S>>Это так же относится и к кодогенератору.
E>Не, ну это уже как напишите

Согласен. Тут уже вопрос сколько на это сил уйдет.

E>>>>>Только труднее посмотреть "чего там нагенерилось и почему"

S>>>>Некоторые вещи лучше не знать

E>>>Даже если надо отлаживать?

S>>А чего там отлаживать? Клиентский код остается без изменения. Отлаживайте сколько хотите.
S>>А сами шаблоны отлаживать не нужно. Компилятся, значит работают. Функциональное программирование, однако.

E>Ну а там вот ты описывал сложные всякие конструёвины, которые рожаются всей этой хреновиной. Вот если "а включаешь -- не работает", что происходит дальше?

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

S>>Да ладно, эта система позволяет очень быстро реализовать новый тип объектов на основе существующих "кубиков".
E>А если что-то сразу не складывается, то что происходит?...

Сообщение об ошибке. Это же, в конце концов, код.
А если кодогенератор сгенерит что-то, что не компилируется. Что происходит?

Здравствуйте, Smal, Вы писали:

S>Две версии интерпретатора С++?
Со стороны C++ была некоторая система калссов, которая использовала это лингвистическое описание. Её я и назвал словом "интерпретатор".
Сначала интерпретатор был устроен так, что макросами генерировалась некоторая статическая таблица, по которой он потом и работал.
Потом я переделал так, что кодогенератор генерил некий код, собираемый из примитивов, который собственно и являлась кодом интерпретатора, но примитивы всё равно опирались на некий фреймворк. Так вот можно было привлечь фреймворк и фреймворкExt, второе случалось, если ты в примитивах указывал отладочную информацию...

E>>Ну да, но редактор может расставлять и "просто С++ классы" ничуть не хуже

S>Но тогда придется программировать то, что уже есть в компиляторе C++.
Это опять же зависит от того, что и как вы напишите.
Я так понимаю, что вы декларируете какой-то набор свойств, по которому строите какой-то конечный автомат, который и используется в дальнейшей работе. Так вот, мне кажется что стрить автомат и проверять его корректность удоьнее не из CT-шаблонов, а простым и ясным C++ кодом. И проверки просто записывать и генерировать всё удобно и представление данных можно какое хочешь выбрать...

Ну а потом, эту готовую структуру, надо отобразить в C++ код, я так понимаю. Соответсвенно тут всё упирается в ваш "интерпретатор" ( (с) см. выше

). ИМХО если написать его прямо, то превратить структуру объектов в С++ код должно быть довольно просто.

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Smal, Вы писали:

S>>Это все уже внутри библиотеки делается. Конечному пользователю туда лезть незачем.
WH>Ну и в кодогенератор ему лезть незачем.
Дык и хорошо. Кто спорит.

WH>А нафига сюда еще и OCaml тащить?
WH>Его же отдельно ставить надо.
Не надо его ставить. Положил exe-шник в репозиторий и ок.

WH>>>Кодогенераторы проще, гибче, быстрее, переносимее...
S>>В нашем случае о переносимости на другую операционку речи не идет (много COM-а).
WH>Видишь только то что хочешь? А как насчет остального?
О простоте: Кодогенератор — это отдельный проект.
Хороший кодогенератор, который умеет делать хотябы половину того, что умеет mpl надо писать и отлаживать.
А mpl — прикрутил и вперед. Собственно сама библиотека — десяток хедеров.
Если о простоте использования, то кодогенератор должен иметь какой-то описательный язык.
Все сложные констуёвины можно обернуть в макросы. И таким образом тоже получаем свой язык.
Удобство одинаково. Единственное, что кодогенератор может в принципе использовать любой извращенный язык,
а в нашем случае — все ограничивается макросами. Да и по барабану.

Про гибкость — в чем она? В любом случае каждая новая фича требует изменения кодогенератора.

Про скорость — возможно, если в смысле компиляции. Но это не первоочередной фактор.

Здравствуйте, Smal, Вы писали:

E>>Не, ну это уже как напишите

S>Согласен. Тут уже вопрос сколько на это сил уйдет.
Не, ну если вам простой код писать сложнее, чем метопрограммировать, то я преклоняюсь конечно, но не разделяю

S>Если так, то я преклоняюсь

Ну в некоторых таки есть

Но вообще-то всё просто. Насколько я понял у вас есть метапрограмма, написанная на входном языке кодогенератора и собственно реализация, которая превращает эту метапрограмму в C++ код, который и работает. То есть это некий фреймворк + собственно нагенерированный код.
В случае кодогенераторов обычно делают так, что ошибки в метапрограмме приводят либо к тому, что она не компилируется, либо к тому, что результат компиляции не работает, но выдаёт диагностику в терминах метапрограммы (ну типа там такое-то свойство противоречит такому-то, или операция провалилась, потому что вот тут у вас логическое противоречие выплыло).
А в случае ошибки во фреймворке, то всё как обычно, assert'ы там, проверки...

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

А у вас как всё происходит?

E>>А если что-то сразу не складывается, то что происходит?...

S>Сообщение об ошибке. Это же, в конце концов, код.
Очень хорошо. Вот я пользователь. Вот у меня не скопилировалось и я получил какой-то бесконечный отчёт о шаблонных подстановках где что-то с чем-то не склеелось.
Заметь, что писал я при этом какие-то макросы, про которые даже не знал это макросы...
Как мне хотя бы понять. Это у меня ошибка или у вас?

S>А если кодогенератор сгенерит что-то, что не компилируется. Что происходит?
А если кодогенератор генерит то, что не компилируется, то авторы кодогенератора ищут у себя ошибку

Здравствуйте, Smal, Вы писали:

S>+ к этому у нас есть проект на boost::mpl. Там все на шаблонах

.

А можешь выдержками поделиться? Хочется почувствовать: каково это — всё на шаблонах, тем более — всё на mpl.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Кодт, Вы писали:

К>А можешь выдержками поделиться? Хочется почувствовать: каково это — всё на шаблонах, тем более — всё на mpl.
В одном можно быть уверенным -- компилируется очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень долго

Здравствуйте, Smal, Вы писали:

S>О простоте: Кодогенератор — это отдельный проект.
И?
S>Хороший кодогенератор, который умеет делать хотябы половину того, что умеет mpl надо писать и отлаживать.
Кодогенератор не должен уметь делать весь этот бред что делает boost::mpl.
Оно ему не надо!
Кодогенератор должен генерить код.

S>А mpl — прикрутил и вперед.
Пить чай пока это все скомпилится...

S>Про гибкость — в чем она?
Попробуй на шаблонах реализовать алгоритм поиска кратчайших путей в ориентированном графе от каждой вершины до каждой.
Вершин в графе больше 20...
В кодогенароторе я просто реализовал алгоритм Алгоритм Флойда-Уоршолла.
Работает мнгновенно.

S>В любом случае каждая новая фича требует изменения кодогенератора.
В любом случае каждая новая фича требует изменения шаблонов.

S>Про скорость — возможно, если в смысле компиляции. Но это не первоочередной фактор.
Лично мне очень не нравится когда проект компилируется часами.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Smal, Вы писали:

S>>О простоте: Кодогенератор — это отдельный проект.
WH>И?
Отдельный проект => дополнительный геморрой. ИМХО.

S>>Хороший кодогенератор, который умеет делать хотябы половину того, что умеет mpl надо писать и отлаживать.
WH>Кодогенератор не должен уметь делать весь этот бред что делает boost::mpl.
WH>Оно ему не надо!
WH>Кодогенератор должен генерить код.
А что тогда он должен делать? mpl умеет жонглировать шаблонами классов.
А что тогда должен делать генератор? Просто генерировать код? А зависимости, статические проверки и т.п.?

S>>А mpl — прикрутил и вперед.
WH>Пить чай пока это все скомпилится...
Ну, в действительности у страха глаза велики. Не так уж и долго. В проекте ~50 объектов.
Компилится он минут 5. Не так уж и страшно. К тому же мы планируем его разделить => ускорим билд.

S>>Про гибкость — в чем она?
WH>Попробуй на шаблонах реализовать алгоритм поиска кратчайших путей в ориентированном графе от каждой вершины до каждой.
WH>Вершин в графе больше 20...
WH>В кодогенароторе я просто реализовал алгоритм Алгоритм Флойда-Уоршолла.
WH>Работает мнгновенно.
Охренеть. Наверное, в кодогенераторе можно подключиться к удаленному серверу и залить оттуда последний snapshot какой-нибудь библиотеки.
Или просчитать траекторию полета крылатой ракеты в условиях семибального шторма. Только мне все это не нужно.
Ты правильно сказал, генератор должен генерить код. Максимум, что мне нужно — операции над последовательностями.
К примеру, есть набор классов V. От этих классов средствами mpl получаем производный класс C.
Теперь мне нужно выбрать из V те классы, которые имеют функцию F и вызвать её в определенный момент у объекта класса C.
Для этого надо скастить этот объект ко всем базам, имеющим эту функцию и вызвать её.
По хорошему, ничего кроме итераторов, for_each, copy, transform, filter, foldr и т.п. не нужно.

S>>В любом случае каждая новая фича требует изменения кодогенератора.
WH>В любом случае каждая новая фича требует изменения шаблонов.
Согласен. Т.е. шаблоны не хуже.

S>>Про скорость — возможно, если в смысле компиляции. Но это не первоочередной фактор.
WH>Лично мне очень не нравится когда проект компилируется часами.
Выше я уже высказался по этому поводу.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

E>>>Не, ну это уже как напишите

S>>Согласен. Тут уже вопрос сколько на это сил уйдет.
E>Не, ну если вам простой код писать сложнее, чем метопрограммировать, то я преклоняюсь конечно, но не разделяю

Я хочу еще раз подчеркнуть, что я не имею ничего против кодогенераторов. Просто я считаю что путь с mpl тоже имеет право на существование.

E>Соответсвенно автор метапргораммы (видимо пользователь вашей библиотеки) пишет её, компилит, пока не скомпилит в С++ (уже на этом этапе можно отловить много логических ошибок), потом компилит до исполняемого кода и отлаживает. При этом пока он отлаживает свои ошибки он получает сообщения о них в терминах своей метапрограммы и думает сам. А как только добирается до ваших получает в терминах "внутренняя ошибка" и обращается к вам...

E>А у вас как всё происходит?

Все просто. Если программист набирает класс из уже существующих кубиков, то он может получить ошибки вроде: у этого класса должна быть такая функция или этот класс не может быть вместе с этим. Если он пишет некоторые кубики сам, то ему приходится так же отловить ошибки вроде невозможно сконвертить std::string к char const * и т.п. Я согласен, что все это не идеально. Но тем не менее работает.
Скорей всего дело упрощается тем, что у нас все разработчики — программисты
(нет экспертов, которые непосредственно пишут код (в этом проекте конкретно)).

E>>>А если что-то сразу не складывается, то что происходит?...

S>>Сообщение об ошибке. Это же, в конце концов, код.
E>Очень хорошо. Вот я пользователь. Вот у меня не скопилировалось и я получил какой-то бесконечный отчёт о шаблонных подстановках где что-то с чем-то не склеелось.
E>Заметь, что писал я при этом какие-то макросы, про которые даже не знал это макросы...
E>Как мне хотя бы понять. Это у меня ошибка или у вас?
Если static assert — значет ваша. Если нет — значит наша. По крайней мере, в идеале

.

S>>А если кодогенератор сгенерит что-то, что не компилируется. Что происходит?
E>А если кодогенератор генерит то, что не компилируется, то авторы кодогенератора ищут у себя ошибку

Анологично

А>>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
E>Почему так скромно? От чего не на XXX::BTree?

МОжно нескрномный вопрос? Вы в проектах>10 человек и длительнотью >1 Года принимали участие? Буквально сегодня перелопатил в целях оптимизации std::vector на std::set в одном месте.

sux>з.ы. а еще круто бы сделать подпись внизу ваши постов о величестве спирита, дабы поломники стекались со вего мира поклониться "великому и ужасному"!

К доктору не пробовали обращатся?

C>Опровергать не буду ... но ... есть некоторые замечания -

C>эффективность — почему в примере он использует для проверки последнего элемента функцию end()
Эта функция — inline. И во многих реализациях STL представляет собой указатель за элемент после последнего. И проход по вектору итераторами равносилен написанию след Сшного кода по скорости:

int arr[256];
for(int *p=&arr[0];p!=&arr[255];p++)
{
*p = 10;
}

А с индексами вы делаете так:
for(int i=0;i<255;i++)
{
p[i] = 10;
}

C>почему бы не объявить vector<blblabla>::interator end = vec.end();
Потому что vec.end() и так развернется к обращению к одному элементу структуры.

carpenter wrote:
>
>
> 1.Неужели в реальном программинге так часто используються шаблоны?
Да, часто жуть как удобно.

>
> 2.Кросплатформенность – опять тотже вопрос – неужели так много народу
> пишет на С++ кросплатформенные приложения , которые еще вдобавок должны
> компилиться любыми компиляторами под любые операционки и под любые
> архитектуры процессоров?
По опыту, если приложение писалось кроссплатформенно, то работает оно
обычно с сильно меньшим количеством багов.
> Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
И пишут. Зависит от задачи.

>
> 3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу
> алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция
> подсчета битов — она же подсчитывает (что еще надо?) ...
А вот это нужно уже сильно реже.

>
> 4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
> чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30
> строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под
> отладчиком дошлифовываю.
Это нормально.

>
> Из реального — мне очень понравился такой метод тестирования —
> дали проект , компилер и мсдн и попросили убрать при компиляции все ошибки и
> варнинги и сказать свое мнение по части пары классов ( после
> тестирования меня брали но на предыдущей работе перебили цену).
Метод идеален, если человека берут именно на саппорт. Но многие ли здесь
хотят саппортом заниматься?

>
> Из последнего собеседования — думаю большинство знает как выяснить —
> являеться ли переменная степенью двойки (имееться в виду быстрый алгоритм
> if(i & (i-1)) но если нет — реально ли до этого дотумкать в течении пары
> минут ?
Ну а это очередной бессмысленный вопрос. Можно еще открыть
"Занимательные задачи" того же Перельмана и соискателей этим доставать.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Smal, Вы писали:

S>Я хочу еще раз подчеркнуть, что я не имею ничего против кодогенераторов. Просто я считаю что путь с mpl тоже имеет право на существование.

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

Здравствуйте, Аноним, Вы писали:

А>МОжно нескрномный вопрос? Вы в проектах>10 человек и длительнотью >1 Года принимали участие? Буквально сегодня перелопатил в целях оптимизации std::vector на std::set в одном месте.
Можно нескромный ответ?
Мы в таких серьёзных проектах STL не используем, зато используем процесс проектирования программ...

А>>МОжно нескрномный вопрос? Вы в проектах>10 человек и длительнотью >1 Года принимали участие? Буквально сегодня перелопатил в целях оптимизации std::vector на std::set в одном месте.
E>Можно нескромный ответ?
E>Мы в таких серьёзных проектах STL не используем, зато используем процесс проектирования программ...

Завидую что вы не пишете проект в условиях когда штат дизайнеров в 10 часовых поясах от вас параллельно занимается разработкой UI для программы а через месяц — бета

Я наверно понимаю в чем дело. Вы ишете конкретные программы под конкретные ТЗ, когда написал, получил бабло — и забыл. Мы же пишем, развиваем и поддерживаеем коробочные продукты.

Здравствуйте, Аноним, Вы писали:

А>Я наверно понимаю в чем дело. Вы ишете конкретные программы под конкретные ТЗ, когда написал, получил бабло — и забыл. Мы же пишем, развиваем и поддерживаеем коробочные продукты.

Вот именно коробочные продукты мы и пишем. Недавно вышла 12 версия одного из них, например.
А прямо сейчас выходит 9-я другого...

Здравствуйте, Аноним, Вы писали:

А>Я наверно понимаю в чем дело. Вы ишете конкретные программы под конкретные ТЗ, когда написал, получил бабло — и забыл. Мы же пишем, развиваем и поддерживаеем коробочные продукты.
Да, забыл добавить, разработка при этом ведётся по всему земному шару. Правда большая её частьсосредоточена всё-таки в Москве.

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

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

Здравствуйте, michus, Вы писали:

M>Здравствуйте, Erop, Вы писали:

E>>Вот именно коробочные продукты мы и пишем. Недавно вышла 12 версия одного из них, например.
E>>А прямо сейчас выходит 9-я другого...

M>Ну прямо ABBYY какой-то.

Действительно, похоже на то.
Так вот она мифическая контора Erop-а...
И что, в этих продуктах никогда не приходилось менять vector на set?
Вот это архитекторы!

A>возможно — Моно же есть. правда не все технологии связанные с .NET могут быть портированы, но не по техническим,
A>а по патентным ограничениям

мм.. скорее нет, чем есть. он слишком сильно отстает от "большого брата", чтоб его можно было в серьез рассматривать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Аноним, Вы писали:

C>>почему бы не объявить vector<blblabla>::interator end = vec.end();
А>Потому что vec.end() и так развернется к обращению к одному элементу структуры.

Он-то развернется. Но представь себе такой код:

for(C::const_iterator i = c.begin() /* return this->_M_first; */; i != c.end() /* return this->_M_last; */; ++i)
{
    ++*i;
}

Может ли компилятор понять, что ++*i не изменяет _M_last? В отсутствие правил strict aliasing — не может. Поэтому он должен вызывать end() каждый раз. И inlining здесь ни при чем. Если вынести вызов end() из условия цикла, это может дать чуточку прироста скорости.

Здравствуйте, Smal, Вы писали:

S>И что, в этих продуктах никогда не приходилось менять vector на set?
S>Вот это архитекторы!

1) Наща контора не мифическая

2) Не знаю кто там какие архитекторы, но я не припоминаю случая, чтобы пришлось менять аналог vector'а на аналог set'а

Я жк говорю, что STL провоцирует экономию на проектировании

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

S>>И что, в этих продуктах никогда не приходилось менять vector на set?
S>>Вот это архитекторы!

E>1) Наща контора не мифическая

Вы сами ее такой сделали

E>2) Не знаю кто там какие архитекторы, но я не припоминаю случая, чтобы пришлось менять аналог vector'а на аналог set'а

Я жк говорю, что STL провоцирует экономию на проектировании

Странно. Простой пример. Пусть у меня был класс для графа. В него можно было добавлять ребра и получать на них идентификаторы — size_t,
дабы после обращаться. Соответственно, ребра я похранил в векторе.
Дальше при развитии проекта мне пришлось некоторые ребра удалять.
При этом я не хотел, что бы от этого страдали клиенты этого класса, т.е. идентификаторы при этом не должны меняться.
Соответственно, std::vector<C> я заменил на std::map<size_t,C>.

RO>Может ли компилятор понять, что ++*i не изменяет _M_last? В отсутствие правил strict aliasing — не может. Поэтому он должен вызывать end() каждый раз. И inlining здесь ни при чем. Если вынести вызов end() из условия цикла, это может дать чуточку прироста скорости.
Вызов end() это лишь обращение к одному полю структцры c. Самого вызова (call) в асм коде вообще не будет соответственно и экономии никакой не будет при копировании той переменной из структуры на стек.

Здравствуйте, Smal, Вы писали:

S>Соответственно, std::vector<C> я заменил на std::map<size_t,C>.
Я бы рёбра графа сразу указателем идентифицировал... Просто на отдельном аллокаторе бы рожал, да и всё, если с аллокацией болшого числа мелочи есть какие-то проблемы.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Smal, Вы писали:

E>Я бы рёбра графа сразу указателем идентифицировал... Просто на отдельном аллокаторе бы рожал, да и всё, если с аллокацией болшого числа мелочи есть какие-то проблемы.

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

Здравствуйте, Аноним, Вы писали:

RO>>Может ли компилятор понять, что ++*i не изменяет _M_last? В отсутствие правил strict aliasing — не может. Поэтому он должен вызывать end() каждый раз. И inlining здесь ни при чем. Если вынести вызов end() из условия цикла, это может дать чуточку прироста скорости.
А>Вызов end() это лишь обращение к одному полю структцры c. Самого вызова (call) в асм коде вообще не будет соответственно и экономии никакой не будет при копировании той переменной из структуры на стек.

15: std::vector<int>::iterator i;
16: for(i=vec.begin();i!=vec.end();i++);
0040D509 lea ecx,[ebp-1Ch]
0040D50C call @ILT+40(std::vector<int,std::allocator<int> >::begin) (0040102d)
0040D511 mov dword ptr [ebp-20h],eax
0040D514 jmp main+8Fh (0040d51f)
0040D516 mov ecx,dword ptr [ebp-20h]
0040D519 add ecx,4
0040D51C mov dword ptr [ebp-20h],ecx
0040D51F lea ecx,[ebp-1Ch]
0040D522 call @ILT+20(std::vector<int,std::allocator<int> >::end) (00401019)
0040D527 cmp dword ptr [ebp-20h],eax
0040D52A je main+9Eh (0040d52e)
0040D52C jmp main+86h (0040d516)

Здравствуйте, Кодт, Вы писали:

К>Дукха — в переводе с санскрита и пали — страдание.

...В философском буддизме (лакшана-вада) страдание признается имманентным бытию и определяется как аффективность, возбуждение, волнение элементов бытия (дхарма), должное состояние которых — покой. Буддийская практика направлена на полное их успокоение (ануттара-ниродха) и переход сознания в состояние нирваны, сверхбытия, абсолюта.

А вообще-то респект, ты все незнакомые слова из форумов в словаре смотришь?

Все что вы привели выше — это код неоптимизированной дебажнок конфигурации.В релизе компилятор даже не реализовал цикл тк он ничего не делает. См:

62:       std::vector<int> vec;
004010E0   mov         al,byte ptr [ebp-0Dh]
004010E3   mov         byte ptr [vec],al
004010E6   xor         eax,eax
004010E8   mov         dword ptr [ebp-20h],eax
004010EB   mov         dword ptr [ebp-1Ch],eax
004010EE   mov         dword ptr [ebp-18h],eax
004010F1   mov         dword ptr [ebp-4],eax
63:       vec.push_back(1);
004010F4   lea         eax,[ebp-14h]
004010F7   push        eax
004010F8   lea         ecx,[vec]
004010FB   mov         dword ptr [ebp-14h],1
00401102   call        std::vector<int,std::allocator<int> >::push_back (00401155)
64:       vec.push_back(2);
00401107   lea         eax,[ebp-14h]
0040110A   lea         ecx,[vec]
0040110D   push        eax
0040110E   mov         dword ptr [ebp-14h],2
00401115   call        std::vector<int,std::allocator<int> >::push_back (00401155)
65:       std::vector<int>::iterator i;
66:       for(i=vec.begin();i!=vec.end();i++);
67:       return -1;

PS VC6

Здравствуйте, AndrewJD, Вы писали:

AJD>В случае копирования это значение может хранится в регистре, а не считываться из памяти.
Если всё так хорошо, то скорее всего компилятор имеет шансы просечь, что тело цикла не переаллокирует буфер вектора...

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

65:       std::vector<int>::iterator i;
66:       for(i=vec.begin();i!=vec.end();i++);
67:       return -1;
0040111A   or          dword ptr [ebp-4],0FFFFFFFFh
0040111E   lea         ecx,[vec]
00401121   call        std::vector<int,std::allocator<int> >::~vector<int,std::allocator<int> > (00401135)

А вот что получается если написать GetTickCount() в теле цикла чтоб оптимизатор его не выкинул:

64:       vec.push_back(2);
00401108   lea         eax,[ebp-14h]
0040110B   lea         ecx,[vec]
0040110E   push        eax
0040110F   mov         dword ptr [ebp-14h],2
00401116   call        std::vector<int,std::allocator<int> >::push_back (0040116f)
65:       std::vector<int>::iterator i;
66:       for(i=vec.begin();i!=vec.end();i++)GetTickCount();
0040111B   mov         eax,dword ptr [ebp-20h]
0040111E   cmp         eax,dword ptr [ebp-1Ch]
00401121   mov         esi,eax
00401123   je          main+60h (00401133)
00401125   call        dword ptr [__imp__GetTickCount@0 (0040202c)]
0040112B   add         esi,4
0040112E   cmp         esi,dword ptr [ebp-1Ch]
00401131   jne         main+52h (00401125)
67:       return -1;
00401133   or          dword ptr [ebp-4],0FFFFFFFFh
00401137   lea         ecx,[vec]
0040113A   call        std::vector<int,std::allocator<int> >::~vector<int,std::allocator<int> > (0040114f)
68:

И где тут вызов end() кторого вы так боялись?

Здравствуйте, carpenter, Вы писали:

короче — эта же фигня обсуждалась у того же майерса в решениях сложных задач
только она касалась вызова vector::size() в цикле for

Здравствуйте, Erop, Вы писали:

E>А вообще-то респект, ты все незнакомые слова из форумов в словаре смотришь?

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Аноним, Вы писали:

C>>У меня шестерка тупо развернула цикл ( благо небольшой ) но тут как говориться —
C>>На компилятор надейся , а сам не плошай

C>>Ибо оптимизация негарантирована ...
А>А может просто выключена?

Если она включена — то каким пунктом стандарта гарантировано что вместо вызова функции end() будет обращение к участку памяти ???

А>Про существование в меню таких пунктов "Build -> Set Active Configururation -> *** — Win32 Release" в курсе?

Я Ф ШОКЕ ... вы открыли для меня вселенную

А>>А может просто выключена?
C>Если она включена — то каким пунктом стандарта гарантировано что вместо вызова функции end() будет обращение к участку памяти ???

А>>Про существование в меню таких пунктов "Build -> Set Active Configururation -> *** — Win32 Release" в курсе?

C>Я Ф ШОКЕ ... вы открыли для меня вселенную

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

Здравствуйте, Аноним, Вы писали:

C>>>эффективность — почему в примере он использует для проверки последнего элемента функцию end()
C>>>почему бы не объявить vector<blblabla>::interator end = vec.end();
C>>>или же как я — int size = vec.size();
C>>> for(int i =0;i<size;i++) // здесь конечно должен быть преaиксный инкремент но поскольку это простой тип я не иду на уступки красивости

C>>>чем этот вариант менее эффективен вызову предиктата , учитывая накладные расходы на вызов лишней функции ?
C>>>Я не оспариваю что для контейнеров не имеющих произвольного доступа вариант с алгоритмами имеет смысл , но писать везде
C>>>по обезьяньи не понимая зачем , а только потому что так надо ...
А>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...

А вы мне ответили или предыдущему человеку?

C>>>На компилятор надейся , а сам не плошай

C>>>Ибо оптимизация негарантирована ...
А>>А может просто выключена?

C>Если она включена — то каким пунктом стандарта гарантировано что вместо вызова функции end() будет обращение к участку памяти ???
ок, а где гарантировано что нет? Где гарантировано то что обращение по индексу не станет обращением через 30 полей изза перегруженности оператора []? Скажу вам по секрету что некоторые СТЛ можно настроить так что каждое обращение по индексу к массиву будет проверять соответствие размеру массива и кидать экцепшн прямо из оператора []. Так что просто поверьте что все с итераторами ок в плане скорости

Здравствуйте, Аноним, Вы писали:

Лано это уже пошел какойто словесный ананизм (он же флейм)

И вообще — проведение врмени на форуме — достаточно безполезное и
жестокое занятие ( как китайская печатная машинка )

Засим выражаю всем свое уважение (даже анонимам

)
и удаляюсь на фик в ОТПУСК

C>>>>На компилятор надейся , а сам не плошай

C>>>>Ибо оптимизация негарантирована ...
А>>>А может просто выключена?

C>>Если она включена — то каким пунктом стандарта гарантировано что вместо вызова функции end() будет обращение к участку памяти ???
А>ок, а где гарантировано что нет? Где гарантировано то что обращение по индексу не станет обращением через 30 полей изза перегруженности оператора []? Скажу вам по секрету что некоторые СТЛ можно настроить так что каждое обращение по индексу к массиву будет проверять соответствие размеру массива и кидать экцепшн прямо из оператора []. Так что просто поверьте что все с итераторами ок в плане скорости

Здравствуйте, Smal, Вы писали:

S>Отдельный проект => дополнительный геморрой. ИМХО.

Под столом.
Простенький проектик на 10К-20К кода геморой, а куча мутных шаблонов нет?

S>А что тогда он должен делать? mpl умеет жонглировать шаблонами классов.
S>А что тогда должен делать генератор? Просто генерировать код? А зависимости, статические проверки и т.п.?
Проверил вход и все.
Остальное проверит комилятор и тесты.

S>Ну, в действительности у страха глаза велики. Не так уж и долго. В проекте ~50 объектов.
S>Компилится он минут 5. Не так уж и страшно. К тому же мы планируем его разделить => ускорим билд.
Не сильно поможет.

S>Ты правильно сказал, генератор должен генерить код.
Не надо охреневать.
Кодогенератор должен простое декларотивное описание превращать в сложный и/или объемный код.
При этом могут быть весьма сложные преобразования.
Поиск кратчайших путей в графе, построение и оптимизация ДКА...
Это все дефакто на шаблонах не сделать.
Да даже банальная сортировка уже на гране возможного.

S>Максимум, что мне нужно — операции над последовательностями.
Аппетит приходит во время еды.
Когда понимаешь что можешь использовать полноценный язык для создания кодогенератора начинаешь иногда приходить к решениям которые раньше обходил стороной как не реализуемые.

S>Согласен. Т.е. шаблоны не хуже.
Нет. Они создают как минимум не меньше гемороя.
А на практике сильно больше.
Да и сделать с их помощью многое нельзя.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, carpenter, Вы писали:

C>3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция подсчета
C>битов — она же подсчитывает (что еще надо?) ...
C>И тут все полезли меряться пи...ками , типа можно так , а можно и так
C>, а типа если под такой проц так загнуть а под другой этак ( я думаю и теорию графов тут можно как нибудь прикрутить

	От:	carpenter
	Дата:	29.08.07 11:42
	Оценка:	+1 -8

	От:	Аноним
	Дата:	30.08.07 08:58
	Оценка:	4 (2) +1 -1

	От:	sux
	Дата:	30.08.07 08:02
	Оценка:	1 (1) -2

	От:	carpenter
	Дата:	29.08.07 14:06
	Оценка:	-3

	От:	Erop
	Дата:	30.08.07 11:42
	Оценка:	1 (1)

	От:	Uzumaki Naruto
	Дата:	29.08.07 14:46
	Оценка:	1 (1) -1

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	29.08.07 13:44
Оценка:	-1

От:	lxa	http://aliakseis.livejournal.com
Дата:	02.09.07 08:31
Оценка:	-1

От:	R.O. Prokopiev	http://127.0.0.1/
Дата:	30.08.07 11:02
Оценка:

	От:	Alexander Pazdnikov
	Дата:	30.08.07 12:09
	Оценка:

	От:	Кодт
	Дата:	31.08.07 11:13
	Оценка:

	От:	AndrewJD
	Дата:	31.08.07 09:44
	Оценка:	+1