Здравствуйте, Shady, Вы писали:
S>Здравствуйте, Дарней, Вы писали:
Д>>Если отвлечься от модной терминологии, то все-таки толстый? S>Он полу-толстый, нет для него терминологии Какая-то часть логики происходит на клиенте, при отсутсвии связи с сервером, всё на нём происходит. Но это сделано так хитро, что код бизнес логики не разрывается на клиентскую и серверную часть. Так что это смарт всё же — при соединении с сервером некоторые операции происходят на нём, при отсутствии соединения, на клиенте, но затем перепроверяются на сервере.
Д>>Так между серверами, или между клиентскими машинами? S>Серверами конечно
Честно говоря, не вижу ничего уникального. Аналогичный подход в КИС используется на фирме, где я раньше работал — уже лет 8 как используется, если не больше.
Здравствуйте, Shady, Вы писали:
S>Уже два На самом деле больше, на линюхе я еще два видел Просто лень в гугле рыться...
угу. слово sharp я не просто так выделил.
S>Непонял этого выражения? Где я записал всех оппонентов в раздел "не знают С++"?
Прямо вот здесь:
Если двое опытных людей в С++ со свободным временем найдутся, то они и сделают
S>? У нас разные представления о зачинщиках (я может то же в этом отметился, тут даже ветка моя есть, хотя это всего лишь был вопрос), но вроде уже притча есть, как Влад C# защищяет
Здравствуйте, alexeiz, Вы писали:
A>В каком-то смысле C++/CLI — это продолжение идеологии C++ на мир CLI (тавтологию сказал ). Ничего там сложного нет. C++ фичи распостраняются на managed мир. Для тех, кто не видел в глаза MC++, C++/CLI должен показаться достаточно логичным и законченным (кстати, в следующей версии компилятора, когда так называемая unified type system будет до конца реализована, managed и unmanaged миры станут во многом мало различимы).
посмотрим. Хотя меня все равно грызут сомнения, что из попытки скрестить ежа с ужом может получиться хоть что-то путное.
A>В каком смысле? Найдутся люди, что предпочтут MC++? Или ты думаешь, что компилятор C++/CLI так и не будет закончен?
Я думаю, что писать что-то серьезное на нем все равно не будут. Ибо не имеет смысла.
VladD2,
> ПК> Если ты о C++/CLI, то это тоже не совсем так: это одноплатформенные расширения C++.
> C++/CLI имет два режима в кторых он порождает чистый мсильные сборки. Как минимум один из режимов будет позволять переносить сборки на любую совместимую платфрму (например, на Моно).
CLI — это и есть та единственная платформа, на которую ориентирован C++/CLI. .Net и Mono — ее реализации.
> ПК> C#... Речь шла о языке, сохраняющем принятые в C++ идиомы.
> С целью? Тут вот человек говорит что С++-ники пишут в С-стиле. Зачем добиваться того же для Шарпа?
От C# ничего добиваться не надо. Речь идет о другом языке, поддерживающем идиомы C++.
> ПК> Это начало совсем другому языку, со своими, другими, чем в C++, идиомами.
> Ну, уж совсем другим это ты загнул. Из всех имеющихся языков он пажалуй ближе всего к хорошим сторонам С++.
У всех свое видение хороших (равно как и плохих) сторон C++. В моем — C# большую часть из них оставил за бортом, т.к. во многом потерял черты C++, ориентированные на усиление статической типизации (const, ссылки, шаблоны и т.п.).
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>В таком случае "безопасные" указатели семантически отличась бы от ссылок, пожалуй, только тем, что могли бы быть нулевыми.
> Ну, вот ты и домечтался до ссылочных типов.
Ссылки C++ и ссылочные типы C# — две большие разницы.
> В самом деле зачем вообще нужны взятие адреса и разыменаование если компилятор и так понимает где объект, а где ссылка на него?
Мне все равно, что там понятно компилятору. Для меня более важным является понятность кода для человека. Например, если считать, что следующее является фрагментом кода из языка, в котором есть разделение на ссылочные и value-типы:
void f(T a)
{
T b = a;
b.x = 10;
// чему здесь равно a.x?
}
Ответ зависит от того, что из себя представляет T.
В общем, мне намного больше нравится, если не определение типа определяет копирующую/ссылочную семантику использования, а это происходит более явно, по месту:
void f(T const& a)
{
T b = a;
b.x = 10;
// очевидно, что a.x не изменилось
}
другой вариант:
void f(T const& a)
{
T& b = a; // так сделать нельзя
b.x = 10;
}
третий вариант:
void f(T a)
{
T& b = a;
b.x = 10;
// очевидно, что a.x == 10
}
А если еще и шаблоны вспомнить, и представить, что это все дело внутри шаблонов... Ах, ну да, в C# же нет полноценных шаблонов...
> ПК> Кроме того, для "безопасных" указателей влет вводится опциональная сборка мусора, которую с "низкоуровневыми" указателями организовать несколько сложнее...
> Вот это фиг.
Не "фиг", а читаем любую книжку по сборке мусора. Вводится не напрягаясь. По сути, главным ограничением для введения сборки мусора в C++ (с формальной точки зрения) является возможность маскировать указатели, скажем, записывая их в файл, а потом считывая.
> Так что то что сделано в МС++ и C++/CLI — это и есть разумное, рельное решение. Другое врят ли появится.
Уже давно существует. Реализации сборки мусора для C/C++ появились раньше, чем CLI/.Net в планах нарисовался. Естественно, пользоваться ими менее комфортно, чем более тесно интегрированными с языком. Но и мы обсуждали не C++, а другой, воображаемый язык, который вполне мог бы отличаться от C++, позволяя более легко ввести сборку мусора.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> Ой зря вы надеетесь на C++/CLI. > 1. Для программирования анменеджед-приложений он врядли когда будет приспособлен.
Ну так и C# это вряд ли светит...
> 2. В чистых режимах (пьюр и сэйф) он будет урезан практически до возможностей Шарпа.
Но с детерменированным разрушением объектов, шаблонами, свободными функциями, и более развитой объектной моделью. Что уже немало.
> В итоге C++/CLI — это замечательная маркетинговая уловка призванная привести на платформу дотнета непримиримых С++-ников (тех кто не хочет или не может изменить привычки).
Yes, managed code is the direction we are going in moving forward for all the places where it makes sense. However extrapolating that to mean C# is simply not true. We are spending a lot of resources to make sure C++ is a primary development language on the .Net platform and are seeing a lot of internal adoption of C++ to write managed code inside of Microsoft. In the RTM version the primary focus of MC++ is to enable you take integrate easily with existing code, but in future releases you will see us focusing much more on making C++ take up the traditional role it serves role as the high end language for system level programming and for expert level programming on the .Net platform.
Вкратце: Майкрософт не планирует переводить основные разработки на C#. Основная часть приложений Майкрософт делается и будет делаться на C++. Для этих нужд C++/CLI и создан. А маркетинг... Это скорее то, что сопутствует C# или Java
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Shady, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
AVK>>Интересно, что ж это за софт такой? Как называется? Если это коробка, то никаких причин скрывать его название я не вижу. S>Софт разрабатывается, оффициального названия нет, есть кодовое "платформа". Мой работодатель не позволяет мне раскрывать больше информации.
ERP с 10000 клиентов не имеющих денег на железо пятилетней давности, да еще и не выпущенная еще.
В общем, ты чем мозги нам пудрить приглоси сюда своего начальника. Глядишь он что-то обяснит, или сам поймет.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shady, Вы писали:
S>Что у вас за фичи уникальные? По описанию/юзанью вашего софта я их не увидел, это не издевательство, я серьёзно, конкурента, так сказать, узнать
Сдается мне твоей случай как раз тот о котором тут так часто любят рассказывать С++-програмиисты (особнно ГВ).
Нравится мне твоя самоувереннсоть. У тебя сложные фичи, а сотсальные щи лаптем хлебают. Хотя да... у тебя же этот... как его... опыт.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shady, Вы писали:
S>Вот JIT улучшат, вот тогда посмотрим.
Думаю, что ты даже приблизительно не соизмеряешь скорость джита и те проблемы производительности которые вы вносите в свои приложения просто выбором не очень оптимальных стратегий или алгоритмов. А уж столько вы теряете на дизайне...
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shady, Вы писали:
VD>> Ты бы хоть в профайл глянул. S>Ну а что тогда бред пишешь?
[офтоп]
Интересно, Паша у нас плюсы ставит всегда когда хамство в мою сторону заметит, или это чисто случайные совпадения?
[/офтоп]
Ну, да кто из нас бредит, думаю, видно не вооруженным взглядом. Вот10000 клиентов в Моске у еще не выпущенной ERP-системы — это форменный бред. Я бы даже сказал бред сивой кобылы.
Тебе же я рассказываю, то что слышал в конторе занимавшейся дистрибуцией продукции Адобы на страны бывшего СССР.
VD>>И скажу тебе по сикрету, что дизайнерских студий кот наплакал. На них бабки не сделашь. Основные инсталяции Фотошопа — это обычне контроы. Почти везеде нужно кратинку пдрихтовать или буклетик сверстать. S>Тьфу, я чуть не поперхнулся! Ты о КАКОЙ стране говоришь? О России? То да, тут у всех софт за 80 рэ. На западе, чтоб картинку подретушировать используют не Фотошоп, а что подешевле, они не идиоты, выкладывать 649$.
Про пиратов и про Россию даже говорить нечего. Тут количество маков недотягивает и до долей прцента.
S>Знаешь что, действительно, у тебя наблюдается тенденция абсолютизма: S>вот не получилось у тебя с С++,
Откуда ты знашь, что у меня и с чем не получилось? Свечку держал? Или телепат. А раз так делай лучше предположения о том сколько протянет не ранке ERP-система разрабатываемая в 21 веке на С++, так как от этого когда новую работу искать.
S> значит всё, язык хуже всех на свете для всех. Если ты редактор и у тебя в издательстве нет Маков, значит всё, не у кого их нет и т.д. и т.п.
Блни, провидец. Ты лучше чем сомневаться в чужих словах сначала научись врать складно. А то у меня живот болит от смеха с тех пор как я твои посты про 10000 неродившихся клинтов и страшную буржуинскую тайту прочел.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Все зависит от полной картины. Можно представить массу случаев, где описанный тобой подход приводит к значительно большему количеству работы. И, главное, на ровном месте, т.к. никаких недостатков, кроме несоответствия твоим вкусам, у приведенного решения не наблюдается.
Ты, знаешь, когда я раньше встречал с твоей стороны защиту тех кто закладывается на разные частности, то думал, что это ты чтобы спор поддержать, ну, или мне наперекор сказать что-то хочешь. Но видимо ты действительно не понимашь опасности токой политики. Раньше мне казалось, что подобное мнение присуще совсем зеленым товарищам у которых сомомнение забивает остатки разума. Видимо я ошибался.
ПК>Потому что я не соглашаюсь с частными утверждениями,
А, ну, да. Поспорить о том 90% или 99.999. Вот это достойный спор.
ПК> обычно приводя аргументы,
Ненадо песен. Аргументы эти за аргументы воспринимают только те кто сами от уровня плюсов оторваться не могут.
ПК> а ты порой приписываешь мне высказывания (обычно о "глобальных" вещах), которых я не делал.
А, ну, ну.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>.Net — не язык, если речь не идет о MSIL. А так... По пунктам, пожалуйста. Одно, случайно попавшее, заметил сам: dynamic_bitset.
Обучать тебя в интерактивном режие дотнету у меня нет времени. Прочти рихтера, статей с нашего сайта, думаю 90% вопросов исчезнут сами собой.
>> Все эти "concept check" и "static_assert" рядом с возможностями R# не лежали.
ПК>R# мы не обсуждаем.
А что мешает?
ПК> Препроцессоры можно к любому языку прикрутить.
И что позволят тебе пользоваться убогим препроцессорм С++ (если ты не понял — это я и о шаблонах) и не взять на вооружение кода более мощьные вещи?
>> Спириты же вообще отдыхают по сравнению с любым постраителем парсеров и кроме как красивой игрушкой больше ничем не являтся.
ПК>Все зависит от задач. Для простеньких вещей генераторы парсеров — overkill.
Чущь. Я с успехом применял их и для примитивного парсинга. Это быстрее и удобнее чем вознят со спиритом. Чтобы создать парсер нужно знать теорию и для использования спирита, и для использования кокора. Так что затраты сил идентичны. А вот результат всегда лучше у генератора.
>> 1. Я лично вылавливал две недели одну тревильную (казалось бы) ошибку. Причем посодил ее не я.
ПК>Да, иногда бывает. Я сравнительно недавно описывал как раз такую: http://rsdn.ru/Forum/Message.aspx?mid=650616&only=1
Неоткрывается.
ПК>Одна из трех за последние более чем пол-года. Эта была самой долгой в диагностике, часа 3-4, наверное. В сумме с остальными двумя можно увеличить до одного дня. Я готов столько накинуть на любой проект ради тех вещей, которые мне нравятся в C++. Никаких особых страданий по этому поводу я не испытываю: ошибки, как ошибки.
Проблема в том, что еще 2-3 серьезных ошибки у тебя всегда остается в коде и они в любой миг могут снести все приложение и данные пользователя. Ну, и похоже ты никогда не ловил ошибки за другими. Поверь найти свою ошибку в сто раз проще. А если тебе нужно пасти троих и более программистов, то в самую пору подумать о "пластмассовом ноже"/"безопастной бртиве".
ПК>Значительно больше неприятностей доставляют логические ошибки, когда при проектировании пропускается какой-нибудь существенный use case,
Я уже устал повторять... но логические ошибки и ошибки проектировани тоже проще устранять на более высокоуровневх языках нежели на С++. Я за последние 4 дня перелопатил весь R# 6 раз. На плюсах мне такое и не снилось. Давича для удаления старого (рукописного кода) добавил в CodeAnalizet (ГУИёвую утилиту из R#-а) рефактроинг на базе XPath запросов. Писал это дело часа 3... потом за 0.6 секунды решил задачу. Вот кстати, запросик:
//class[rs:IsInheritedFrom('RSParser.CodeDom.AstNode') and @Name != 'RProject' and @Name != 'RCompileUnit']//ctor[not(./CustomAttributeSections/attribute-section/AttributeDeclarations/attribute[@Name = 'Handwork'])]/Statements
Выбирает весь код (если он есть) конструкторов не помеченных атрибутом Handwork классов наследников RSParser.CodeDom.AstNode кроме RCompileUnit и RProject.
Попробуй ради хомхмы повторить это на плюсах.
И так везде. Ты считашь, что ошибка архитектора это глобальная проблема... А я за три часа создаю тул решающих проблему раз и на всегда. Причем следующий я уже создам за пол часа. В общем, это тяжело передать, но есть некий кумулятивный эффект позволяющий резко повысить общий уровень разработки.
ПК> и нужно затрагивать некоторые аспекты дизайна, тяжело поддающиеся изменению. Тогда, да, приходится напрячься. Но плюс-минус то же самое будет и в C#/Java/Whatever.
Отнюдь. Плюсы оттдыхают в каенном веке.
>> 2. На дотнете я больеше получаса на поиск ошибки обычно не трачу. Ну, тяжело добиться ошибки второго/третьего порядка. Нет испорченой памяти, нет выходов за пределы массивов. Везеде нормальные исключения с колстэками. И оптимизатор не наровит извратить код как бог черепаху.
ПК>Да, это положительные стороны. Для меня их недостаточно, чтобы скомпенсировать отрицательные.
Пашь, поверь добавить недостающие вещи к Шарпу намного проще чем выличить С++.
Просто нужно уметь взглянуть на проблему по другому. Не так как на нее смотрит обычный С++-ник.
Забавно, но работая над R#-ом я вдруг осознал, что многое ради чего я создавал R# можно было делать на дотнете и другими средсвами. Просто мои комплексы (во многом сформированные С++-ом) не довали мне очистить свой разум (с). Конечно имея доведенный до промышленного качества R# намного мощьнее, гибче и удобнее, но и без него есть все что нужно для того чтобы решать сложнейшие задачи так как на плюсах и представить себе невозможно. К сожалению толковый рассказ о всем этом слишком непростое дело.
>> Ну, да. До тех пор пока не начали его сдовать. А как ближе к релизу, так... где там Баундчекер?... Какой критин... и т.п.
ПК>У себя в проектах я такого не наблюдаю.
Значит до релиза еще есть время.
ПК>Проще далеко не всегда. Маленькие вещи — да, проще.
Я кстати, заметил... ты не одинок в упоминании "маленьких вещей". Я уже много раз слышал нечто подобное. Но это самовнушение. Проще и маленькие "вещи" и большие.
ПК> Но в основном не из-за безопасности, а из-за 1) динамической типизации;
А я то болван, все по старинке пытаюсь максимально жить со статической. Правда, Паша, в том, что динамичекая типизация и тому подобные вещи — это вынужденный компромис дизайна. И обойти его не всилах ни ты, ни я (ни на С++, ни на Лиспе). И тут наличие качественного рантайма конечно способствует упрощению жизни. Однако во многих случаях рарод занимается распихиваением приведений типов по всему коду только от безграмотности. Всякие итераторы и посетители решают 90% проблем даже без дженериков. А уж с ними и вообще подобные проблемы становятся проблемой кривых рук. Ну, а разу уж речь о кривых руках, то я предпочту, чтобы за ними (даже если это мои руки) следил бескомпромисных рантайм, а не надзиратель проверяющий применение паттернов.
ПК> 2) более быстрого цикла разработки (не нужно компилировать, линковать и т.п.).
От тут немгу не согласиться. Это несомненно правда. И те кто не прониклись даже не представляют насколько ускоряется цикл!
ПК> Когда проект дорастает до определенных размеров, становится заметно сложнее.
А это уже самовнушение. Масштабирование линейно. Естественно с большим проектом сложнее, но плюсы эту сложность не устраняют. Более того они ее увеличивают своей сложностью. А отсуствие возможности быстрого и глубокого рефакторинга делают работу над большими проектами еще более сложной. Ведь малейшая ошибка дизайна и геморрой на долгие нидели (а то и месяцы) обеспечен.
ПК> Плюс, Шарпу до Питона по части многих возможностей, меня интересующих, еще расширяться нужно.
Это каких же? Никак отсуствие строгой типизации, обязательного объявления переменных, десятикрантый проигрыш в скорости?
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Там я говорил о том, что и у того, и у того подхода есть свои преимущества и недостатки. О безусловном преимуществе монолитного дизайна я уж точно не говорил. В проектах, с которыми я сталкиваюсь, обычно предпочитаю модульность.
Ну, и про отсуствие необходимости в компонетных фичах ты тоже не говорил? Или ни они ли делают модульность реальной? Или мы за модульность монолитного типа? На уровне исходников?
ПК>Еще раз: ошибался, халтурил и т.п. Но мне интересны языки, предоставляющие больше возможностей, а не усекающие их ради "безопасности".
Ой ли? А не ты ли обертываешь все указатели в обертки? Что же это за ограничение такое, снимающее с тебя рутину?...
ПК> "Безопасность" появляется на горизонте при прочих равных, чего в данном случае и близко не наблюдается.
Расскажи нам про "близко не наблюдается" и "при прочих равных" ты все время упрекаешь меня в том, что я за тебя домысливаю. Вот как раз тот случай. Ты вроде как высказался негативно о чем-то. И это что-то явно C# + дотнет. Но прямо ведь ты не говоришь. Ну, давай или выскжись прямо, или скажи, как всегда "ничего подобного я не говорил/думлал" и мы все поймем, что это просто "слова в небо".
ПК>Скажем, если бы C++ остался бы тем же, что сейчас, но пресловутая арифметика указателей была бы вынесена в какой-нибудь "unsafe", наверное, был бы "за" (хотя, имхо, есть более удачные альтернативы). Плюс еще ряд улучшений не повредил бы. Но с сохранением возможности использования наработанных в C++ приемов.
А ты уверен что верно оценивашь количество того что нужно удалить из С++ (вынести в ансэйф)? Я вот уже 100%-но уверен, что проще недостающие вещи добавить в C#. Ведь практически все проблемы С++ в нем устранены.
ПК>C# — не тот случай.
Чем же? Поведай нам незнайкам. Как же мы умудряемся писать на нем быстрее и качественее? Может мы не знаем некий "дзен"?
ПК>Его обстругали значительно более радикально. Generics уже, правда, добавили. Если еще подобавляют, может, и будет иметь смысл на него еще посмотреть...
Ай, снобизмом тянет... Так, все же может ты выключишь этот снбизм и перечислишь что тебе нехватает в C# кроме метапрограммирования на шблонах (условимся, что R# уже сейчас дает значительно больше в этой области чем они)? Да, подключение реализаций (в том числе и к вэлью типам) R# тоже реализаует элементарно. Так что там тебе еще мешает? conast для локальных переменных? Несмешите мои тапочки.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
S>>Вот JIT улучшат, вот тогда посмотрим. VD>Думаю, что ты даже приблизительно не соизмеряешь скорость джита и те проблемы производительности которые вы вносите в свои приложения просто выбором не очень оптимальных стратегий или алгоритмов. А уж столько вы теряете на дизайне...
Я не знаком с Shady, но ИМХО, Влад, ты несколько поспешно делаешь свои предположения. Или, это уже выводы?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
VladD2,
> ПК>Там я говорил о том, что и у того, и у того подхода есть свои преимущества и недостатки. О безусловном преимуществе монолитного дизайна я уж точно не говорил. В проектах, с которыми я сталкиваюсь, обычно предпочитаю модульность.
> Ну, и про отсуствие необходимости в компонетных фичах ты тоже не говорил?
Нет. Последнее, что я по этому поводу помню, касалось отсутствия у меня необходимости в компонентности самой по себе.
> Или ни они ли делают модульность реальной?
Не только они.
> Или мы за модульность монолитного типа? На уровне исходников?
И это тоже. Но обычно предпочитаю оборачивать модули своих программ в DLL (без COM).
> ПК> Еще раз: ошибался, халтурил и т.п. Но мне интересны языки, предоставляющие больше возможностей, а не усекающие их ради "безопасности".
> Ой ли? А не ты ли обертываешь все указатели в обертки?
Нет. В обертки я оборачиваю только те указатели, которые в этом нуждаются. Т.е., например, представляющие собой массивы, или те, что указывают на объекты, которые нужно удалять через delete.
> ПК> "Безопасность" появляется на горизонте при прочих равных, чего в данном случае и близко не наблюдается.
> Расскажи нам про "близко не наблюдается" и "при прочих равных" ты все время упрекаешь меня в том, что я за тебя домысливаю.
Я уже устал это перечислять. Писал больше одного раза в данной теме в прямых ответах на твои сообщения, чего именно мне не хватает в C# или Java.
> ПК> C# — не тот случай.
> Чем же?
Тем, что не сохраняет наработанные в C++ идиомы: "с сохранением возможности использования наработанных в C++ приемов. C# — не тот случай.".
> ПК> Его обстругали значительно более радикально. Generics уже, правда, добавили. Если еще подобавляют, может, и будет иметь смысл на него еще посмотреть...
> Ай, снобизмом тянет...
> Так, все же может ты выключишь этот снбизм и перечислишь что тебе нехватает в C# кроме метапрограммирования на шблонах (условимся, что R# уже сейчас дает значительно больше в этой области чем они)?
1) R# меня (по крайней мере, пока) не интересует, так же как и другие дополнительные препроцессоры, т.к. не распространен в достаточной степени, чтобы быть доступным везде, где доступен сам язык.
2) В C# мне не хватает большей ориентированности на статическую, а не динамическую, типизацию (да, и const тоже), плюс поддержки многих идиом, которые мне нравятся в C++. Для последних нужны: свободные функции, детерменированное разрушение объектов, шаблоны, явные ссылки и указатели, а не разделение на ссылочные и value-типы, композиция классов множественным наследованием и наследованием от шаблонов безо всяких виртуальных функций, стало быть и полноценные шаблоны.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> .Net — не язык, если речь не идет о MSIL. А так... По пунктам, пожалуйста. Одно, случайно попавшее, заметил сам: dynamic_bitset.
> Обучать тебя в интерактивном режие дотнету у меня нет времени. Прочти рихтера, статей с нашего сайта, думаю 90% вопросов исчезнут сами собой.
Влад, это уже просто абзац. Сначала ты просишь перечислить, что именно есть в boost, чего нет в .Net. После того, как я это делаю, ты просто отмахиваешься. Если тебе есть, что сказать по этому поводу — скажи. В противном случае лучше молчать.
> ПК> Я сравнительно недавно описывал как раз такую: http://rsdn.ru/Forum/Message.aspx?mid=650616&only=1
> ПК>Одна из трех за последние более чем пол-года. Эта была самой долгой в диагностике, часа 3-4, наверное. В сумме с остальными двумя можно увеличить до одного дня. Я готов столько накинуть на любой проект ради тех вещей, которые мне нравятся в C++. Никаких особых страданий по этому поводу я не испытываю: ошибки, как ошибки.
> Проблема в том, что еще 2-3 серьезных ошибки у тебя всегда остается в коде и они в любой миг могут снести все приложение и данные пользователя.
То же самое верно и для других ошибок: исключение точно так же может снести все приложение и данные пользователя.
> Ну, и похоже ты никогда не ловил ошибки за другими. Поверь найти свою ошибку в сто раз проще.
"Ох уж мне эти сказки, ох уж мне эти сказочники". Все эти ошибки были не моими, а в чужом коде. В проекте, который уже существует лет десять. К которому я присоединился всего пол-года назад. В самых старых частях его кода. То есть к "найти свою ошибку в сто раз проще" это вообще не относится.
> И так везде. Ты считашь, что ошибка архитектора это глобальная проблема... А я за три часа создаю тул решающих проблему раз и на всегда.
Я прекрасно представляю пределы возможностей автоматизированных средств анализа кода. Большинство вещей, на которые у меня идет время при разработке на C++, находится за этими пределами. Обычно это непонимание, что одна функция на самом деле представляет собой две или более семантически различных операции. По формальным признакам, какая из операций должна быть в каком из мест, где используется данная функция, определить невозможно. Соответственно, чтобы перелопатить код, нужно пройтись по каждому из случаев, и "глазками" определить, какая из новых двух функций должна использоваться в каждом из случаев.
> ПК> Плюс, Шарпу до Питона по части многих возможностей, меня интересующих, еще расширяться нужно.
> Это каких же? Никак отсуствие строгой типизации, обязательного объявления переменных, десятикрантый проигрыш в скорости?
В данном случае речь шла о приемах функционального программирования, по которым Питон, на мой взгляд, далеко "обходит" C#.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> ПК>В таком случае "безопасные" указатели семантически отличась бы от ссылок, пожалуй, только тем, что могли бы быть нулевыми.
>> Ну, вот ты и домечтался до ссылочных типов.
ПК>Ссылки C++ и ссылочные типы C# — две большие разницы.
С этим никто не спорит. Просто ты в своих поисках идиала в плотную подобрался к ссылкам в C#.
>> В самом деле зачем вообще нужны взятие адреса и разыменаование если компилятор и так понимает где объект, а где ссылка на него?
ПК>Мне все равно, что там понятно компилятору.
Дык чем меньше шума в коде, тем проще его воспринимать.
ПК> Для меня более важным является понятность кода для человека. Например, если считать, что следующее является фрагментом кода из языка, в котором есть разделение на ссылочные и value-типы: ПК>
ПК>void f(T a)
ПК>{
ПК> T b = a;
ПК> b.x = 10;
ПК> // чему здесь равно a.x?
ПК>}
ПК>
ПК>Ответ зависит от того, что из себя представляет T.
Это чисто теоретические рассуждения. Рельно подобных проблем не возникает. В тех местах где действительно разница в семантики вэлью-типов важно компилятор не дает ошибиться. А такие случаи проблем у народа не вызывают. С этим все равно в сто раз проще разобраться, чем каждый раз мысленно сопровождать разыменование и другую шушору работы с указателями.
Если уж говорить о реальных вопросах, то больше возникает вопросов по работе со строками (они ведь ведут себя очень похоже на вэлью-типы) и переопределенными операторами сравнения (пример со сравнением строк ты помнишь).
ПК>В общем, мне намного больше нравится, если не определение типа определяет копирующую/ссылочную семантику использования, а это происходит более явно, по месту: ПК>
ПК>void f(T const& a)
ПК>{
ПК> T b = a;
ПК> b.x = 10;
ПК> // очевидно, что a.x не изменилось
ПК>}
ПК>
ПК>другой вариант: ПК>
ПК>void f(T const& a)
ПК>{
ПК> T& b = a; // так сделать нельзя
ПК> b.x = 10;
ПК>}
ПК>
ПК>третий вариант: ПК>
ПК>void f(T a)
ПК>{
ПК> T& b = a;
ПК> b.x = 10;
ПК> // очевидно, что a.x == 10
ПК>}
ПК>
Это потому что ты привык к этому убожеству. Еще раз повторюсь... все это мусорный шум мешающий воспринимать реальную суть приложения.
В реальном программировании 98% объектов являются ссылочными (я не шучу). Те что что являются вэлью-типми обычно имеют выраженный вэлью-характер. С ними обычно работаешь очень похоже на встроенные примитивы вроде int. Например, для работы с датами используется структура DateTime. У нее просто нет модифицирующих операций. Все операции возвращают новое значение. Так что ошибиться невозможно. И это характерно для большинства структур.
Ну, а что до твоих примеров, то подставь любой примитивный тип и ты получишь в С++ ту же проблему, что и поисывал в Шарпе.
ПК>А если еще и шаблоны вспомнить, ПК> и представить, что это все дело внутри шаблонов...
То ничего ровным счетом не изменится.
ПК> Ах, ну да, в C# же нет полноценных шаблонов...
Ах, ну, да... Как же не наехать при случае?
Тут есть два мнения. Одно из них, то что в С++ полноценных шаблонов нет. А есть убогий препроцессор который синтаксическим то развать язык не поворачивается. Так что давай не будем в суе поминать эту тему.
>> ПК> Кроме того, для "безопасных" указателей влет вводится опциональная сборка мусора, которую с "низкоуровневыми" указателями организовать несколько сложнее...
>> Вот это фиг.
ПК>Не "фиг", а читаем любую книжку по сборке мусора.
Хоть обчитайся. Фиг он и в Африе фиг.
ПК> Вводится не напрягаясь.
Чушь. Очень напрягаясь и приводит к большому количеству ограничений. Иначе получаются уроды "о которых пишут в крижках".
ПК> По сути, главным ограничением для введения сборки мусора в C++ (с формальной точки зрения) является возможность маскировать указатели, скажем, записывая их в файл, а потом считывая.
По сути ты опять начинашь говорить о проблеме которую знаешь очень поверхностно. Я к сожалению тоже не большой спец в ней. Но даже то что зная на сегодня я наводит меня на мысль, что создать качественную реализацию ЖЦ очень тяжело (а скорее невозможно) без существенного ограничения адресной арифметики. И что реализации ЖЦ от МС или Сана — это одни из самых качественных реализаций из имеющихся. И ребята из этих контор знают что делают. Вот что пишит один сведующий товарищь по поводу ссылок в Роторе:
Interior References
For convenience, we allow the stack to reference an object by the address of one of its members instead of its beginning. It makes ByRef implementation convenient. This complicates the mark phase because GC can’t set the bit of the DWORD pointed to by the reference anymore. An extra argument passed by the code manager to GC tells GC that the reference may be interior and GC will search through its data structure to locate the beginning of the object. Since this is a costly process, only stack locations are allowed to contain interior references.
>> Так что то что сделано в МС++ и C++/CLI — это и есть разумное, рельное решение. Другое врят ли появится.
ПК>Уже давно существует. Реализации сборки мусора для C/C++ появились раньше, чем CLI/.Net в планах нарисовался. Естественно, пользоваться ими менее комфортно, чем более тесно интегрированными с языком.
Да нельзя ими пользоваться. Задница это. Эксперементы свободных художников, так сказать. А нужно решение промышленного качества. И когда над таковым начинают работать, то плучается нечто вроде ЖЦ в дотнете или Яве. И все потому что есть рельные сложности, а не от криврукости или скудоумия. У разработчиков С++ таких ресурсов попросту нет. А крутые конторы вроде IBM и МС на подобные исследования грантов вроде в последнее время не даеют.
ПК> Но и мы обсуждали не C++, а другой, воображаемый язык, который вполне мог бы отличаться от C++, позволяя более легко ввести сборку мусора.
Дык, чудак ты человек, я тебе и говорю, что есть реальные проблемы в реализации ЖЦ. И они начинают давлеть на дизайн языка/рантайма. Дотнет и C# — это компромис. Причем очень достойный. Сделать лучше конечно всегда можно. Но нужно понимать, что это архи-сложно.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alex Reyst, Вы писали:
AR>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Да-да! А еще ножи бывают настоящие, "опасные", а бывают пластиковые, "безопасные"
AR>Пластиковые ножи, искусственные елки, безалкогольное пиво и технология .NET — вот что ведет человечество к надувным резиновым женщинам и биологическому краху! AR>
Смех смехом, но всё вышеперечисленное -- действительно знаки разложения и деградации современного общества. Лучший способ защититься от изнасилований -- кастрировать всех мужчин при рождении. Что нам поборники .Net и предлагают.
Какая-то часть логики происходит на клиенте, при отсутсвии связи с сервером, всё на нём происходит. Но это сделано так хитро, что код бизнес логики не разрывается на клиентскую и серверную часть. Так что это смарт всё же — при соединении с сервером некоторые операции происходят на нём, при отсутствии соединения, на клиенте, но затем перепроверяются на сервере.
На самом деле больше, на линюхе я еще два видел 
Это несомненно правда. И те кто не прониклись даже не представляют насколько ускоряется цикл!
