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

E>>>Чего? Как оно нужный ::operator delete найдёт?
C>>Они forward compatible в libstdc++.
E>Ха! А если я перекрою, например?
Будешь сам себе злобный Буратино.

E>Я не утверждаю, что COM на С++ написан или на него ориентирован. Я всего лишь утверждаю, что он задал формат таблиц виртуальных функций под винду...
Твое утверждение необоснованно.

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

I>>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>>на работе не самый свежий ассист стоит.
CC>>глянь на оффсайте, например тут:
CC>>http://wholetomato.com/products/featureRefactoring.asp
I>Короче говоря — ничего нет

I>Нужны высокоуровневые средтва, рефакторинг тот же.
Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.

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

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

E>>>>Чего? Как оно нужный ::operator delete найдёт?
C>>>Они forward compatible в libstdc++.
E>>Ха! А если я перекрою, например?
C>Будешь сам себе злобный Буратино.
ага вы можете выбрать себе любой цвет при условии что он черный И соответственно определить любой operator delete при условии что он тождественно равный free()

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

B>>Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.
V>Сдается мне, ты вообще не понимаешь, о чем идет речь в это дискуссии.
Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.

B>Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.
Господь с тобой, какие мои аргументы ты опроверг? Давай сначала, а то уже запуталось все.
Итак, с какими конкретно моими тезисами ты не согласен и почему?

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

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

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

B>>>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>>>Позволяет. Но некоторые языки позволяют делать это лучше.

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

___>Пруфлинк. Или нотариально заверенные скриншоты.

___>Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.
Я понимаю, Nemerle может служить примером. Но зачем писать Lisp? Почему его вообще всегда упоминают, а забывают про какую нибудь Аду или PL/1? Это же всё устаревшие языки программирования.

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

I>>Т.е. показать тебе именно пример где проперти не надо ?
V>То есть, property нужен только при работе с базами данных?

I>>Windows Presentation Framework
V>Ничего про нее не знаю.

I>>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
V>Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

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

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

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

CC>>>Для шарпа мало. Для С++ — достаточно.
CC>>>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

I>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>на работе не самый свежий ассист стоит.
CC>глянь на оффсайте, например тут:
CC>http://wholetomato.com/products/default.asp
CC>http://wholetomato.com/products/featureRefactoring.asp
Ассист бяка. Он на сложном коде, насыщенном шаблонами глючит.

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

B>C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.
B>Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.

На самом деле, с точки зрения выразительности запись std::map<std::string, std::string> гораздо лучше. И нужно писать именно так (но не в случае с STL ). Проблема в том, что STL довольно хреновая библиотека. И я вообще не знаю случаев, когда её использование было бы оптимальным решением. Но вообще говоря, можно реализовать библиотеку контейнеров (назовем её my_lib) так, чтобы использования объекта с типом my_lib::map<my_lib::string, my_lib:string> транслировалось в эффективный код.
Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка. Размер массива можно задавать через параметр шаблона, для этого определение класса строка должно иметь вид template<unsigned N = sizeof(char*)> class string;
Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.
И можно придумать множество параметров, в соответствии с которыми будут настраиваться контейнеры.
В итоге процесс программирования в таком случае можно будет поделить на две части. 1 — Написание логики работы программы. 2 — оптимизация программы путем подбора параметров контейнеров.
Только почему то господину Степанову это совершенно не пришло в голову...

B>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

WTF, что это за язык?!

void split(int *arr)
  requires(is_object_root(as_array(arr, 100)))
  writes(extent(as_array(arr, 100)))
{
  split_array(as_array(arr, 100), 50);
  split_array(as_array(arr+50, 50), 25);
  split_array(as_array(arr, 50), 25);
  split_array(as_array(arr+25, 25), 10);
}

void splitAndJoin(int *arr)
  requires(is_object_root(as_array(arr, 100)))
  writes(extent(as_array(arr, 100)))
{
  split_array(as_array(arr, 100), 50);
  join_arrays(as_array(arr, 50), as_array(arr+50, 50));
}

void join(int *arr1, int *arr2)
  requires(arr1 + 100 == arr2)
  requires(is_object_root(as_array(arr1, 100)))
  requires(is_object_root(as_array(arr2, 32)))
  writes(extent(as_array(arr1, 100)), extent(as_array(arr2, 32)))
{
  join_arrays(as_array(arr1, 100), as_array(arr2, 32));
}

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

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

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

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

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

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

MC>Не знаю, насколько это в ассисте хорошо работает,
Нормально работает. Кода с дикой мешаниной шаблонов, на котором кто-то отмечал глюки ассиста у меня под рукой нет.
Были билды где авторы чегой то там ломали, но на относительно последних — все ок.

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

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

I>>Т.е. показать тебе именно пример где проперти не надо ?
V>То есть, property нужен только при работе с базами данных?

Необязательно.

I>>Windows Presentation Framework
V>Ничего про нее не знаю.

Загляни в какой толковый туториал по MVVM.

I>>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
V>Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

Контролы в WPF и тот же System.Rectangle никакого отношения к БД не имеют.

Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?

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

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

I>>>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>>>на работе не самый свежий ассист стоит.
CC>>>глянь на оффсайте, например тут:
CC>>>http://wholetomato.com/products/featureRefactoring.asp
I>>Короче говоря — ничего нет

I>>Нужны высокоуровневые средтва, рефакторинг тот же.
CC>Зачем?
CC>Объясни?
CC>Какие средства надо? Что у тя входит в рефакторинг?

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

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

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

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

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

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

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

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

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

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

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

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

В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер потому ты их там и не видишь.

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

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

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

Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.

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

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

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

B>>Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.
V>Господь с тобой, какие мои аргументы ты опроверг? Давай сначала, а то уже запуталось все.
V>Итак, с какими конкретно моими тезисами ты не согласен и почему?

B>>В итоге, это позволяет писать на С++ код вида:
V>Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.
1) Не согласен с тем, что COM не позволяет напрямую использовать C++ для реализации интерфейсов. Контрпример — приведенный код, который будет успешно создавать экземпляр COM-интерфейса (AddRef()/Release() были опущены для краткости, с ними будет new CComObject<CSomething> вместо CSomething). И CComObject<> — это не "специфический биндинг для C++", а всего лишь shortcut для стандартных реализаций AddRef()/Release(), дополнительно упрощающий жизнь. Основной функционал — генерация vtable, выполняемая компилятором С++ без каких-либо дополнительных библиотек.
2) С тем, что "COM написан на C, так как там нет манглинга". Отсутствие манглинга и C-совместимые API для приложений означают extern "C" и желание разработчиков оставить совместимость для фанатов чистого C.

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

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

I>Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.
Твои фантазии касательно ниши С++ (и сопутствующий им флейм) оставим в стороне.

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

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

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

CC>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.

Да ты што!! Нам решарпер любую архитектуру исправит. Это ведь такая продвинутая штука!