Здравствуйте, Ikemefula, Вы писали:
I>>>Из того, с чем не работаю, примеры не привожу. CC>>А с С++ ты работаешь?
I>Приходится посматривать туда.
А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Aleх, Вы писали:
A>>>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.
CC>>>В качестве лирического отступления. CC>>>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string. CC>>>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.
A>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет. CC>Настраиваемый через шаблонный параметр размер буфера это цирк. CC>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?
Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше. A>>Тогда причем здесь это, я же описал совершенно другой случай. CC>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу. CC>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.
Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.
A>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.
CC>>>Я уже представляю себе этот нереальный пипец в коде. A>>В чем заключается этот пипец? CC>В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений.
Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.
Здравствуйте, Aleх, Вы писали:
A>>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет. CC>>Настраиваемый через шаблонный параметр размер буфера это цирк. CC>>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?
A>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов. A>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
А не проще ли будет ускорить реально тормозящее место во всех реализациях строки — прикрутить к строке быстрый кастомный аллокатор?
Считай это подсказкой направления.
A>>>Тогда причем здесь это, я же описал совершенно другой случай. CC>>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу. CC>>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.
A>Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.
Hint: дело не в командах проца а в работе кэша.
CC>>>>Я уже представляю себе этот нереальный пипец в коде. A>>>В чем заключается этот пипец? CC>>В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений. A>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.
Для людей, пишущих в стиле Александреску, на одном из моих предыдущих мест работы появился термин "укушенный Александреску".
Ибо человек, постигший Александреску-дзэн поначалу начинает писать на шаблонах всё. В прямом смысле, вообще всё.
А потом приходит пушистый северный зверёк в виде черепашьей скорости компиляции и (да, бывает и такое!) compiler limits.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Aleх, Вы писали:
A>>>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет. CC>>>Настраиваемый через шаблонный параметр размер буфера это цирк. CC>>>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?
A>>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов. A>>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
CC>А не проще ли будет ускорить реально тормозящее место во всех реализациях строки — прикрутить к строке быстрый кастомный аллокатор?
Можно и так, если это позволит достичь желаемых результатов. Но все равно подход останется тем же — аллокатор будет передаваться в качестве параметра шаблона. CC>Считай это подсказкой направления.
A>>>>Тогда причем здесь это, я же описал совершенно другой случай. CC>>>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу. CC>>>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.
A>>Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист. CC>Hint: дело не в командах проца а в работе кэша.
И что? кеш это часть процессора. и про команды я ничего не писал.
A>>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход. CC>Для людей, пишущих в стиле Александреску, на одном из моих предыдущих мест работы появился термин "укушенный Александреску". CC>Ибо человек, постигший Александреску-дзэн поначалу начинает писать на шаблонах всё. В прямом смысле, вообще всё. CC>А потом приходит пушистый северный зверёк в виде черепашьей скорости компиляции и (да, бывает и такое!) compiler limits.
Конечно, нужно знать меру, но вообще избегать шаблонов и особенно считать, что они не нужны совсем (как считают, например, оберонщики ) тоже не стоит.
Здравствуйте, Mr.Cat, Вы писали:
MC>Это все оттого, я считаю, что в C# мало средств метапрограммирования. Без макросов типичную конструкцию (свойство, например) разработчик языка не выпустит в виде библиотеки — надо в язык включать. А разработчик приложений не сможет генерацию и поддержку boilerplate поручить макросу — ему нужны будут тулзы.
Нет, это из-за распространённости языка . На C# тоже можно писать лаконично, красиво и понятно, только миллионам леммингов надо быстро напедалить, вот и есть хорошие штамповалки, там где они нужны и востребованы. На С++ тоже востребованы, но сложны в изготовлении. Макросы безусловно вещь мощная, но их никто не даст использовать кому попало .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, CreatorCray, Вы писали:
CC> Согласен с оратором, что оппоненту следует разъяснить, зачем проперти все таки так нужен в С++.
Ну, вообще, свойства это один из способов улучшения инкапсуляции, безотносительно языка. Просто еще один способ отделить интерфейс от реализации. Можно-ли обойтись без них? Разумеется. Вопрос удобства.
Здравствуйте, MxKazan, Вы писали:
CC>>Т.е. мьсе трепло? MK>В таком тоне я общаться не собираюсь.
Аналогично. Потому и прошу подтверждать ссылками.
MK>P.S. Пример
Я право не вижу там ничего подобного "вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного"
Единственная фраза, содержащая слово "указатель" вот:
Блин, такое ощущение что программирование на С++ ассоциируется с суровой рукопашной с указателями, копипастом кода и т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Aleх, Вы писали:
A>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов. A>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше. A>>>Тогда причем здесь это, я же описал совершенно другой случай.
Ничем он особо не лучше: от параметров шаблонов пухнет страшно код, да и засунуть 2 такие строки в один массив целая проблема. Т.е. Здесть возможно даже аллокатор стоит делать не параметром шаблона, а параметром конструктора.
A>>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.
A>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.
Скажем по другому: чем это лучше 5ти классов map, map_double_hashing и т.д. с одним интерфейсом? Допустим параметразовать можно было бы хеш функцией, но все эти 5 реализаций карты очень различаются и найти что-то общее в рамках одной реализации тут ИМХО будет сложнее, да и смысл?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
B>>>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать? ___>>Ехать. Но с комфортом. B>Приведите пример задачи, которую нельзя "некриво" реализовать на С++ и я удивлю вас контрпримером
Да этими примерами забит весь КСВ. Оскомину уже набило.
Здравствуйте, CreatorCray, Вы писали:
I>>>>Из того, с чем не работаю, примеры не привожу. CC>>>А с С++ ты работаешь?
I>>Приходится посматривать туда. CC>А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.
Сколько месяцев этому проекту ?
сколько релизов было ?
Сколько тестеров, колько девелоперов ?
Сколько кастомизаций/варантов деплоймента ?
Сколько раз кастомер менял требования ?
Сколько есть конкурентов у продукта ?
Здравствуйте, Ikemefula, Вы писали:
I>>>Приходится посматривать туда. CC>>А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.
I>Сколько месяцев этому проекту ? I>сколько релизов было ? I>Сколько тестеров, колько девелоперов ? I>Сколько кастомизаций/варантов деплоймента ? I>Сколько раз кастомер менял требования ? I>Сколько есть конкурентов у продукта ?
Может тебе еще и номера счетов и пароли к SVN написать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
I>>Сколько месяцев этому проекту ? I>>сколько релизов было ? I>>Сколько тестеров, колько девелоперов ? I>>Сколько кастомизаций/варантов деплоймента ? I>>Сколько раз кастомер менял требования ? I>>Сколько есть конкурентов у продукта ?
CC>Может тебе еще и номера счетов и пароли к SVN написать?
в главах 6-9 неактуальны для с++ воообще, а не только вашей песочницы
хочу услышать внятный ответ, как наприер:
программируя на с++ у программиста открываются мощные внутренние интеллектуальные способности и это даёт такой эффкт, что все инструменты рефакторнга являются не более чем тормозом.
Пока что все что сказал ты и dr.Chaos сводится к абурду следующего вида —
дай дураку перфоратор/шуроповерт, он всю стену враз опаскудит, посему для настоящих мастеров перфоратор/шуроповерт не нужен в прынцыпе.
I>в главах 6-9 неактуальны для с++ воообще, а не только вашей песочницы
Ты б хоть ссылку давал не на содержание а на сам текст
Неужто ты хочешь сказать что в
I>хочу услышать внятный ответ
Только после того, как ответишь что из этого умеет решарпер:
Replace Constructors with Creation Methods[/*]
Move Creation Knowledge to Factory[/*]
Encapsulate Classes with Factory[/*]
Introduce Polymorphic Creation with Factory Method[/*]
Encapsulate Composite with Builder[/*]
Inline Singleton[/*]
ComposeMethod[/*]
Replace Conditional Logic with Strategy[/*]
Move Embellishment to Decorator[/*]
Replace State-Altering Conditionals with State[/*]
Replace Implicit Tree with Composite[/*]
Replace Conditional Dispatcher with Command[/*]
Form Template Method[/*]
ExtractComposite[/*]
Replace One/Many Distinctions with Composite[/*]
Replace Hard-Coded Notifications with Observer[/*]
Unify Interfaces withAdapter[/*]
Extract Adapter[/*]
Replace Implicit Language with Interpreter [/*]
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
I>>хочу услышать внятный ответ CC>Только после того, как ответишь что из этого умеет решарпер:
Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
Но раз уж ты таки считаешь, что нобходимость рефакторинга в с++ зависит от решарпера,
в готовом виде он конечно все это он не умеет, кроме
но все до единого эти рефакторнги делаются из более простых, например выделение подкласса, интерфейса, движение метода, преобразование конструктора в фабричный метод и тд.
Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
Т.е. да или нет, без виляний в твоем духе.
Здравствуйте, Ikemefula, Вы писали:
I>>>хочу услышать внятный ответ CC>>Только после того, как ответишь что из этого умеет решарпер:
I>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
Зависят. Ты тут речь завёл с того, что С++ дескать такое говно что под него нет тулов для рефакторинга.
I>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере
На что тебе был приведён тул — ассист.
Ты начал ныть что мол, он слишком мало умеет.
На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.
I>в готовом виде он конечно все это он не умеет
Тогда какое отношение эта книга имеет к разговору о тулах для рефакторинга?
I>но все до единого эти рефакторнги делаются из более простых, например выделение подкласса, интерфейса, движение метода, преобразование конструктора в фабричный метод и тд.
Простые рефакторинги для методик разработки, принятых и используемых в С++ в ассисте есть.
I>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.
I>Т.е. да или нет, без виляний в твоем духе.
Прекращай нести чушь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, abdul.zycor, Вы писали: AZ> ... В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.
Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.
) тоже не стоит.
. На C# тоже можно писать лаконично, красиво и понятно, только миллионам леммингов надо быстро напедалить, вот и есть хорошие штамповалки, там где они нужны и востребованы. На С++ тоже востребованы, но сложны в изготовлении. Макросы безусловно вещь мощная, но их никто не даст использовать кому попало 
