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

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

В качестве лирического отступления.
При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

Я уже представляю себе этот нереальный пипец в коде.

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

CC>>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.
DC>Да ты што!! Нам решарпер любую архитектуру исправит. Это ведь такая продвинутая штука!
На пришедшем от американских индусов C# проекте решарпер сжирал всю доступную память и вижуалка дохла в корчах.
Снёс нахрен и поставил ассист.

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

I>Вот есть задача или изменение имеющейся архитектуры под новые требования.

I>Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.

I>Или такая задача — упрощения имеющегося кода.

И для этого мы, видимо, выделяем метод аж в целый класс .

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



I>Но гораздо проще, быстре и надежнее будет сделать рефакторинг.

I>Практически везде нужно

I>1. выделение базового класса/интерфейса
I>2. перемещение методов по иерархии
I>3. использование базового класса

Ну да, у нас же нет свободных функций, нам везде классы лепить надо.

I>еще очень сильно не хватает "преобразование метода в класс"
I>и вообще очень много чего не хватает

I>при этом Решарпер предоставляет много средств которые не показыны в меню что я привел, например создание наследника, генерацию конструкторов и многое другое

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

I>заметь — выделение метода я упомянул только здесь.

CC>>Ты не меряй то, что надо для шарпа на плюсы.

I>Рефакторинг нужен независимо от языка.

I>В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер потому ты их там и не видишь.
Самое мощьное средство рефакторинга программист и если ему для написания кода нужна графическая штамповалка boilerplate кода, то либо что=то не так с языком, либо программист что-то не так делает.

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

I>>Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.
I>>Или такая задача — упрощения имеющегося кода.

DC>И для этого мы, видимо, выделяем метод аж в целый класс .

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

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

DC>

I>>Но гораздо проще, быстре и надежнее будет сделать рефакторинг.

I>>Практически везде нужно

I>>1. выделение базового класса/интерфейса
I>>2. перемещение методов по иерархии
I>>3. использование базового класса

DC> Ну да, у нас же нет свободных функций, нам везде классы лепить надо.

свободные функции это каменный век.

DC>Я вообще придерживаюсь мнения, что biolerplate код должен убираться, а не плодиться с использованием мегакрутого решарпера.

он и убирается. при чем оставшийся код приводится к легко понятной форме

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

функции это круто. а как на счет подсистем над которыми работали десятки девелоперов в течении многих лет ?

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

I>>В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер потому ты их там и не видишь.
DC>Самое мощьное средство рефакторинга программист и если ему для написания кода нужна графическая штамповалка boilerplate кода, то либо что=то не так с языком, либо программист что-то не так делает.

Хорошему программисту лишний инструмент не помеха.

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

I>>но по любому высокоуровневые оптимзации решают на порядки больше нежели числодробилки.
CC>Это какое отношение имеет к обсуждению фич средств рефакторинга для С++?

Непосредственное.

I>>Хочешь выделить небольшую фичу в отдельную подсистему — добро пожаловать в ад на с++.
CC>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.

"написание биндингов"

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

CC>Здравствуйте, Aleх, Вы писали:

A>>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.
A>>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
CC>По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
CC>Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
CC>И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.
CC>проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?

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

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

I>>>Windows Presentation Framework
V>>Ничего про нее не знаю.
I>Загляни в какой толковый туториал по MVVM.
Я тока поправлю. Все-таки не Framework, а Foundation. Windows Presentation Foundation

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

I>>>>Windows Presentation Framework
V>>>Ничего про нее не знаю.
I>>Загляни в какой толковый туториал по MVVM.
MK>Я тока поправлю. Все-таки не Framework, а Foundation. Windows Presentation Foundation

Да, я поторопился.

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

CC>Здравствуйте, Aleх, Вы писали:

A>>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.
A>>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
CC>По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
CC>Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
CC>И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.
CC>проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?
Теоретически, среда разработки может подсказывать, что там происходит на самом деле. А вообще, в С++ много конструкций с неочевидной семантикой (использование перегруженных операторов). Многие поклонники Си говрят, что они по этой причине не переходят на С++. Если же грамотно использовать все эти фитчи, предоставляющие альтернативную семантику для привычных конструкций, проблемы не будет. Проблема в программистах недостаточно знающий язык или недостаточно хорошо умеющий проектировать интерфейсы классов.

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

CC>Здравствуйте, Aleх, Вы писали:

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

CC>В качестве лирического отступления.
CC>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.
Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет. Тогда причем здесь это, я же описал совершенно другой случай.

A>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

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

A>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме. Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
В нормально спроектированной графической системе это будет выглядеть так:

button1.x = 30;
frame.redraw();

Автоматическая перерисовка — зло.

I>Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?
Ты приводишь примеры какой-то незнакомой мне среды. Ты можешь показать УНИВЕРСАЛЬНЫЙ пример?
А ведь я тоже могу покахать тебе кусок на Мотиве и спросить, куда здесь засунуть проперти и зачем.

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

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

CC>>В качестве лирического отступления.
CC>>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.
Настраиваемый через шаблонный параметр размер буфера это цирк.
А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>Тогда причем здесь это, я же описал совершенно другой случай.
Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.

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

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

MK>Так чего тогда плюсовал слившему товарищу?
Ты о чём конкретно?

MK> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.
Если ты ничего не понял то лучше бы спросил.

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

Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.

MK>Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
Мьсе потрудится привести пруфлинк?

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

I>>Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?
V>Ты приводишь примеры какой-то незнакомой мне среды. Ты можешь показать УНИВЕРСАЛЬНЫЙ пример?

Я привожу примеры из того, с чем работаю.
Из того, с чем не работаю, примеры не привожу.

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

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

MK>>Так чего тогда плюсовал слившему товарищу?
CC>Ты о чём конкретно?
О плюсе к этому посту

Автор: Vamp
Дата: 03.02.10

.

MK>> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.
CC>Если ты ничего не понял то лучше бы спросил.
Да вроде понятно.

CC>Уродство: это переться со своим уставом (методиками программирования на одном языке) в чужой монастырь (пытаться в тех же методиках писать на другом языке). И потом орать что это дескать не сам дурак, а язык плохой.
CC>Ей богу, шо дети.

CC>Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
CC>На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.
Вот не надо. В твоем же примере убогости свойств, разговор идет про C#.

MK>>Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
CC>Мьсе потрудится привести пруфлинк?
Нет, лопатить кучу страниц КСВ мне в лом. Но ты же не будешь отнекиваться, что всегда выступаешь на стороне С++.

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

I>Из того, с чем не работаю, примеры не привожу.
А с С++ ты работаешь?

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

I>>Из того, с чем не работаю, примеры не привожу.
CC>А с С++ ты работаешь?

Приходится посматривать туда.

Здравствуйте, dr.Chaos, Вы писали:
DC>графическая штамповалка boilerplate
Это все оттого, я считаю, что в C# мало средств метапрограммирования. Без макросов типичную конструкцию (свойство, например) разработчик языка не выпустит в виде библиотеки — надо в язык включать. А разработчик приложений не сможет генерацию и поддержку boilerplate поручить макросу — ему нужны будут тулзы.

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

MK>>>Так чего тогда плюсовал слившему товарищу?
CC>>Ты о чём конкретно?
MK>О плюсе к этому посту

Автор: Vamp
Дата: 03.02.10

.

I>>>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>>>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>>>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.
I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

Согласен с оратором, что оппоненту следует разъяснить, зачем проперти все таки так нужен в С++.

MK>>> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.
CC>>Если ты ничего не понял то лучше бы спросил.
MK>Да вроде понятно.
Что то в глаза не бросается

CC>>Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
CC>>На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.
MK>Вот не надо. В твоем же примере убогости свойств, разговор идет про C#.
Мсье не потрудился прочитать внимательно ветку сообщений?
См. выше процитированный кусок. Там чётко видно, что речь идёт о пропертях касательно С++.

MK>>>Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
CC>>Мьсе потрудится привести пруфлинк?
MK>Нет, лопатить кучу страниц КСВ мне в лом. Но ты же не будешь отнекиваться, что всегда выступаешь на стороне С++.
Т.е. мьсе трепло?