Частота ошибок в зависимости от языка: что делать? - Философия программирования

Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???

Можно ли разработать ещё более экономичные языки?

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

FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

FDS>Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???

FDS>Можно ли разработать ещё более экономичные языки?

Признаюсь, доку не читал. Но подозреваю, что ошибки всё-таки делает программист, а не язык

Код на Ада может быть в среднем менее "ошибочным" хотя бы потому, что на Ada пишут гораздо меньше, чем на C++, Ada-спецов меньше и, как следствие, они качественнее

Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".

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

O>Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".

1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

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

3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

FDSC wrote:

> Слышал, что при написании программ на C++ количество допущенных ошибок
> на порядок больше, чем при написании их же в "АДА", стоимость выше на
> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
такая статистика неудивительна.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>FDSC wrote:

>> Слышал, что при написании программ на C++ количество допущенных ошибок
>> на порядок больше, чем при написании их же в "АДА", стоимость выше на
>> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

C>Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
C>такая статистика неудивительна.

Прочитай по внимательней, там есть раздел по исследованиям по C++. Говорят, что C++ не исправил ошибок в C.

FDS>Здравствуйте, Cyberax.

Кстати, речь ведь не только о C++ и есть ещё много других статей по сравнению языков (привести сей-час честно говоря не могу).

Кстати обращаю внимание на другое:
Язык Ада, между прочим, предназначен для приложений реального времени. Цитата: "Технология Java не является устойчивой к сбоям и не предназначена ... для использования в рамках управляющих систем реального времени...."

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

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

FDS>http://www.adaic.com/whyada/ada-vs-c/cada_art.html.
Прочитал. КГ/АМ.

Порадовало следующее:
Coding standards for C have been aimed at avoiding the known problems with the C language. A partial list is:

· dangling "else"s
Это что ли "if( condition ) { block } else"?
Это в каком наркотическом бреду такое может стать ТАКОЙ проблемой,
что надо специально этот случай оговаривать в стандарте кодирования ?

· use of "=" for "==", especially in conditional statements
Гы

Новички от этого страдают. Но компиляторы как правило на такое
ругаются ворнингами. А программеров что игнорируют ворнинги — кастрировать
без права обжалования.

· use of "/=" for "!="
Гм... А в каком это языке "не равно" пишется как "/="?

· overuse of macros
Да, это грех. Полностью согласен.

· use of "cute programming" that sacrifices comprehension for brevity
...Вообще-то это дело вкуса...

· use of integer for pointer
Ну, это возможно только в С, но не в C++

Вот еще:

Will C++ Change The Picture?
Some may look at this study and conclude that C++ will tame C's problems.

Our early experience does not support that conclusion.

Bug rates in C++ are running higher even than C, although we have no where near the ideal comparison platform that we have had with VADS for C and Ada. We do not yet have a large mix of people programming in both C++ and Ada for similar difficulty programs and with history as released products. Our theoretical views of our C++ problems indicate that C++ may allow "run-away inheritance", where many very similar classes are created from a substrate without care to design a smaller number of re-usable classes without many variants; also, existing C++ programs have not yet made good use of templates and so have become cluttered with "container classes" and attendant conversions; finally, so much of C++ goes unseen, hidden behind the notational convenience of the language, that the code can become difficult to understand and navigate. We have had long experience with Object Oriented Software, and believe that OO approaches can yield great benefit if tools can fully support the OO process, and if inheritance complexity can be minimized.

Мое резюме: Ребята, возможно, неплохо знают Аду, но знают C очень поверхностно.
С++ они не знают совершенно. Короче, еще одно сборище адвокатов пытающихся давать советы космического масштаба и космичексой же глупости. Фтопку.

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

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

O>>Какие бы приёмы не применялись для уменьшения количества ошибок на стадии разработки, всё равно их количество обратно пропорционально квалификации программиста, а не некоему "коэффициенту безошибочности языка".

FDS>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

Великая страна Индия всеми силами опровергает данный постулат

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

Ну, во-первых, не C++, а C (т.е. статистика собиралась именно по C vs Ada). А во-вторых, можно ли говорить об объективности и достаточном количестве статистических данных в пределах одного проекта?

FDS>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

Предполагаю, что чем распространённее язык, тем больше вероятность нарваться на неквалифицированного программиста. В контексте нашей страны (пост-СССР) такие языки, как Ада, Форт или Оберон не очень широко распространены, поэтому часто люди используют их из любви к искусству, а не только из-за требований тимлида, что влечёт за собой более высокую квалификацию таких людей "за те же деньги"

Потом, если уж такой разговор зашёл, то почему именно Ada vs C? Могу заявить, что разрабатывать на C# (или, скажем, на Java) сейчас дешевле и надёжнее, чем на C (за C++ не скажу). Так почему Ада? Переходим на C#. Или на Оберон — он вообще "синтаксически минимален"

PS: в общем-то, я к тому, что серебрянной пули нет...

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

...

Эти ребята очень неплохо знают C++, просто 1995 статья написана. Я уже немного раньше сказал, что речь идёт не только о C++ и Аде и есть множество различных мнений по этому вопросу.
Мне, кажется, что от языка всё-таки очень много зависит; я хотел бы узнать мнение других не только по поводу Ады, это просто как пример. Ада и С++ даже не вынесены в заголовок...

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

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

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

O>Потом, если уж такой разговор зашёл, то почему именно Ada vs C? Могу заявить, что разрабатывать на C# (или, скажем, на Java) сейчас дешевле и надёжнее, чем на C (за C++ не скажу). Так почему Ада? Переходим на C#. Или на Оберон — он вообще "синтаксически минимален"

O>PS: в общем-то, я к тому, что серебрянной пули нет...

Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Я не вижу, чем managed С++ хуже C#. (Впрочем, у меня немного практики программирования под .NET). По поводу Java я уже тут где-то написал, что технология не предназначена для работы в системах управления ответственными объектами в режиме реального времени.

FDSC wrote:

>>> Слышал, что при написании программ на C++ количество допущенных ошибок
>>> на порядок больше, чем при написании их же в "АДА", стоимость выше на
>>> 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).
> C>Там с Адой сравнивается не _С++_, а С. Это КРАЙНЕ разные языки, так что
> C>такая статистика неудивительна.
> Прочитай по внимательней, там есть раздел по исследованиям по C++.
> Говорят, что C++ не исправил ошибок в C.

Совсем странно:
================
Bug rates in C++ are running higher even than C, although we have no
where near the ideal comparison platform that we have had with VADS for
C and Ada. We do not yet have a large mix of people programming in both
C++ and Ada for similar difficulty programs and with history as released
products. Our theoretical views of our C++ problems indicate that C++
may allow "run-away inheritance", where many very similar classes are
created from a substrate without care to design a smaller number of
re-usable classes without many variants; also, existing C++ programs
have not yet made good use of templates and so have become cluttered
with "container classes" and attendant conversions; finally, so much of
C++ goes unseen, hidden behind the notational convenience of the
language, that the code can become difficult to understand and navigate.
We have had long experience with Object Oriented Software, and believe
that OO approaches can yield great benefit if tools can fully support
the OO process, and if inheritance complexity can be minimized.
================
Скорее всего они:
1. Использовали малоопытных С++ников.
2. Использовали древнюю (даже для 1994г.) версию С++.
3. Пункты 2 и 1 вместе взятые.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>Скорее всего они:
C>1. Использовали малоопытных С++ников.
C>2. Использовали древнюю (даже для 1994г.) версию С++.
C>3. Пункты 2 и 1 вместе взятые.

Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в программировании на C++ чего-то??? (я сам прогр. Delphi / assembler, C++ только правлю и дополняю, и то не очень часто).

В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).

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

[... skipped ...]

O>>PS: в общем-то, я к тому, что серебрянной пули нет...

FDS>Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Не такое уж и старое. Оберон — это наследник Паскаля (и Модулы-2, соответственно).

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

FDS>Я не вижу, чем managed С++ хуже C#. (Впрочем, у меня немного практики программирования под .NET). По поводу Java я уже тут где-то написал, что технология не предназначена для работы в системах управления ответственными объектами в режиме реального времени.

Так Java вроде и не для систем реального времени предназначалась imho. Основная задумка была в кросспратформенности. Ну и в мегафичах вроде "всё есть объект", "всегда есть GC" и т.д.

А насчёт Managed C++ — да ничем он не лучше C#. И вообще, наиболее эффективный .NET-код можно написать только на IL

Но мне лично не нравится уродский синтаксис MC++ (C++ фактически приклеили пару новых ног, чтобы он смог бегать по новой платформе).

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

[... skipped ...]

O>А насчёт Managed C++ — да ничем он не хуже C#. И вообще, наиболее эффективный .NET-код можно написать только на IL

Но мне лично не нравится уродский синтаксис MC++ (C++ фактически приклеили пару новых ног, чтобы он смог бегать по новой платформе).

Вечно тороплюсь и опечатываюсь

Здравствуйте, Oyster.

По поводу многоножки-C++ согласен.

Вы писали:

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

O>[... skipped ...]

O>>>PS: в общем-то, я к тому, что серебрянной пули нет...

FDS>>Я предлагаю сравнивать любые языки и даже среды программирования. Ада была как пример. Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

O>Не такое уж и старое. Оберон — это наследник Паскаля (и Модулы-2, соответственно).

Извини, я не знал.

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

Насчёт задачи, я в плане того, что Java не Ag пуля. Согласен.

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

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

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

[... skipped ...]

FDS>Насчёт задачи, я в плане того, что Java не Ag пуля. Согласен.

FDS>Я не предлагаю искать с.п. Ведь удачный при проектировании языка подход может быть применён к языкам других отраслей.

FDS>Смысл сравнения найти новую идею и улучшить текущие языки. У них ведь нет, например, поддержки автоматической проверки ошибок — приходится писать ещё и языки, которые декларируют правила написания кода, а затем код на таких языках используют системы проверки — не удобно, да и системы проверки не так уж и распространены.

Эволюция языков и так происходит. Посмотри на широко применяемые индустриальные языки (C++, Java, C#) — и увидишь то, что прижилось. Излишне нагружать язык "синтаксическим сахаром" (для проверок валидности на этапе компиляции, например) тоже не есть хорошо (потому как листинги становятся более ... запутанными, что ли, и продуктивность программиста падает), поэтому в индустриальных языках прижились только действительно необходимые фичи.

Что же касательно уменьшения стоимости разработки — так работы ведутся (причём ведутся постоянно). Неизвестно только, что попадёт в индустриальные языки следующего поколения. Тем не менее, можно поюзать Google и найти несколько интересностей: например, Spec# (это касательно compile-time assert) или Comega (асинхронные методы, элементы ФП, ...).

PS: сорри что оба примера из .NET — что знал...

DEA>· use of "/=" for "!="
DEA> Гм... А в каком это языке "не равно" пишется как "/="?

Как минимум в Erlang.

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

FDS>Эти ребята очень неплохо знают C++,
FDS>просто 1995 статья написана.
Обоснуй! Из статьи видно полностью противоположное.

Раз:

We do not yet have a large mix of people programming in both C++ and Ada for similar difficulty programs and with history as released products

Сами признаются что опыта — йок.

Два:

Our theoretical views of our C++ problems indicate that C++ may allow "run-away inheritance", where many very similar classes are created from a substrate without care to design a smaller number of re-usable classes without many variants;

Жалобы на то что C++ "много позволяет". Если им мама в детсве не вбила в бошку что не все что позволено можно делать... Клиника.

Три:

existing C++ programs have not yet made good use of templates and so have become cluttered with "container classes" and attendant conversions;

Звиздеж чистейшей воды. Я юзал шаблоны (BIDS) в Borland C++ 3.1 начиная с 1992-го года. В 1994-м вышел HP STL.

Четыре (всем рыдать):

finally, so much of C++ goes unseen, hidden behind the notational convenience of the language, that the code can become difficult to understand and navigate.

А это вообще перл: жалуются что на C++ трудно программировать потому что на нем удобно писать! Что из-за этого трудно разобраться в коде!

Короче, мозги у них под Аду заточены и ничего кроме своей распрекрасной Ады они видеть не хотят.

FDS>Мне, кажется, что от языка всё-таки очень много зависит;
Зависит.
Но данная статья нерепрезентативна тк в одном из сравниваемых языков (C) авторы явно некомпетентны — их "стандарт кодирования" для C — явный билет на газенваген.

Мне кажется старались перенести модель программирования ADA на C и у них это не получилось. Крайне бы удивился случись наоборот.

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

O>Что же касательно уменьшения стоимости разработки — так работы ведутся (причём ведутся постоянно). Неизвестно только, что попадёт в индустриальные языки следующего поколения. Тем не менее, можно поюзать Google и найти несколько интересностей: например, Spec# (это касательно compile-time assert) или Comega (асинхронные методы, элементы ФП, ...).

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

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

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

Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

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

FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

FDS>Насколько буквально это понимать и почему C++ более распространён чем АДА? Переходим на АДА???

FDS>Можно ли разработать ещё более экономичные языки?

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

FDSC wrote:

> C>Скорее всего они:
> C>1. Использовали малоопытных С++ников.
> C>2. Использовали древнюю (даже для 1994г.) версию С++.
> C>3. Пункты 2 и 1 вместе взятые.
> Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по
> моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в
> программировании на C++ чего-то??? (я сам прогр. Delphi / assembler,
> C++ только правлю и дополняю, и то не очень часто).

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

Претензии к библиотеке контейнеров — тоже к себе пусть предъявляют.
Сейчас есть стандартная STL.

> В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).

Смысла нет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

FDS> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

Я описался, хотел сказать, что С они знают неплохо

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

Я например, кодга с C# знакомился, никак не мог отвыкнуть от привычек проектирования на Delphi. Принципы очень похожие, а реализация разная. В частности, слишком много надо вложенных классов в C# делать и нельзя — вложенные функции. Так я на Delphi в итоге и остался (C# по работе не нужен).

(это я на жизнь жалуюсь).

Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

ANS>Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

Это уже философия не программирования. Вообще, пока по таким принципам большинство будет жить плохо нам будет.

Нужно проявлять активность. По моему опыту, пользователь всё-таки очень много полезных вещей знает. Очень много, только вынуть из него тяжело.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

ANS>Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

А может, большинство не хочет изобретать молотовелосипед?

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

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

Ада довольно распространённый язык, в своих сферах.

Я как раз и хочу получить мнение коллег по поводу статистической информации. У меня в фирме всё просто — интерфейс Delphi, микроконтроллер — assembler, и можно не думать. Просто захотелось своё написать (ну, так в течении ближайших 20 лет

).

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

C>FDSC wrote:

>> C>Скорее всего они:
>> C>1. Использовали малоопытных С++ников.
>> C>2. Использовали древнюю (даже для 1994г.) версию С++.
>> C>3. Пункты 2 и 1 вместе взятые.
>> Да, по поводу IDE они что-то странное написали. А вообще фрагмент, по
>> моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в
>> программировании на C++ чего-то??? (я сам прогр. Delphi / assembler,
>> C++ только правлю и дополняю, и то не очень часто).

C>В чем в С++ проблема с runaway inheritance я не понимаю (вообще в первый
C>раз такой термин слышу), больше похоже, что их местные программисты
C>чего-то не так задизайнили.

C>Претензии к библиотеке контейнеров — тоже к себе пусть предъявляют.
C>Сейчас есть стандартная STL.

>> В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).

C>Смысла нет.

Не понял по чему. Потому что мы — не разработчики компиляторов?? Давай станем

FDSC wrote:

> C>Претензии к библиотеке контейнеров — тоже к себе пусть предъявляют.
> C>Сейчас есть стандартная STL.
>>> В любом случае я предлагаю сравнивать любые языки (хоть алгол-60).
> C>Смысла нет.
> Не понял по чему. Потому что мы — не разработчики компиляторов?? Давай
> станем

Какие проблемы? Берешь GCC и пишешь к нему фронтенд для своего языка.
Получится компилируемый в маш. коды язык. Я так делал, кстати, без
особых трудностей.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

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

Извини, что такое GCC?

Сначало надо знать, что этой за зверь — свой язык, а потом уже писать что-то. Я уже 3 года со знакомыми программистами общаюсь, у каждого своё мнение по поводу удобств языков и IDE.

Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки. Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.
Может это смешно делать, кодга половину всего этого сделала Microsoft (пусть даже не всё для других), но мне надоело писать на том, что не нравится, а MS никогда нормальный компилятор с моей точки зрения не выпустит. Можно конечно в NASA устроиться...

.

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

FDS>Здравствуйте, Andrei N.Sobchuck, Вы писали:

FDS>>> Мне интересны мнения не профессиональных исследователей, а того, кто на форуме. По моему они лучше могут понимать что надо делать.

ANS>>Почему? Мне кажется, что большинство живёт так: дали камень, значит нужно чуток камень заполировать, чтоб ровная поверхность была, и гвозди камнем можно было забивать; дали молоток — забивают молотком; дали пневматический молоток — круто, работает пневмомолотком. Но я сомневаюсь, что этот гвоздезабиватель способен придумать (а это именно то, чего ты хочеш) обычный молоток, я уже молчу о пневмо. Максимум это заполировать камень.

FDS>Это уже философия не программирования.

Группа соответсвует

FDS>Вообще, пока по таким принципам большинство будет жить плохо нам будет.

Инноваций то очень мало в языках программирования. О чем это говорит?

FDS>Нужно проявлять активность. По моему опыту, пользователь всё-таки очень много полезных вещей знает. Очень много, только вынуть из него тяжело.

Это легко проверить. Вот ты пользователь компиляторы. Возьми и расскажи чего бы ты хотел /улучшить/.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

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

O>А может, большинство не хочет изобретать молотовелосипед?
Чтобы появился 'ферари', нужно было чтобы кто-то изобрёл мотовелосипед, а история-таки предпочитает двигаться по спирали.

FDSC wrote:

> C>Какие проблемы? Берешь GCC и пишешь к нему фронтенд для своего языка.
> C>Получится компилируемый в маш. коды язык. Я так делал, кстати, без
> C>особых трудностей.
> Извини, что такое GCC?

GNU Compiler Collection (http://www.gcc.org/).

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

Кхм. Это должен быть не IDE, а язык.

> Может это смешно делать, кодга половину всего этого сделала Microsoft
> (пусть даже не всё для других), но мне надоело писать на том, что не
> нравится, а MS никогда нормальный компилятор с моей точки зрения не
> выпустит. Можно конечно в NASA устроиться... .

MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и расскажи чего бы ты хотел /улучшить/.

Отвечаю.

1. IDE снабжается системой создания автоматизированных заглушек для ещё ненаписанного кода. Это возможно:
1.1. Программист делает пометки несозданных функций в созданном коде — компилятор автоматически делает шаблон (это легко, можно сделать и как надстройку)
1.2. Компилятор рассматривает код, находя функции, выход которых не является корректным (т.е. объект разрушаеся или не создаётся, или т.п.). Далее идёт создание пустых шаблонов объектов, исходя из формальной безошибочности работы следующих функций.

2. IDE снабжается возможностью проектирования процесса разработки ПО: т.е. помагает программисту выявить последовательность разработки методов и классов приложения с учётом применения итеративной разработки.

3. IDE позволяет задавать граф возможных и запретных последовательностей вызовов методов (инциализация -> применение, create -> Init -> загрузка из сети данных пользователя -> .. но не наоборот ). Идёт контроль за обнулением инициализированных полей. Поля объекта можно делать константными в пределах блока кода (или наоборот, изменяемыми)

4. IDE реализует сам код, как граф. Названия методов даются как справочная информация для программиста, могут меняться автоматически. Различные участки графа кода могут быть использованы вне пределов функции, наподобие шаблонов С (только при этом речь идёт не о безразлии к классам, а о общем порядке следования команд в алгоритме для однотипных объектов). Например, метод-шаблон, позволяющий работать со всеми элементами некоторого сложного объекта-коллекции по очереди без явных циклов и т.п. (т.е. задаётся код работы с элементом и говорится, что выполнять для всех элементов, однако объект может быть любой сложности [какое-нибудь ВВ-дерево]). (не уверен, что могу сделать)

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

5. Конкретный синтаксис языка определяет программист. Основа языка позволяет писать классы и функции (в т.ч. вложенные), а использование тех или иных обозначений (возможно, математических) зависит от области работы компонента. В том числе речь идёт о сокрытии непосредственной объектно-функциональной структуры языка -> записывается сам алгоритм (не знаю как это сделать).

6. Библиотеки позволяют работать с приватными методами и полями в отдельных заявленных функциях других классов (а не во всём классе). (см. так же 3).

7. Компилятор позволяет работать низкоуровнево без использования ассемблера и с гарантией совместимости низкого кода с высоким (речь идёт об ограничении применения регистров CPU и т.п. в пределах работы низкого кода. Ограничениях для компилятора, а не для программиста).

Главное, это 4 и 5. Если я конечно смог правильно объяснить, что хочу. Это не всё. Что вспомнил.

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

C>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.

Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не используют такие компиляторы, или используют их с существенными надстройками.

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

FDSC wrote:

> C>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.
> Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не
> используют такие компиляторы, или используют их с существенными
> надстройками.

Ха. Вы думаете Microsoft не использует собственный компилятор?

А в NASA используют GCC, или родной VxWorks'овский.

> Компиляторы приличные, да вот нехватает их возможностей. (см. выше
> написал сообщение с заголовком "Предложения по улучшению"). Не приятно
> на них программировать (если конечно сроки поставлены и начинаешь
> нервничать).

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

FDSC wrote:

> ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и
> расскажи чего бы ты хотел /улучшить/.
> /*Отвечаю.*/
> 1. IDE снабжается системой создания автоматизированных заглушек для
> ещё ненаписанного кода. Это возможно:
> 1.1. Программист делает пометки несозданных функций в созданном коде —
> компилятор автоматически делает шаблон (это легко, можно сделать и как
> надстройку)

Смотри IDEA (http://www.intellij.com/) или Eclipse
(http://www.eclipse.org) — там это есть уже много лет.

> 1.2. Компилятор рассматривает код, находя функции, выход которых не
> является корректным (т.е. объект разрушаеся или не создаётся, или
> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
> формальной безошибочности работы следующих функций.

Бессмысленно. Просто нужно разработать нормальную семантику
использования объектов (как в С++) или использовать GC и не иметь таких
проблем вообще.

> 2. IDE снабжается возможностью проектирования процесса разработки ПО:
> т.е. помагает программисту выявить последовательность разработки
> методов и классов приложения с учётом применения итеративной разработки.

Рефакторинг в IDEA, Eclipse, Reshaper.

> 3. IDE позволяет задавать граф возможных и запретных
> последовательностей вызовов методов (инциализация -> применение,
> create -> Init -> загрузка из сети данных пользователя -> .. но не
> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
> объекта можно делать константными в пределах блока кода (или наоборот,
> изменяемыми)

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

> 4. IDE реализует сам код, как граф. Названия методов даются как
> справочная информация для программиста, могут меняться автоматически.

Было такое в Together и Rational Rose — успешно провалилось как
неудобное и неюзабельное решение.

> 5. Конкретный синтаксис языка определяет программист. Основа языка
> позволяет писать классы и функции (в т.ч. вложенные), а использование
> тех или иных обозначений (возможно, математических) зависит от области
> работы компонента. В том числе речь идёт о сокрытии непосредственной
> объектно-функциональной структуры языка -> записывается сам алгоритм
> (не знаю как это сделать).

Это в область DSL — сейчас она развивается достаточно активно.

> 6. Библиотеки позволяют работать с приватными методами и полями в
> отдельных заявленных функциях других классов (а не во всём классе).
> (см. так же 3).

А смысл?

> 7. Компилятор позволяет работать низкоуровнево без использования
> ассемблера и с гарантией совместимости низкого кода с высоким (речь
> идёт об ограничении применения регистров CPU и т.п. в пределах работы
> низкого кода. Ограничениях для компилятора, а не для программиста).

А нафиг??

Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и
OCaml) — многие вопросы отпадут сами.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

FDS>Слышал, что при написании программ на C++ количество допущенных ошибок на порядок больше, чем при написании их же в "АДА", стоимость выше на 60% и т.п. (см. http://www.adaic.com/whyada/ada-vs-c/cada_art.html).

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

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

FDS>Насколько буквально это понимать

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

FDS> и почему C++ более распространён чем АДА? Переходим на АДА???

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

FDS>Можно ли разработать ещё более экономичные языки?

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

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

Если говорить о том как это достигается, то все очень просто. С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение). Если требования гибкости заставляют отложить проверки до времени выполнения, то проверки перекладываются на рантайм. Тут безусловные видеры управляемые среды и скриптовые языки. Их рантаймы контролируют все действия во время работы программы. Например, в С++ можно легко привести любой блок памяти к любому (даже не совместимому) типу. Это может легко привратиться в ошибку. Уравляемые же среды и скритовые языки недопускают пдобного или требуют специальной декларации своих намерений в виде пометки части кода как небезопастного (в таких участках возможны такие же ошибки как и в С++-коде).

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

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

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

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

FDS>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

Проблема в том, что нельзя взять миллион обезьян и заставить написать их сложный софт. К тому же есть очень отвественные задачи в которых стоимость ошибки очень велика. Тут защищенные языки и рантаймы позволяют понизить вероятность ошибки и стало быть снизить риски и стоимость. Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

FDS>>http://www.adaic.com/whyada/ada-vs-c/cada_art.html.
DEA>Прочитал. КГ/АМ.

Здесь за кг/ам в отправляют баню. Так что рекомендую воздержаться от проявлений падонковских сокращений.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

C>FDSC wrote:

>> C>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.
>> Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не
>> используют такие компиляторы, или используют их с существенными
>> надстройками.

C>Ха. Вы думаете Microsoft не использует собственный компилятор?

Я сказал не использует, или с надстройками.

C>А в NASA используют GCC, или родной VxWorks'овский.
Откуда такие сведения?
В NASA вообще на данный момент используют автоматическую генерацию кода (90-97% автоматически).

>> Компиляторы приличные, да вот нехватает их возможностей. (см. выше
>> написал сообщение с заголовком "Предложения по улучшению"). Не приятно
>> на них программировать (если конечно сроки поставлены и начинаешь
>> нервничать).

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

Под компилятором в данном случае я подразумевал не только IDE, но и весь пакет программ Visual Studio или Delphi Studio.

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

C>FDSC wrote:

>> ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и
>> расскажи чего бы ты хотел /улучшить/.
>> /*Отвечаю.*/
>> 1. IDE снабжается системой создания автоматизированных заглушек для
>> ещё ненаписанного кода. Это возможно:
>> 1.1. Программист делает пометки несозданных функций в созданном коде —
>> компилятор автоматически делает шаблон (это легко, можно сделать и как
>> надстройку)

C>Смотри IDEA (http://www.intellij.com/) или Eclipse
C>(http://www.eclipse.org) — там это есть уже много лет.

насчёт IDEA не знаю, а то что легко я и написал из-за Eclipse.

>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>> является корректным (т.е. объект разрушаеся или не создаётся, или
>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>> формальной безошибочности работы следующих функций.

C>Бессмысленно. Просто нужно разработать нормальную семантику
C>использования объектов (как в С++) или использовать GC и не иметь таких
C>проблем вообще.

Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и частичная отладка всего проекта без них.

>> 2. IDE снабжается возможностью проектирования процесса разработки ПО:
>> т.е. помагает программисту выявить последовательность разработки
>> методов и классов приложения с учётом применения итеративной разработки.

C>Рефакторинг в IDEA, Eclipse, Reshaper.

Жаль, не знаю. Спасибо, посмотрю (меня этому не учили, немного не та область).

>> 3. IDE позволяет задавать граф возможных и запретных
>> последовательностей вызовов методов (инциализация -> применение,
>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>> объекта можно делать константными в пределах блока кода (или наоборот,
>> изменяемыми)

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

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

Что значит "обходится грамотным проектированием"? Создавать полные графы естественно не нужно.
Часто встречаю ошибки типа: пользователь не инициализировал переменную и пытается с ней работать, связывается с микроконтроллером и пошёл (и не только это). Много проблем возникает из-за этого. А самому проверять нудно и трудно. Вот уж "обходится грамотным проектированием", наоборот, проектировать и проверять легче.

>> 4. IDE реализует сам код, как граф. Названия методов даются как
>> справочная информация для программиста, могут меняться автоматически.

C>Было такое в Together и Rational Rose — успешно провалилось как
C>неудобное и неюзабельное решение.

Не знаю Together, но в Rational Rose такого не было никогда. RR не позволял писать полномасштабный код как граф, среда вообще предназначена для UML-проектирования.

Между прочим, лично знаю людей, которые используют эти продукты.

Кстати, я ещё писал: "Код отбражается как граф, дерево или ещё что-нибудь удобное". А как же давнишние '+', позволяющие свернуть функции в MS VS.

Кстати в этом направлении сейчас есть движение — в частности, для UML-спроектированного приложения создаётся шаблон кода. Я, в том числе, и это имел ввиду.

>> 5. Конкретный синтаксис языка определяет программист. Основа языка
>> позволяет писать классы и функции (в т.ч. вложенные), а использование
>> тех или иных обозначений (возможно, математических) зависит от области
>> работы компонента. В том числе речь идёт о сокрытии непосредственной
>> объектно-функциональной структуры языка -> записывается сам алгоритм
>> (не знаю как это сделать).

C>Это в область DSL — сейчас она развивается достаточно активно.

Где почитать, подскажи!!!

>> 6. Библиотеки позволяют работать с приватными методами и полями в
>> отдельных заявленных функциях других классов (а не во всём классе).
>> (см. так же 3).

C>А смысл?

Смысл простой. В Delphi, например, вообще нельзя работать из другого класса с private-членами. Protected — только в текущем модуле. Допустим я хочу поправить (дополнить) чужой класс (в любом языке), зачем мне делать доступными приватные члены для всех методов, когда мне нужен, возможно, только один? Зря возможность ошибочного вызова делать.

>> 7. Компилятор позволяет работать низкоуровнево без использования
>> ассемблера и с гарантией совместимости низкого кода с высоким (речь
>> идёт об ограничении применения регистров CPU и т.п. в пределах работы
>> низкого кода. Ограничениях для компилятора, а не для программиста).

C>А нафиг??

Мне, например, надобилось.

Привожу примеры:
Один алгорит с 7 вложенными циклами Delphi компилирует так, что переписанный на asm работает в 7,5 раза быстрей, но при смене проекта всё заново писать приходиться. Муторно.

В RSDN непомню кто, писал про обёртку для вызова функций из внешний DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на количество аргументов. Я видел решение его задачи на Delphi 2-мя функциями (с использованием asm). По моему так гораздо лучше.

C>Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и
C>OCaml) — многие вопросы отпадут сами.

Я знаю нормально Dlephi, C++, assembler. Кстати, Java не так уж и отличается от C++ (программировал я на ней чуть-чуть, правда Eclipse сильно отличается от того, что мне приходилось видеть).

OCaml — никогда не слышал!!! Что это?

Выходит, Вас устраивают существующие компиляторы?

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

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

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

Не согласен. Приложения для систем управления на ней часто пишут. Защита, хорошо, а по поводу поддрежки многопоточности?
Кстати, что бы не быть голословным: Ада используется фирмой BEA.

VD>Буквально и понимать. С++ имеет море возможностей приводящих к скрытию ошибок и к ошибкам второго порядка (наложенным... портишь память в одном месте, а программа падает в другом).

Спасибо, понял.

FDS>> и почему C++ более распространён чем АДА? Переходим на АДА???

VD>Ада это мертворожденное дитя. Она может и более надежна, но это откровенно тяжеловестный и неудобный язык программирования. С++ же является приемником С и на него переходила целая толпа С-шников которые хотели получить ОО-возможности.

Незнаю, вообще, Ада-программисты говорят, что она хорошо читается. Хотя я думая иначе. Наверное это зависит от опыта программирования на Ада.

FDS>>Можно ли разработать ещё более экономичные языки?

VD>А причем тут экономичность? Речь же шала о надежности и безопастности. Да и экономить можно разные. Можно экономить память, можно время программиста, а можно количество символов в исходном файле.

Речь шла не только о надёжности, но и о времени и стоимости проектирования.

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

Видимо, это зависит от квалификации. Я слышал и другие мнения.

VD>Если говорить о том как это достигается, то все очень просто. С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение). Если требования гибкости заставляют отложить проверки до времени выполнения, то проверки перекладываются на рантайм. Тут безусловные видеры управляемые среды и скриптовые языки. Их рантаймы контролируют все действия во время работы программы. Например, в С++ можно легко привести любой блок памяти к любому (даже не совместимому) типу. Это может легко привратиться в ошибку. Уравляемые же среды и скритовые языки недопускают пдобного или требуют специальной декларации своих намерений в виде пометки части кода как небезопастного (в таких участках возможны такие же ошибки как и в С++-коде).

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

VD>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение).

А можно допустить ошибки без запуска программы?? Синтаксические что-ли?

Я не понял, поясните пожалуйста.

Простите, если несколько узко образован.

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

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

FDS>>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).

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

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

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

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

Я думаю это связано больше с ошибками проектирования и уверенностью в себе.

FDS>>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?

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

Ну, получается, что если Ада такая нечитаемая и вообще, мертворождённая, то программисты должны стоить дорого и проект то же. Я и спрашиваю: как так?

VD>Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.

Всяко бывает.

По моему мы несколько ушли от темы.

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

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

Искать их не по статистике сложнее. А потому что просто ошибки более опытных людей более сложны по своей сути. Ну, глупо ошибаться если задача пустяк. Просто любой разум имеет придел. И если для опытного разума это просо ошибка, то для менее опытного это жуткий ребус. Короче опытный программист с трудом находит свои мудренные ошибки, а менее опытный свои более простые. Но востприятие ошибок практически одинаковое. До их обнаружения они не понятны и не объяснимы.

FDS>Я думаю это связано больше с ошибками проектирования и уверенностью в себе.

Возможно. Весма возможно.

FDS>Ну, получается, что если Ада такая нечитаемая и вообще, мертворождённая, то программисты должны стоить дорого и проект то же. Я и спрашиваю: как так?

Ада и стоит не мало. На столько не мало, что по сравнению с менее одиозными языками вроде Шарпа или Явы еще бабушка на двое скажет что дешевле. Но по сравнению с С++ кое что есть. Все же Ада позволяет с высокой долей увереннсоти говорить о корректности. А С++ — это надежда на крутость программиста и вера в проведение.

VD>>Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.

FDS>Всяко бывает.

FDS>По моему мы несколько ушли от темы.

Да, нет. Это все к вопросу о цене ошибки. Если одна ошибка стоит миллионы долларов. То применение С++ в таких проектах — это по хлеще чем топка помещений ассигнациями.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>Не согласен. Приложения для систем управления на ней часто пишут.

Часто? А где статистика?

FDS> Защита, хорошо, а по поводу поддрежки многопоточности?

Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.

FDS>Кстати, что бы не быть голословным: Ада используется фирмой BEA.

Это что тукседо пишут?

FDS>Незнаю, вообще, Ада-программисты говорят, что она хорошо читается. Хотя я думая иначе. Наверное это зависит от опыта программирования на Ада.

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

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

FDS>Речь шла не только о надёжности, но и о времени и стоимости проектирования.

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

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

FDS>Видимо, это зависит от квалификации. Я слышал и другие мнения.

Все в этой жизни зависит от квалификации. А мнений бывает очень много. Причем большинство из них диамитрально-противоположенные.

FDS>Об этом много пишут в учебниках, однако я таких ошибок никогда не встречал (видать простые программы были). По моему ошибки обычно больше логического характера возникают. Очень спорный вопрос.

Ну, если ты не встречал такие ошибки, то с вероятностью в 99% ты просто имешь малый опыт. Ну, или ты крут как вареные яйца.

У тех же парней из МС или тех что делают Линуксы и т.п. подобных проблем хоть отбавляй. От банальных AV, до переполнений буферов. В общем игра в усидчивость на гигабайтах кода.

FDS>Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).

Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.

VD>>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение).

FDS>А можно допустить ошибки без запуска программы??

Легко. Чем больше контроль компилятора. И чем более грамотно проектируется ПО, тем больше ошибок вылавливается еще до стадии отладки.

FDS> Синтаксические что-ли?

Я не понял, поясните пожалуйста.

Синтаксис, семантика. Это очень не мало. Если ты умешь грамотно формулировать мысли, то семантический контроль позволяет отлавливать очень много ошибок.

Прстой пример из недавнего опыта. Представь себе редактор у которого есть представление данных в документе, и представление данных во View. И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор. Другими словами грамотное проектирование переносит отвественность за качество на безошибочный компилятор. Так что даже на не супер идельном ЯП можно существенно улучшить защищенность программы, а стало быть уменьшить время затрачиваемое на отладку, и ускорить поизводство ПО. А есди сам язык и рантайм помогают тебе держать типы в целости и сохранности, твоя задача существенно упрощается.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>Извини, что такое GCC?

GCC — это С++-компилятор созданный на базе открытого фронтэнда ГНУ.

FDS>Сначало надо знать, что этой за зверь — свой язык, а потом уже писать что-то. Я уже 3 года со знакомыми программистами общаюсь, у каждого своё мнение по поводу удобств языков и IDE.

Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.

FDS>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

А как сейчас где?

FDS> Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.

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

FDS>Может это смешно делать, кодга половину всего этого сделала Microsoft (пусть даже не всё для других), но мне надоело писать на том, что не нравится, а MS никогда нормальный компилятор с моей точки зрения не выпустит. Можно конечно в NASA устроиться...

.

Нда. Ты еще и пары компиляторов МС не видел, а уже судишь и столь котигорично. Поверь на слово. МС один из лидеров в компиляторостроении. Есть конечно и другие лидеры. У них есть достойные продукты. Но компиляторы МС — это очень и очень достойные родукты.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

C>>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.

FDS>Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не используют такие компиляторы, или используют их с существенными надстройками.

Да? Ну, насса использует черта лысого. С ним отдельно. А на чем по-твоему пишутся продукты МС? И какие-такие надстройки используют в МС?

FDS>Компиляторы приличные, да вот нехватает их возможностей. (см. выше написал сообщение с заголовком "Предложения по улучшению"). Не приятно на них программировать (если конечно сроки поставлены и начинаешь нервничать).

Ты бы луче ссылку дал.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>Под компилятором в данном случае я подразумевал не только IDE, но и весь пакет программ Visual Studio или Delphi Studio.

Завязывай ты с Дельфи. А то не равен час под компилятором начнешь понимать редактор кода и комплит-ворд.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

FDSC wrote:

> C>Ха. Вы думаете Microsoft не использует собственный компилятор?
> Я сказал не использует, или с *надстройками*.

Не используют они никаких настроек. Вся Винда сейчас у них компилируется
на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.

> C>А в NASA используют GCC, или родной VxWorks'овский.
> Откуда такие сведения?

http://www.windriver.com/ Кроме того, сами насовцы достаточно много
писали о Роверах и спутниках.

> В NASA вообще на данный момент используют автоматическую генерацию
> кода (90-97% автоматически).

С чего бы это? Чтобы код генерировать нужно иметь:
1. Генератор
2. Шаблоны

Отладка обоих может быть намного дороже написания кода вручную.

> C>Часть возможностей просто не нужна для нормального языка, а другая
> часть
> C>должна быть в IDE, а не компиляторе.
> Под компилятором в данном случае я подразумевал не только IDE, но и
> весь пакет программ Visual Studio или Delphi Studio.

А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
данного языка и IDE для данного языка.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

FDSC wrote:

> VD>Ада давно устарела. Ява, Шарп, Васик (и другие управляемые языки),
> а так же некоторые типизированные функциональные языки обеспечивают не
> меньшую чем в Аде защиту при этом являсь полноценными и современными ООЯ.
> Не согласен. Приложения для систем управления на ней часто пишут.
> Защита, хорошо, а по поводу поддрежки *многопоточности*?

Давно уже есть везде. А что в этом такого суперэкзотичного?

Есть еще и специализированые решения для очень многопоточных приложений:
ACE (Adaptive Communication Environment), язык Erlang и т.п.

> Кстати, что бы не быть голословным: Ада используется фирмой BEA.

BEA сейчас в основном продает WebLogic, написаный на Java.

> VD>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до
> запуска программы на исполнение).
> А можно допустить ошибки без запуска программы?? Синтаксические
> что-ли? Я не понял, поясните пожалуйста.

Естественно

Все ошибки в программе закладываются во время ее
написания. Задача компилятора — помочь их выловить еще на этапе компиляции.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

>> 4. IDE реализует сам код, как граф. Названия методов даются как
>> справочная информация для программиста, могут меняться автоматически.

C>Было такое в Together и Rational Rose — успешно провалилось как
C>неудобное и неюзабельное решение.

очень интересно. а можно подробнее?

FDSC wrote:

>>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>>> является корректным (т.е. объект разрушаеся или не создаётся, или
>>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>>> формальной безошибочности работы следующих функций.
> C>Бессмысленно. Просто нужно разработать нормальную семантику
> C>использования объектов (как в С++) или использовать GC и не иметь таких
> C>проблем вообще.
> Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и
> частичная отладка всего проекта без них.

Это я про деструкторы — в нормальных языках они вызываются почти всегда
автоматически, а в других языках деструкторов нет вообще. Простейшие
ошибки типа _возможного_ обращения по нулевому указателю давно умеют
отслеживать статические верефикаторы в C#/Java.

>>> 3. IDE позволяет задавать граф возможных и запретных
>>> последовательностей вызовов методов (инциализация -> применение,
>>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>>> объекта можно делать константными в пределах блока кода (или наоборот,
>>> изменяемыми)
> C>Нафиг такое не нужно, так как это принципиально невозможно проверить в
> C>общем случае и, вдобавок, обходится грамотным проектированием.
> Не понял, что нельзя проверить в общем случае?

Что последовательность вызовов будет нужно.

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

Принципиально нельзя построить статический граф вызовов методов с
временными метками (могу даже доказательство привести).

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

Смотри С++, а именно идиому RAII — Resource Acquisition Is
Initialization и smart pointer'ы. То есть для работы с микроконтроллером
нужно взять на него хэндл, в конструкторе которого производится нужная
предварительная инициализация.

> C>Было такое в Together и Rational Rose — успешно провалилось как
> C>неудобное и неюзабельное решение.
> Не знаю Together, но в Rational Rose такого не было никогда. RR не
> позволял писать полномасштабный код как граф, среда вообще
> предназначена для UML-проектирования.

Позволяет, причем в RR можно писать полностью весь код. Году в 2000 я
пробовал применить это на практике сначала на RR, потом на Together.
Результат такой — уж проще руками все писать.

> Кстати в этом направлении сейчас есть движение — в частности, для
> UML-спроектированного приложения создаётся шаблон кода. Я, в том
> числе, и это имел ввиду.

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

> C>Это в область DSL — сейчас она развивается достаточно активно.
> Где почитать, подскажи!!!

Отсюда http://en.wikipedia.org/wiki/Domain-specific_language и по ссылкам.

> C>А смысл?
> Смысл простой. В Delphi, например, вообще нельзя работать из другого
> класса с private-членами. Protected — только в текущем модуле.
> Допустим я хочу поправить (дополнить) чужой класс (в любом языке),
> зачем мне делать доступными приватные члены для всех методов, когда
> мне нужен, возможно, только один? Зря возможность ошибочного вызова
> делать.

В С++ есть механизм friend'ов, который позволяет открыть приватные члены
для избранных классов или функций. Хотя необходимость использования
такого механизма показывает на неправильное проектирование — другой
класс не должен лезть в приватные данные класса.

> C>А нафиг??
> Мне, например, надобилось.
> Привожу примеры:
> Один алгорит с 7 вложенными циклами Delphi компилирует так, что
> переписанный на asm работает в 7,5 раза быстрей, но при смене проекта
> всё заново писать приходиться. Муторно.

И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
ассемблером, а потом линкуйте в проект.

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

> В RSDN непомню кто, писал про обёртку для вызова функций из внешний
> DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на
> количество аргументов. Я видел решение его задачи на Delphi 2-мя
> функциями (с использованием asm). По моему так гораздо лучше.

В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего
требовалось что-то другое (типа делегатов или хука).

> C>Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и
> C>OCaml) — многие вопросы отпадут сами.
> Я знаю нормально Dlephi, C++, assembler. Кстати, Java не так уж и
> отличается от C++ (программировал я на ней чуть-чуть, правда Eclipse
> сильно отличается от того, что мне приходилось видеть).
> OCaml — никогда не слышал!!! Что это?

Функциональный язык, достаточно популярный: http://www.ocaml.org

> Выходит, Вас устраивают существующие компиляторы?

Да. Естественно, место для улучшений есть, но ничего принципиально
нового не хочется.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Дарней wrote:

>>> 4. IDE реализует сам код, как граф. Названия методов даются как
>>> справочная информация для программиста, могут меняться автоматически.
> C>Было такое в Together и Rational Rose — успешно провалилось как
> C>неудобное и неюзабельное решение.
> очень интересно. а можно подробнее?

А чего особого? Рисовалась диаграмма классов, к методам делались
аннотации в виде их кода (можно еще было их генерировать из диаграммы
состояний). Работало все криво и неудобно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

VD>Завязывай ты с Дельфи. А то не равен час под компилятором начнешь понимать редактор кода и комплит-ворд.

Не могу, работа такая

Может, посветуете что-нибудь то же (для изучения).

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

VD>Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.

Согласен. Только не знаю, кто законодатель.

FDS>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

VD>А как сейчас где?

Не понял. Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему. По поводу средств проверок, согласен, хранятся отдельно.

FDS>> Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.

VD>Открою тебе сикрет. В передовых на сегодня технологиях уже давно отказываются от самого понятия деструктора. А ручной вызов уже давно считается чем-то не приличным.

Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

VD>Нда. Ты еще и пары компиляторов МС не видел, а уже судишь и столь котигорично. Поверь на слово. МС один из лидеров в компиляторостроении. Есть конечно и другие лидеры. У них есть достойные продукты. Но компиляторы МС — это очень и очень достойные родукты.

Как раз два компилятора я видел: MS VS 6 Standard Architect и MS VS .NET 2003 EA.
Причём на 6-ой пришлось попрограммиовать. .NET конечно гораздо лучше.

Вы меня убедили... я ничего не знаю

>
>>В RSDN непомню кто, писал про обёртку для вызова функций из внешний
>>DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на
>>количество аргументов. Я видел решение его задачи на Delphi 2-мя
>>функциями (с использованием asm). По моему так гораздо лучше.
>
>
> В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего
> требовалось что-то другое (типа делегатов или хука).
>
Кажется, всё было именно простейшей обёрткой для функции, динамически
находимой по названию.

Posted via RSDN NNTP Server 1.9

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

C>http://www.windriver.com/ Кроме того, сами насовцы достаточно много
C>писали о Роверах и спутниках.

>> В NASA вообще на данный момент используют автоматическую генерацию
>> кода (90-97% автоматически).

C>С чего бы это? Чтобы код генерировать нужно иметь:
C>1. Генератор
C>2. Шаблоны

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

Уже есть. Прочитал перевод статьи "NASA's Mission Reliable", Patrik Regan, Scott Hamilton, IEEE Computer, jan 2004. Впрочем, они не из NASA. Ссылку дать не могу

.

C>А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
C>данного языка и IDE для данного языка.

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

Лучше предложи что-нибудь своё — а я отыграюсь

.

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

C>А чего особого? Рисовалась диаграмма классов, к методам делались
C>аннотации в виде их кода (можно еще было их генерировать из диаграммы
C>состояний). Работало все криво и неудобно.

Это не то, о чём я говорил. Работает это действительно не самым лучшим образом, но скорее от неудачной реализации.

FDSC wrote:

> C>Отладка обоих может быть намного дороже написания кода вручную.
> Уже есть. Прочитал перевод статьи "NASA's Mission Reliable", Patri*c*k
> Regan, Scott Hamilton, IEEE Computer, jan 2004. Впрочем, они не из
> NASA. Ссылку дать не могу .

Вот она: http://www.computer.org/computer/homepage/0104/Regan/

Они используют не генерацию, а автоматическое выделение модели кода, с
последующей формальной верефикацией:

This application proved a few important claims for the technology,
including that it could extract models from source code automatically.

> C>А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
> C>данного языка и IDE для данного языка.
> Различаю, этому меня точно учили. Это была терминологическая
> неточность, виноват, исправлюсь. Однако написать слово "компилятор"
> несколько проще, чем объяснять, что имеешь в виду целый пакет программ
> разработки (который не входит в IDE). В любом случае — уже не по теме.

Однако, это очень большая разница. Тут большинство под словом
"компилятор" все же понимают именно компилятор в отдельности, а среду
разработки+компилятор называют IDE.

> Лучше предложи что-нибудь своё — а я отыграюсь .

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

FDSC wrote:

> C>А чего особого? Рисовалась диаграмма классов, к методам делались
> C>аннотации в виде их кода (можно еще было их генерировать из диаграммы
> C>состояний). Работало все криво и неудобно.
> Это не то, о чём я говорил. Работает это действительно не самым лучшим
> образом, но скорее от неудачной реализации.

За 10 лет развития UML так ничего удачного и не предложили, так что
можно про этот подход забыть. Кстати, до UMLя тоже были попытки
графического представления программ (с тем же результатом).

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

raskin wrote:

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

А шаблоны были взяты из Loki, скорее всего. Тогда ничего удивительного —
в С++ нету динамческой диспетчеризации, а в Дельфи она есть.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

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

FDS>>Не согласен. Приложения для систем управления на ней часто пишут.

VD>Часто? А где статистика?

Нет статистики. Привожу примеры: система управления поездами линии метро Парижского метрополитена; автоматизированная станция документальной связи Мин. Обороны РФ; ПО спускаемого аппарата Beagle 2 европейской станции Mars Express.

FDS>> Защита, хорошо, а по поводу поддрежки многопоточности?

VD>Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.

FDS>>Кстати, что бы не быть голословным: Ада используется фирмой BEA.

VD>Это что, тукседо пишут?

Ошибся с названием фирмы. BAE. Виноват.

FDS>>Об этом много пишут в учебниках, однако я таких ошибок никогда не встречал (видать простые программы были). По моему ошибки обычно больше логического характера возникают. Очень спорный вопрос.

VD>Ну, если ты не встречал такие ошибки, то с вероятностью в 99% ты просто имешь малый опыт. Ну, или ты крут как вареные яйца.

У тех же парней из МС или тех что делают Линуксы и т.п. подобных проблем хоть отбавляй. От банальных AV, до переполнений буферов. В общем игра в усидчивость на гигабайтах кода.

С вероятностью 0.99 я программирую в другой области (ну, опыт, в общем, то же не очень). По поводу переполнений буферов: по моему это как раз к логическим ошибкам на этапе алгоритмизации, и очень серьёзным. AV — это Access Violation? Туда же.

FDS>>Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).

VD>Интересно было бы посмотреть на эту статистику. Я — так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов, ловимые компилятором.

Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.
По поводу ошибок с типами — я стараюсь проектировать всё так, что бы преобразований типов не было вообще (с Вашей точки зения это, я думаю, неправильно).

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

VD>Синтаксис, семантика. Это очень не мало. Если ты умешь грамотно формулировать мысли, то семантический контроль позволяет отлавливать очень много ошибок.

Согласен, особенно Warnings помогают, процентов 50 ошибок отлавливают, причём довольно трудно находимых. Однако не все ошибки.

Ещё чуть-чуть и Вы от меня мокрого места не оставите. Предложите своё. Посмеюсь.

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

C>За 10 лет развития UML так ничего удачного и не предложили, так что
C>можно про этот подход забыть. Кстати, до UMLя тоже были попытки
C>графического представления программ (с тем же результатом).

Не согласен.

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

VD>>Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.

www.embedded.com/story/OEG20021211S0034
Взял остюда пример. По моему Ада вообще не курит. Курят Яву.

Listing 1 An Ada multitasking program

1 with Ada.Text_IO;
2 procedure Tasking_Example is
3 Finished : Boolean := False;
4 pragma Atomic(Finished);
5
6 task Outputter; -- task specification
7
8 task body Outputter is -- task body
9 Count : Integer := 1;
10 begin
11 while not Finished loop
12 Ada.Text_IO.Put_Line(Integer'Image(Count));
13 Count := Count + 1;
14 delay 1.0; -- one second
15 end loop;
16 Ada.Text_IO.Put_Line("Terminating");
17 end Outputter;
18
19 begin
20 delay 20.0; -- twenty seconds
21 Finished := True;
22 end Tasking_Example;

Ладно, убедили: Аду на свалку, мне — подучить языки.

Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.

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

FDSC wrote:

> VD>Часто? А где статистика?
> Нет статистики. Привожу примеры: система управления поездами линии
> метро Парижского метрополитена; автоматизированная станция
> документальной связи Мин. Обороны РФ; ПО спускаемого аппарата Beagle 2
> европейской станции Mars Express.

Beagle 2 лучше было не приводить в пример.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

FDSC wrote:

> VD>>Тут безусловно рулят функциональные языки. А Ада нервно курит.
> Причем по бональным соображениям. В ФЯ легко достигается неблокирующий
> режим работы. Так что контролировать нечего. А учитывая отсуствие
> побочных эффектов у функций распараллеливание становится намного более
> простой задачей.
> www.embedded.com/story/OEG20021211S0034
> <http://www.embedded.com/story/OEG20021211S0034>
> Взял остюда пример. По моему Ада вообще не курит. Курят Яву.
> Listing 1 An Ada multitasking program

Обычная многотредовая программа, на С++/C#/Java будет выглядеть примерно
так же (с точностью до синтаксиса). _Абсолютно_ другой подход к
многопоточности можно посмотреть в языке Erlang
(http://en.wikipedia.org/Erlang):

Pid = spawn(Mod, Func, Args)     % execute function Func as new thread

Pid ! a_message      % send message to the thread (asynchronously)

receive       % receive message sent to this thread
  a_message -> do_something
end.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>За 10 лет развития UML так ничего удачного и не предложили, так что
C>можно про этот подход забыть. Кстати, до UMLя тоже были попытки
C>графического представления программ (с тем же результатом).

Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций

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

VD>Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.

Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.

VD> И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор.

Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

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

T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
В Аде можно

tarkil wrote:
> Здравствуйте, VladD2, Вы писали:
>
> VD>Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.
>
> Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.
>
> VD> И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор.
>
> Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

Вопрос не мне, но всё же: чем не паскалевский древний

type MyType=type OldGoodType;

Для Integer — пойдёт на ура, насколько я помню.
Может быть у fpc это можно заставить корректно работать с объектами

Posted via RSDN NNTP Server 1.9

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

FDS>Может, посветуете что-нибудь то же (для изучения).

Набор стандартный. Для расширения кругозора хорошо изучить:
1. Дотнет/Яву (а лучше обе технологии).
2. Какой-нибудь функциональный язык.
3. С++. Если не доводить его изучение до форм религии, очень помогает.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

C>Не используют они никаких настроек. Вся Винда сейчас у них компилируется
C>на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.

Сдается мне, что на VC6 компилировалась NT 4. А винды компилируются на чем попалао (например, на исследовательских версиях компиляторов). Ну, а релизы винды компилируются на текущем релизе VC. Хотя тут я ничего утверждать не могу. Это только догадки.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

Ну, почему же? Как раз очень даже по теме. Ты видимо интуитивно вышел на верную тему.

Для контроля качества нужно применять некие средства анализа. Эти средства неминуемо потребуют наличия парсера. А парсер — это компонент одинаково необходимый как в компиляторе, так и в любых дополнительных средствах вроде IDE или анализаторе кода. Просто ты для себя смешал эти понятия, а они на самом деле имеют иерархическое отношение.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

VD>>Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.

FDS>Согласен. Только не знаю, кто законодатель.

На сегодня законодатель IDEA. Дальше как не смешно идет MS и Эклипс. И уже потом Борланд. Первенство МС и т.п. еще обсуждается, но IDEA пока что лидер в желотой майке. У конторы ее выпускающей есть отличное расширение для MS VS — ReSharper. С ним VS 2003 становится просто гипер-средой.

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

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

FDS>>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

VD>>А как сейчас где?

FDS>Не понял.

Ну, ты говоришь "действительно разделение, а не как сейчас". Вот и интересно про что ты ведешь речь? Где это "как сейчас"?

FDS> Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему.

Странно. Даже дельфи имееть структурированную обработку исключений. А языки типа Efil имеют так же пред- и пост-условия, ну, и другие фишки. Есть так же плагины для C# превросящие декларативный контроль ошибок в этот язык.

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

FDS>Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>Ошибся с названием фирмы. BAE. Виноват.

А. Ну, первая несколько известнее и как раз все время Яву испоьзует.

FDS>С вероятностью 0.99 я программирую в другой области (ну, опыт, в общем, то же не очень). По поводу переполнений буферов: по моему это как раз к логическим ошибкам на этапе алгоритмизации, и очень серьёзным. AV — это Access Violation? Туда же.

К логическим? Т.е. если я где-то неверно тип привел, то это логическая ошибка? Ну, да, допустим, что для С++ это можно назвать логической ошибкой. Но как обяснить тот факт, что на Яве или C# (в безопастном режиме) таких ошибок вообще невозможно сделать? Вообще!

FDS>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.

Не, ну, все же интересно...

FDS>По поводу ошибок с типами — я стараюсь проектировать всё так, что бы преобразований типов не было вообще (с Вашей точки зения это, я думаю, неправильно).

Не почему же. Это похвальное стремление. Малость максималистское, но все же. Есть все же безопасные приведения типов. Например int -> long или chat -> int. Ну, или любые понижения типов (down cast). При этом гарантированно проблем с типами не будет. Языки типа Явы и Шарпа делают такие приведения автоматически (не требуя явного на то указания). Причем даже если имеет место приведение типов оно контролируется в рантайме. Так что код в котором имеет место ошибка типов никогда не сможет повредить память и привести к появлению ошибок второго порядка (которые ой как не просто выловить).

FDS>Интересно, как я отловлю с помощью преобразования типов ошибку в коде построения сетевого графика, или в численном интегрировании краевой задачи (долго, помню, с ней мучился)?

Контроль типов — это заслуга языка и рантайма. Плюс от программиста требуется проектирование нацеленное на перекладывание контроля типов на компилятор. А задачи то тут в общем-то не причем.

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

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

FDS>Согласен, особенно Warnings помогают, процентов 50 ошибок отлавливают, причём довольно трудно находимых. Однако не все ошибки.

Все это было бы слишком просто.

FDS>Ещё чуть-чуть и Вы от меня мокрого места не оставите. Предложите своё. Посмеюсь.

Ну, что я могу предложить? Разве что вот это http://rsdn.ru/projects/rsharp/article/rsharp_mag.xml. Может будет интересно...

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.

Я такое встречал только в багландовском компиляторе, а он известен тем что в нем очень много ошибок.
Короче не надо говорить про С++ то чего нет.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

Т>В Аде можно

Рыба вобла! А пример кода можно?

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

R>

R>type MyType=type OldGoodType;
R>

Ага, действительно есть такая буква. Забыл.

tarkil wrote:

> VD> И там, и там хронятся строки. Но в первом случае они хранятся
> просто так, а во втором перенесенными на страницу. Так вот если
> хранить их как строка/символ в строке в обоих случаях и не разделять
> тиы, то ошибочно посунув вместо индекса перенесенной линии индекс
> линии из документа ты будешь долго ловить ошибку в отладчие. Если же
> ввести понятие виртуальных и реальных координат, то контроль за
> правильностью действий возмет на себя компилятор.
> Во-во. Влад, может быть ты знаешь языки, в которых можно без написания
> множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке,
> ведёт себя совсем как int, только это совсем другой тип и использовать
> один вместо другого нельзя"? В горячо мною любимом C++ для этого надо
> определить класс и все операции вручную. В Java не лучше. Но хоть
> где-нибудь-то можно?!

В С++ пишешь:
typedef boost::strong_typedef<int> NumberOfSymbolInString;

Все, и не надо ничего больше писать

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

VladD2 wrote:

> C>Не используют они никаких настроек. Вся Винда сейчас у них
> компилируется
> C>на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.
> Сдается мне, что на VC6 компилировалась NT 4. А винды компилируются на
> чем попалао (например, на исследовательских версиях компиляторов). Ну,
> а релизы винды компилируются на текущем релизе VC. Хотя тут я ничего
> утверждать не могу. Это только догадки.

Релизы всех виндов до SP2 компилируются VC6 — это можно посмотреть в
отладочных символах ядра.

С XP SP2 начали пользоваться для компиляции ядра VC7.1 у которого другой
формат отладочных символов. Все пользователи VC6 побежали жаловаться в
МС и в VC8 формат снова изменили на VC6-compatible и пообещали
перекомпилить Винду

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

R>Для Integer — пойдёт на ура, насколько я помню.
Вот только, если определить

type MyType=Integer;

то MyType становится неотличим от Integer и можно использовать один вместо другого.

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

T>Здравствуйте, Трурль, Вы писали:

Т>>В Аде можно

T>Рыба вобла! А пример кода можно?

type MyType is INTEGER;

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

FDS>Ладно, убедили: Аду на свалку, мне — подучить языки.

FDS>Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.

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

Не надо

. Здесь все элементарно просто. В статье, что ты привел, речь идет не о С++, а о С. Разница огромна, и дело не в том, что в С++ есть слово "класс". С++ — строготипизирован. А С — нет. Более того. Ошибка типизации в С, которую так легко допустить, мало того что не ловится компилятором, так она еще и приводит к повреждению памяти, что увеличивает цену исправления дефектов и увеличивает время обнаружения и исправления дефектов — в рантайме вовсе не обязательно будет креш.

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

Так чего вы хотите?

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

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

T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

struct PositionInString{int Value;};

Оно?

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

FDS> Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Язык программирования созданный Никлаусом Виртом и Юргом Гуткнехтом параллельно с создание операционной системы тоже носящей имя Оберон. Потомок от языков Pascal/Modula. (Имеет сборку мусора, модульную структуру, допускает высокоэффективную компиляцию даже без специальных ухищрений разработчиков компиляторов, а уж с ухищрениями — вообще улёт.)

Породил целое семейство языков — Обероны:

Pascal (1970) -->-- Modula 2 (1979) -->-- Oberon (1987) -->-- Oberon 2 (1992) -->-- Component Pascal (1997), Active Oberon (2000), Zonnon (2005)
+ многие другие

Скоро в России школьников будут учить языку Component Pascal вместо устаревшего Turbo Pascal.

Сергей Губанов wrote:

> Скоро в России школьников будут учить языку Component Pascal
> <http://www.inr.ac.ru/%7Einfo21/> вместо устаревшего Turbo Pascal.

Когда же прекратят издеваться над школьниками....

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, Cyberax.

Вся "винда" проверяется с помощью систем автоматической проверки (существует два поколения таких систем). Это очень серьёзно. Если бы у меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

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

FDS>>>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

...

VD>Ну, ты говоришь "действительно разделение, а не как сейчас". Вот и интересно про что ты ведешь речь? Где это "как сейчас"?

FDS>> Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему.

VD>Странно. Даже дельфи имееть структурированную обработку исключений. А языки типа Efil имеют так же пред- и пост-условия, ну, и другие фишки. Есть так же плагины для C# превросящие декларативный контроль ошибок в этот язык.

Слышал.
Я говорю про то, что контроль ошибок как код можно было бы скрыть когда надо, а когда надо — показать, причём в соответствующем контексте, скрывая ненужные алгоритмические подробности.
Насколько я знаю, в настоящее время, код пост- и предусловий существует отдельно, а исключения — прямо в коде (ну, конечно, это лучше, чем if IORESULT <> 0, но ненамного).

FDS>>Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

VD>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.

Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....

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

VD>К логическим? Т.е. если я где-то неверно тип привел, то это логическая ошибка? Ну, да, допустим, что для С++ это можно назвать логической ошибкой. Но как обяснить тот факт, что на Яве или C# (в безопастном режиме) таких ошибок вообще невозможно сделать? Вообще!

К сожалению я мало программировал на C#. По моему, там вообще приведение типов используется "в принципе" осторожнее.
Вообще, я скажу, проектирование программы на C++ и C# просто абсолютно разные вещи. Я когда учил C# голову чуть не сломал.

FDS>>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.

VD>Не, ну, все же интересно...

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

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

2. Отсутствие доказанного математического алгоритма вплоть до процесса отладки. Полное незнание предметной области. Непонимание предметной сущности объекта. Путаница в порядках следования индексов свойств-массивов и правилах их перестановки.
Сюда же: неполная проработка проблемы перед кодированием: обычно ведёт к конфликтным ситуациям с объектами, зависанию приложения в бесконечном цикле или другим "экспрессивным" ошибкам. (очень часто)

3. Слшком сильная иерархичность доступа к объектам => запутанный код. Слишком сильное разделение на
приложения на слои. Наличие централизованного хранилища информации, не привязанного ни к одному физическому представлению (ввод пользователя, диск, обработка, вывод пользователя), что вводило лишние преобразования объектов в программу.
(тотально у всех программистов — непрофильных выпускников с опытом менее 1-3 года (за редким искл.), или профильных с опытом менее 1 — 1,5 года (у всех, видимо отличные в фирму не идут — идут куда получше))

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

5. Неправильные вызовы функций из других библиотек (несогласование типов и методов выделения памяти), забытые stdcall и pascal (удивительно, даже у довольно опытных программистов).
Сюда же: неправильные преобразования типов в межмодульных связях. Т.е., например, в одном модуле загружается однобайтовое значение в 4-байтовый стек, старшие байты не инициализированы. Другой модуль читает все 4-байта. (редко)

VD>Ну, контроль со стороны компилятора и рантайма, а так же разные сборщики мусора только облегчает жизнь программисту, но никак не заменяют программиста. Писать алгоритмы и добиваться их верной работы прийдется все же самостоятельно.

Я об этом и говорю. Но стремиться нужно к полной автоматизации кодирования (интересно, меня тогда уволят? Я ведь кодировщик, типичный).
Со сборщиками мусора я в C# то же намучился, но кажется понял — легко и удобно, но очень убого. Уж тогда бы сразу на аппаратном уровне сделали. Мне, как assembler-программисту, пусть и микроконтроллеров, жутко на это смотреть.

Кстати, до сих пор не могу понять, почему компилятор не может сам контролировать выделение памяти, особенно, когда на этапе компиляции уже всё понятно. А если не понятно, опять же компилятор может вставить код — счётчик ссылок (другое дело — такой код уже сложно сделать в общем случае, нужен анализ копирования с копии и т.п. Но ведь это возможно).

Здравствуйте, Gaperton.

Я просил не спорить больше об Ада и С++.

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

C>Beagle 2 лучше было не приводить в пример.

Так и знал...

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

C>FDSC wrote:

>>>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>>>> является корректным (т.е. объект разрушаеся или не создаётся, или
>>>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>>>> формальной безошибочности работы следующих функций.
>> C>Бессмысленно. Просто нужно разработать нормальную семантику
>> C>использования объектов (как в С++) или использовать GC и не иметь таких
>> C>проблем вообще.
>> Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и
>> частичная отладка всего проекта без них.

C>Это я про деструкторы — в нормальных языках они вызываются почти всегда
C>автоматически, а в других языках деструкторов нет вообще. Простейшие
C>ошибки типа _возможного_ обращения по нулевому указателю давно умеют
C>отслеживать статические верефикаторы в C#/Java.

Тут про деструкторы ни слова.

>>>> 3. IDE позволяет задавать граф возможных и запретных
>>>> последовательностей вызовов методов (инциализация -> применение,
>>>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>>>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>>>> объекта можно делать константными в пределах блока кода (или наоборот,
>>>> изменяемыми)
>> C>Нафиг такое не нужно, так как это принципиально невозможно проверить в
>> C>общем случае и, вдобавок, обходится грамотным проектированием.
>> Не понял, что нельзя проверить в общем случае?

C>Что последовательность вызовов будет нужно.

Чушь.

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

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

Никто и не предлагает его строить.

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

C>Смотри С++, а именно идиому RAII — Resource Acquisition Is
C>Initialization и smart pointer'ы. То есть для работы с микроконтроллером
C>нужно взять на него хэндл, в конструкторе которого производится нужная
C>предварительная инициализация.

Неправильно понял. Привожу пример:
Уже есть предварителбная инициализация.
Пользователь устанавливает в программе диапазон измерений АЦП — 10 В, ЦАП — 5 В.
Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно. Естественно нет. Никакая инициализация тут просто так не поможет. "Умные указатели" тут вообще не причём.
Программа должна обрабатывать эту ошибку пользователя, а такиз вариантов масса.

>> C>А смысл?
>> Смысл простой. В Delphi, например, вообще нельзя работать из другого
>> класса с private-членами. Protected — только в текущем модуле.
>> Допустим я хочу поправить (дополнить) чужой класс (в любом языке),
>> зачем мне делать доступными приватные члены для всех методов, когда
>> мне нужен, возможно, только один? Зря возможность ошибочного вызова
>> делать.

C>В С++ есть механизм friend'ов, который позволяет открыть приватные члены
C>для избранных классов или функций. Хотя необходимость использования
C>такого механизма показывает на неправильное проектирование — другой
C>класс не должен лезть в приватные данные класса.

Представь, что класс, в который ты хочешь лезть неправильно спроектировали. Собственно ты правильно понял.

>> C>А нафиг??
>> Мне, например, надобилось.
>> Привожу примеры:
>> Один алгорит с 7 вложенными циклами Delphi компилирует так, что
>> переписанный на asm работает в 7,5 раза быстрей, но при смене проекта
>> всё заново писать приходиться. Муторно.

C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
C>ассемблером, а потом линкуйте в проект.

И что? Всё так же останется. Ещё и компилировать отдельно придётся.

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

"Хаки" в приложении работают на любой системе, совместимой с Intel x86.
Ничего себе небольшие — час или 15 минут!

FDSC wrote:

> Вся "винда" проверяется с помощью систем автоматической проверки
> (существует два поколения таких систем). Это очень серьёзно. Если бы у
> меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

Эта система называется 'lint'

И толку от нее ~0.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, Cyberax, Вы писали:
C>В чем в С++ проблема с runaway inheritance я не понимаю (вообще в первый раз такой термин слышу), больше похоже, что их местные программисты чего-то не так задизайнили.
Именно об этом они и говорят. По их наблюдениям, "местные программисты" любят наследоваться только от известных им классов поближе к всеобщему корню, наколбашивая десятки братьев-близнецов вместо выделения общей функциональности и минимизации copy/paste кода. Кроме того, те же программисты слабо владеют шаблонами, потому любят плодить свои личные контейнеры вместо параметризации stl.
Впечатление такое, что парни сфотографировали хаос — разработку без проектирования, где никто не следит за reuse, и порождение классов выполняется как в голову ударит. Конечно никто не станет рисовать красивые иерархии — класс соседа по качеству на порядок ниже, чем библиотечный, так что проще отнаследоваться от корня и скопировать 90% поведения, чем унаследоваться от соседа (особенно если он private и protected разбрасывает аки Воробъянинов бублики). А раз за разработку своих контейнеров никто по рукам не ударит — будет велосипедалить очереди и стеки (благо основное, чему их научили на пятидневных курсах — это именно очереди и стеки на С++, а вовсе не паттерны проектирования бизнес-классов). Потом, припертый к стенке, он начнет кричать про критическую неприменимость stl для его целей, мотивируя то неясными багами в методе reserve, то чиста своим заточенным мемори менеджером...

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

FDS>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....

Да сколько угодно. Вон, в форуме Delphi регулярно предлагают конструктор поместить внутрь try, а free — в finally

вот тебе и деструктор без конструктора...

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

FDSC wrote:

> Неправильно понял. Привожу пример:
> Уже есть предварителбная инициализация.
> Пользователь устанавливает в программе диапазон измерений АЦП — 10 В,
> ЦАП — 5 В.
> Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно.
> Естественно нет. Никакая инициализация тут просто так не поможет.
> "Умные указатели" тут вообще не причём.
> Программа должна обрабатывать эту ошибку пользователя, а такиз
> вариантов масса.

Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
исполнения.

> C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
> C>ассемблером, а потом линкуйте в проект.
> И что? Всё так же останется. Ещё и компилировать отдельно придётся.

Два случая:
1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
этого уродовать язык.
2. Ассемблера много — точно надо выносить в отдельный файл.

> C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
> C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
> C>небольших выигрышей в производительности).
> "Хаки" в приложении работают на любой системе, совместимой с Intel x86.

А если у меня PPC? Или Amd64 или Itanium?

> Ничего себе небольшие — час или 15 минут!

Крайне редкий случай — обычно выигрыш в десятки процентов.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>FDSC wrote:

>> Неправильно понял. Привожу пример:
>> Уже есть предварителбная инициализация.
>> Пользователь устанавливает в программе диапазон измерений АЦП — 10 В,
>> ЦАП — 5 В.
>> Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно.
>> Естественно нет. Никакая инициализация тут просто так не поможет.
>> "Умные указатели" тут вообще не причём.
>> Программа должна обрабатывать эту ошибку пользователя, а такиз
>> вариантов масса.

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

Логических ошибок времени исполнения не бывает. Компилятор должен указать мне, что такая возможность у пользователя есть, иначе мне придётся искать её самому (это тяжело, правда).

>> C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
>> C>ассемблером, а потом линкуйте в проект.
>> И что? Всё так же останется. Ещё и компилировать отдельно придётся.

C>Два случая:
C>1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
C>этого уродовать язык.
C>2. Ассемблера много — точно надо выносить в отдельный файл.

Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).

>> C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
>> C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
>> C>небольших выигрышей в производительности).
>> "Хаки" в приложении работают на любой системе, совместимой с Intel x86.

C>А если у меня PPC? Или Amd64 или Itanium?

Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.

>> Ничего себе небольшие — час или 15 минут!

C>Крайне редкий случай — обычно выигрыш в десятки процентов.

В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.

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

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

FDS>>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....

S>Да сколько угодно. Вон, в форуме Delphi регулярно предлагают конструктор поместить внутрь try, а free — в finally

вот тебе и деструктор без конструктора...

Класс..

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

FDS>А вообще фрагмент, по моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в программировании на C++ чего-то??? (я сам прогр. Delphi / assembler, C++ только правлю и дополняю, и то не очень часто).

Ну вот и ещё один полез что-то доказывать вне области собственных знаний...

Здравствуйте, tarkil, Вы писали:
T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
Delphi. Начиная, если не путаю, с 4 не то 5.

type MyInt = type int

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

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

R>>Для Integer — пойдёт на ура, насколько я помню.
Т>Вот только, если определить
Т>

type MyType=Integer;

Т>то MyType становится неотличим от Integer и можно использовать один вместо другого.

Верно, но только если опустить второй type:

type MyType= type Integer;

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

FDSC wrote:

> C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
> C>исполнения.
> Логических ошибок времени исполнения не бывает. Компилятор должен
> указать мне, что такая возможность у пользователя есть, иначе мне
> придётся искать её самому (это тяжело, правда).

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

> C>Два случая:
> C>1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
> C>этого уродовать язык.
> C>2. Ассемблера много — точно надо выносить в отдельный файл.
> Тут прикол в том, что я рад бы от него вообще избавиться.

А зачем? Пусть себе живет там, где он нужен.

> C>А если у меня PPC? Или Amd64 или Itanium?
> Amd64 то же совместимый с Intel x86.

С большими (и влияющими на производительность) оговорками.

> С Itamium наши пользователи никогда не работают. Да и Delph то же.

Ну вот, сами себя ограничиваете.

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

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

>>> Ничего себе небольшие — час или 15 минут!
> C>Крайне редкий случай — обычно выигрыш в десятки процентов.
> В некотрых приложениях сплошь и рядом (всё равно редко, но очень
> значительно). Особенно в Delphi.

Ну так давно пора ее выбросить.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>FDSC wrote:

>> Вся "винда" проверяется с помощью систем автоматической проверки
>> (существует два поколения таких систем). Это очень серьёзно. Если бы у
>> меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

C>Эта система называется 'lint'

И толку от нее ~0.

Нет. Первое поколение: PREfix и PREfast.
Второе поколение: Slam, ESP и Vault.

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

C>FDSC wrote:

>> C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
>> C>исполнения.
>> Логических ошибок времени исполнения не бывает. Компилятор должен
>> указать мне, что такая возможность у пользователя есть, иначе мне
>> придётся искать её самому (это тяжело, правда).

C>Это невозможно в принципе в общем случае, а лишь в некоторых частных
C>случаях и со знанием семантики приложения.

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

По ассемблеру не согласен, но разумного ничего сказать не могу (да и не я решаю: выбрасывать Delphi или нет).

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

FDS>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....
Вот только в С++ с этим проблем нет.

Ибо деструкторы автоматические те за их вызовами следит компилятор.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

>>> 4. IDE реализует сам код, как граф. Названия методов даются как
>>> справочная информация для программиста, могут меняться автоматически.

C>>Было такое в Together и Rational Rose — успешно провалилось как
C>>неудобное и неюзабельное решение.

Д>очень интересно. а можно подробнее?

Изменять имена методов может любая утилита рефакторинга. Тут ЮМЛ-и и на фиг не уперлись.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

Д>Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций

Возможно. Вот бы на одну прямую глянуть.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>Вся "винда" проверяется с помощью систем автоматической проверки (существует два поколения таких систем). Это очень серьёзно. Если бы у меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

А я бы нервнечал. Уж больно в ней много глюков.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>Нет. Первое поколение: PREfix и PREfast.
FDS>Второе поколение: Slam, ESP и Vault.

PREfast входит в VS 2005. Но это довольно примитивное средство контроля. Своеобразный FxCop для анменеджед-кода. В МС вроде и посерьезнее были средства.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.

WH>Я такое встречал только в багландовском компиляторе, а он известен тем что в нем очень много ошибок.
WH>Короче не надо говорить про С++ то чего нет.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

S>>Да сколько угодно. Вон, в форуме Delphi регулярно предлагают конструктор поместить внутрь try, а free — в finally

вот тебе и деструктор без конструктора...

FDS>Класс..

Ага. Высший.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

WH>Вот только в С++ с этим проблем нет.

Ибо деструкторы автоматические те за их вызовами следит компилятор.

Гы-гы:

class A
{
    A() { } // скрытый !!! :)
public:
    ~A()
    {
        printf("Goddammit! This is not supposed to happen!!!\n");
    }
};

void main()
{
    for (int i = 0; i < 10; i++)
        ((A*)&i)->~A();
}

И что самое поскудное

— это же совершенно корректный код

.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>К сожалению я мало программировал на C#. По моему, там вообще приведение типов используется "в принципе" осторожнее.
FDS>Вообще, я скажу, проектирование программы на C++ и C# просто абсолютно разные вещи.

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

FDS> Я когда учил C# голову чуть не сломал.

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

FDS>>>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.

VD>>Не, ну, все же интересно...

FDS>Привожу, что от неё осталось (кстати, это в основном были интерфейсные приложения), ошибки в порядке убывания значимости:
FDS>0. Разнообразные ошибки.

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

FDS>2. Отсутствие доказанного математического алгоритма вплоть до процесса отладки. Полное незнание предметной области. Непонимание предметной сущности объекта. Путаница в порядках следования индексов свойств-массивов и правилах их перестановки.
FDS>Сюда же: неполная проработка проблемы перед кодированием: обычно ведёт к конфликтным ситуациям с объектами, зависанию приложения в бесконечном цикле или другим "экспрессивным" ошибкам. (очень часто)

FDS>3. Слшком сильная иерархичность доступа к объектам => запутанный код. Слишком сильное разделение на
FDS>приложения на слои. Наличие централизованного хранилища информации, не привязанного ни к одному физическому представлению (ввод пользователя, диск, обработка, вывод пользователя), что вводило лишние преобразования объектов в программу.
FDS>(тотально у всех программистов — непрофильных выпускников с опытом менее 1-3 года (за редким искл.), или профильных с опытом менее 1 — 1,5 года (у всех, видимо отличные в фирму не идут — идут куда получше))

FDS>4. Обнуление полезной информации, в следствие вызова метода инициализации после считывания информации. Проверка на корректность данных, которые должны быть или могут быть некорректны (у всех программистов, обычно в каждом приложении или через раз (у неопытных гораздо чаще)).

FDS>5. Неправильные вызовы функций из других библиотек (несогласование типов и методов выделения памяти), забытые stdcall и pascal (удивительно, даже у довольно опытных программистов).
FDS>Сюда же: неправильные преобразования типов в межмодульных связях. Т.е., например, в одном модуле загружается однобайтовое значение в 4-байтовый стек, старшие байты не инициализированы. Другой модуль читает все 4-байта. (редко)

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

FDS>Я об этом и говорю. Но стремиться нужно к полной автоматизации кодирования (интересно, меня тогда уволят?

Да.

FDS> Я ведь кодировщик, типичный).

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

FDS>Со сборщиками мусора я в C# то же намучился, но кажется понял — легко и удобно, но очень убого.

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

FDS> Уж тогда бы сразу на аппаратном уровне сделали. Мне, как assembler-программисту, пусть и микроконтроллеров, жутко на это смотреть.

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

FDS>Кстати, до сих пор не могу понять, почему компилятор не может сам контролировать выделение памяти, особенно, когда на этапе компиляции уже всё понятно.

Компилятор и контролирует. Только не тот что текст на токины и ветки AST крамсает. А тот который из промежуточного кода в рантайме машинный код строит. GC — это очень сложный механизм и JIT-компилятор внем один из главных элементов. Он строит карты доступности и делает кучу разных оптимизаций.

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

FDS> А если не понятно, опять же компилятор может вставить код — счётчик ссылок (другое дело — такой код уже сложно сделать в общем случае, нужен анализ копирования с копии и т.п. Но ведь это возможно).

Счетчик ссылок — это:
1. Довольно медленно. Сборщик мусора работает значитльно быстрее чем счетчики ссылок в скриптовых языках или КОМ-е.
2. Не решает всех проблем. При подсчете ссылок есть вероятность появления циклических ссылок. В скриптовых языках использующих подсчет ссылок для контроля жизни объектов специально для решения этой проблемы периодически запускают специальный код отыскивающий мертвые циклы в ссылках и прибивающий "подвисшие" объекты. Этот код крив и не очень то эффективен. Тот же ЖЦ Явы намного более эффективное решение.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

T>Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.

Ну, это их тараканы. Мое мнение очень просто. Лишать себя дополнительного контроля и при этом получать приципиально более медленные решения не стоит. Гибкости мне хватает и в C#.

T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

Если не ошибаюсь, в D нечто подобное возможно. Было в Паскале... перекочивало в Аду. Эта концепция вообще-то была во многих языках. Называлась по разному, но суть одна неких typedef, но порождающий не алиас, а новый тип. По-моему очень полезная концепция. Ну, да можно жить и без нее. Все же и копипыст, и шаблоны, и дженерики для этого применимы. И лучше помучиться с ними, чем постоянно вставлять проверки и молиться.

Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов. Пусть даже без полиморфизма. А с полиморфизмом так вообще была бы круть.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

FDS>>Нет. Первое поколение: PREfix и PREfast.
FDS>>Второе поколение: Slam, ESP и Vault.

VD>PREfast входит в VS 2005. Но это довольно примитивное средство контроля. Своеобразный FxCop для анменеджед-кода. В МС вроде и посерьезнее были средства.

PREfast несравним с Slam, ESP и Vault и действительно примитивен. Что у MS серьёзнее?

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

VD>Не совсем. Конечно на стиль языки влияют, но почему-то мне кажется, что человек после хорошей школы Шарпа будет и на С++ писать намного качественее. Шарп он подталкивает к более грамотному проектированию... к использованию ООП, безопасным приемам и т.п.

Согласен. Я то как раз после С++ (точнее C++ я к тому времени уже забыл, с Delphi) на C# переходил, а не наоборот.

FDS>> Я когда учил C# голову чуть не сломал.

VD>Очень странно. Многие находят изучение этого языка очень простым. Причем именно потому, что он очень логичен и интуитивен.

После Delphi слишком сильное различие в проектировании, потому что очень похоже в принципе и очень отличается в реализации. Вообще мне он очень понравился.

VD>Прочита по внимателнее свой

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

Согласен: все решения были вообще наполовину процедурными — удивительно как вообще жили. Доходило до вызовов в Delphi функций LocalAlloc совершенно без надобности.

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

Убого там как раз — расход памяти и процессора.

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

Я уже давно это понял. Три раза разбирался: кажется понял, а потом ...

VD>Счетчик ссылок — это:
VD>1. Довольно медленно. Сборщик мусора работает значитльно быстрее чем счетчики ссылок в скриптовых языках или КОМ-е.

Не знаю. Поверю на слово.

VD>2. Не решает всех проблем. При подсчете ссылок есть вероятность появления циклических ссылок. В скриптовых языках использующих подсчет ссылок для контроля жизни объектов специально для решения этой проблемы периодически запускают специальный код отыскивающий мертвые циклы в ссылках и прибивающий "подвисшие" объекты. Этот код крив и не очень то эффективен. Тот же ЖЦ Явы намного более эффективное решение.

В общем согласен.

Спасибо. Особенно за R#. Я видел эту статью раньше, но почему-то не обратил внимания. Мысли там очень правильные.

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

FDS>Ладно, убедили: Аду на свалку, мне — подучить языки.

FDS>Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.

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

Господа! Вы Обероны забыли! Господин Губанов, где вы! АУУУ!!!

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

MN>Господа! Вы Обероны забыли! Господин Губанов, где вы! АУУУ!!!

Re[5]: Частота ошибок в зависимости от языка: что делать?

... << RSDN@Home 1.1.4 beta 7 rev. 472>>

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

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

FDS>Логических ошибок времени исполнения не бывает. Компилятор должен указать мне, что такая возможность у пользователя есть, иначе мне придётся искать её самому (это тяжело, правда).
Для этого придуманы различные паттерны. Если у вас два объекта требуют согласованного конфигурирования — сделайте класс "согласованный конфигуратор". Или примените шаблоны С++, чтобы попытка присвоить несовместимый вход к выходу была ошибкой компиляции.
Если подобных паттернов становится много, и их трудно контролировать — посмотрите в сторону DSL.
FDS>Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).
Ассемблер вообще не нужен.
FDS>Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
FDS>В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.
Не нужно. Ты в курсе, почему из С++ убирают слово register? Да потому, что ранние компилеры забивали на него — не умели оптимизировать. А новые компиляторы забивают на наго потому, что у них больше информации об использовании переменной, чем у программиста. И они принимают значительно более обоснованные решения.
Что это означает? Что вместо возможности принуждать компилятор к определенному поведению, лучше наоборот — научить компилятор корректно оптимизировать. Современное состояние оптимизации настолько далеко ушло от знакомых мне со школы решений типа "выноса инварианта за цикл"... Сейчас компиляторы ухитряются инлайнить виртуальные вызовы!
FDS>В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.
Я, честно говоря, не понимаю вас. Если производительность критична — выкинь Delphi. Современные компиляторы промышленного уровня оптимизируют так, что ты запаришься их догонять. При этом все время рискуя вылететь за пределы кросс-процессорной совместимости, или внести трудноуловимую ошибку. Возможности оптимизации в Delphi находятся в противозачаточном состоянии. Поэтому работа с ним вредна для разработчиков time-critical приложений: они привыкают не доверять компилятору.

Не так давно я имел спор с таким Delphi/Asm специалистом. Его мнение о С++ было ниже плинтуса. Я предложил ему продемонстрировать это. Ок, он попытался нарисовать на асме банальный поиск в массиве интов: while(a[i++]!=test && i<length); return i. Конечно, VC++ 7.1 написал более длинный цикл. Ручной асм-код смотрелся намного красивше. Увы, при замерах скорости VC победил с разгромным счетом.

Что это означает? Что асм применяют сейчас почти только те, кто пользуется некачественным компилятором. Ребята, возьмите нормальный компайлер. Это сэкономит вам сотни часов бессмысленно потраченного времени.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

VD>Здравствуйте, Дарней, Вы писали:

Д>>Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций

VD>Возможно. Вот бы на одну прямую глянуть.

Я бы тоже не прочь посмотреть

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

VD>Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов.

Будут проблемы со срезкой.

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

S>Верно, но только если опустить второй type:
S>

S>type MyType= type Integer;
S>

Согласен, но raskin упоминал нечто древне-паскалевское.

Здравствуйте, Трурль, Вы писали:
Т>Согласен, но raskin упоминал нечто древне-паскалевское.
Ой, этих паскалей... Причем между ними идет постоянный взаимообмен фичами. К тому же, вполне возможно что такая фича существовала со времен какого-нибудь TP7, только я о ней ничего не знал. В свое время напоролся в исходниках, и был шибко удивлен.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

VD>Там компилятор был не причем. Там были махинации со своим пулом памяти и вручную вызывались деструкторы. Конструктор же вызывался дважды из-за прохода по памяти в одном из деструкторов (или еще где... уже не помню).

Те наплевал на все защиты С++, что-то наворотил шаловливыми ручками, а С++ виноват? Прэлесно!

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

VD>И что самое поскудное

— это же совершенно корректный код

.
И что это доказывает? В C# тоже можно написать unsafe и натворить тАкое

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

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

S>Для этого придуманы различные паттерны. Если у вас два объекта требуют согласованного конфигурирования — сделайте класс "согласованный конфигуратор". Или примените шаблоны С++, чтобы попытка присвоить несовместимый вход к выходу была ошибкой компиляции.

А почему я должен писать код, когда компилятор может в принципе это сделать и без него?

S>Если подобных паттернов становится много, и их трудно контролировать — посмотрите в сторону DSL.

Вот именно, "посмотрите в сторону DSL". Почему бы это не реализовать прямо в компиляторе?

FDS>>Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).
S>Ассемблер вообще не нужен.

Особенно для тех микроконтроллеров, для которых нет других компиляторов.

FDS>>Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
FDS>>В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.
S>Не нужно. Ты в курсе, почему из С++ убирают слово register? Да потому, что ранние компилеры забивали на него — не умели оптимизировать. А новые компиляторы забивают на наго потому, что у них больше информации об использовании переменной, чем у программиста. И они принимают значительно более обоснованные решения.
S>Что это означает? Что вместо возможности принуждать компилятор к определенному поведению, лучше наоборот — научить компилятор корректно оптимизировать. Современное состояние оптимизации настолько далеко ушло от знакомых мне со школы решений типа "выноса инварианта за цикл"... Сейчас компиляторы ухитряются инлайнить виртуальные вызовы!

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

FDS>>В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.
S>Я, честно говоря, не понимаю вас. Если производительность критична — выкинь Delphi. Современные компиляторы промышленного уровня оптимизируют так, что ты запаришься их догонять. При этом все время рискуя вылететь за пределы кросс-процессорной совместимости, или внести трудноуловимую ошибку. Возможности оптимизации в Delphi находятся в противозачаточном состоянии. Поэтому работа с ним вредна для разработчиков time-critical приложений: они привыкают не доверять компилятору.

Производительность вообще не критична. Просто она иногда такой становится случайно. Десятый раз повторяю — не я выбираю средство разработки!

S>Не так давно я имел спор с таким Delphi/Asm специалистом. Его мнение о С++ было ниже плинтуса. Я предложил ему продемонстрировать это. Ок, он попытался нарисовать на асме банальный поиск в массиве интов: while(a[i++]!=test && i<length); return i. Конечно, VC++ 7.1 написал более длинный цикл. Ручной асм-код смотрелся намного красивше. Увы, при замерах скорости VC победил с разгромным счетом.

У меня хорошее мнение о качестве компиляции C++. Его очень трудно обогнать (я пробовал). Между прочим, Delphi то же обогнать не легко.
Найди программиста получше. Я тебе без цикла это напишу, с помощью строковых команд — VC точно хуже компилирует, уже пробовали.
Никогда не видел, что б ассемблер смотрелся намного красивее языка высокого уровня, даже если это C++.

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

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

S>Что это означает? Что асм применяют сейчас почти только те, кто пользуется некачественным компилятором. Ребята, возьмите нормальный компайлер. Это сэкономит вам сотни часов бессмысленно потраченного времени.

Любой компилятор иногда становится некачественным. VС с MFC — малокачественные по сравнению с Delphi, кодга пишешь интерфейсное приложение — на Delphi просто ничего знать не нужно, что бы его написать, а в MFC ещё потрудиться надо, да ещё карты сообщений в коде по ногами путаются всё время.
Обычно, только C++ для МК всегда супер качественный — его действительно не обогнать.

Мне приходилось применять asm (правда, всего 2 раза), для создания более компактного и понятного кода.

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

FDS>А почему я должен писать код, когда компилятор может в принципе это сделать и без него?
ГМ. Я может, чего-то не уловил. Но компилятор в любом случае нуждается в информации о том, что тебе можно, а что нельзя. Написание этого кода — и есть такой рассказ компилятору.
FDS>Вот именно, "посмотрите в сторону DSL". Почему бы это не реализовать прямо в компиляторе?
Что именно?

FDS>Особенно для тех микроконтроллеров, для которых нет других компиляторов.

Не передергивай. Речь шла о совмещении кода на асм с другими компиляторами. Ты не на Delphi часом под микроконтроллеры пишешь?
FDS>Научить компилятор корректно оптимизировать очень трудно, а принудить его может почти каждый.
Уже. Друг мой, уже. И давно. На досуге попробуй порвать VC хотя бы 7. Уверяю тебя — устанешь. Даже если ты в уме помнишь latency для всех команд Pentium и кто там через какой пайп может ездить.
FDS>Производительность вообще не критична. Просто она иногда такой становится случайно. Десятый раз повторяю — не я выбираю средство разработки!
Очень странно. Сначала ты предлагаешь изобрести новое средство разработки. А когда тебе говорят: так вот же оно! Уже есть! Не надо ничего изобретать! Ты отказываешься от обсуждения, т.к. ты не выбираешь средство разработки. Что ж, сочувствую.

FDS>У меня хорошее мнение о качестве компиляции C++. Его очень трудно обогнать (я пробовал). Между прочим, Delphi то же обогнать не легко.
Легко. Как раз Delphi я тебе порву на раз-два. Особенно в математике. У них никогда не было толковой оптимизации плавающей запятой. Ну и про убогий инлайнинг тоже забывать не стоит.
FDS>Найди программиста получше. Я тебе без цикла это напишу, с помощью строковых команд — VC точно хуже компилирует, уже пробовали.
Попробуй еще раз. На VC 7.0 или 7.1. Убедишься в том, что строковые команды рулят не всегда.
FDS>Никогда не видел, что б ассемблер смотрелся намного красивее языка высокого уровня, даже если это C++.
Имеется в виду асм-код, сгенеренный компилятором.
FDS>Я могу сделать любой код на asm (если, конечно, я его могу сделать его вообще), исполняющийся столько же или быстрее кода C++, при этом не зная, как компилирует VC.
Это иллюзия. Оптический обман. В некоторых простых случаях ты действительно сделаешь код, исполняющийся на равных. В некоторых, еще более редких случаях, ты сможешь получить выигрышь за счет глобальных оптимизаций (которые С++ — компайлеру просто недоступны). Код, сгенерированный компилятором Intel, ты будешь догонять месяцами. А изучая дизассемблернуый код, будешь периодически всплескивать руками и говорить "не может быть! Это должно работать медленнее, чем у меня".
FDS>Это так же, как сравнивать программы, которые один компилятор скомпилировал с опцией оптимизации размера кода, а другой — с опцией оптимизации быстродействия.
Нет. Это как сравнивать программы, написанные человеком, который ничего не знал про MMX, SSE2, и параллельные конвейеры в x86, c программами, написанными экспертом.

FDS>Любой компилятор иногда становится некачественным. VС с MFC — малокачественные по сравнению с Delphi, кодга пишешь интерфейсное приложение — на Delphi просто ничего знать не нужно, что бы его написать, а в MFC ещё потрудиться надо, да ещё карты сообщений в коде по ногами путаются всё время.
На самом деле это не вполне так. Ты, скорее всего, опять же говоришь про VC 6.0. C тех пор случилось много нового.
FDS>Обычно, только C++ для МК всегда супер качественный — его действительно не обогнать.

FDS>Мне приходилось применять asm (правда, всего 2 раза), для создания более компактного и понятного кода.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

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

FDS>>А почему я должен писать код, когда компилятор может в принципе это сделать и без него?
S>ГМ. Я может, чего-то не уловил. Но компилятор в любом случае нуждается в информации о том, что тебе можно, а что нельзя. Написание этого кода — и есть такой рассказ компилятору.

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

FDS>>Вот именно, "посмотрите в сторону DSL". Почему бы это не реализовать прямо в компиляторе?
S>Что именно?

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

FDS>>Особенно для тех микроконтроллеров, для которых нет других компиляторов.

S>Не передергивай. Речь шла о совмещении кода на асм с другими компиляторами. Ты не на Delphi часом под микроконтроллеры пишешь?

Издеваешся?

FDS>>Научить компилятор корректно оптимизировать очень трудно, а принудить его может почти каждый.
S>Уже. Друг мой, уже. И давно. На досуге попробуй порвать VC хотя бы 7. Уверяю тебя — устанешь. Даже если ты в уме помнишь latency для всех команд Pentium и кто там через какой пайп может ездить.

Я же сказал, не всегда компилятор лучше — чем новее компилятор, тем лучше он оптимизирует код, но в некоторых частных случаях всё равно плохо компилирует. Поменьше читай рекламных сообщений. Кстати, времена исполнения помнить совсем не обязательно.

FDS>>Производительность вообще не критична. Просто она иногда такой становится случайно. Десятый раз повторяю — не я выбираю средство разработки!
S>Очень странно. Сначала ты предлагаешь изобрести новое средство разработки. А когда тебе говорят: так вот же оно! Уже есть! Не надо ничего изобретать! Ты отказываешься от обсуждения, т.к. ты не выбираешь средство разработки. Что ж, сочувствую.

А, вот о чём! Согласен. Но в C++ нет некоторых возможностей Delphi — вот я и не могу перейти на него. Иначе бы все уже давно на Delphi плюнули.

FDS>>У меня хорошее мнение о качестве компиляции C++. Его очень трудно обогнать (я пробовал). Между прочим, Delphi то же обогнать не легко.
S>Легко. Как раз Delphi я тебе порву на раз-два. Особенно в математике. У них никогда не было толковой оптимизации плавающей запятой. Ну и про убогий инлайнинг тоже забывать не стоит.

М-м. Попробуй.

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

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

FDS>>Никогда не видел, что б ассемблер смотрелся намного красивее языка высокого уровня, даже если это C++.
S>Имеется в виду асм-код, сгенеренный компилятором.

А-а-а. Да кто ж его смотрит то!

FDS>>Я могу сделать любой код на asm (если, конечно, я его могу сделать его вообще), исполняющийся столько же или быстрее кода C++, при этом не зная, как компилирует VC.
S>Это иллюзия. Оптический обман. В некоторых простых случаях ты действительно сделаешь код, исполняющийся на равных. В некоторых, еще более редких случаях, ты сможешь получить выигрышь за счет глобальных оптимизаций (которые С++ — компайлеру просто недоступны).

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

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

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

Где это я его буду догонять, на своём AMD Athlon?
Точно, бывает такое. Но программист, написавший компилятор от Intel, возможно, напишет ещё круче.

FDS>>Это так же, как сравнивать программы, которые один компилятор скомпилировал с опцией оптимизации размера кода, а другой — с опцией оптимизации быстродействия.
S>Нет. Это как сравнивать программы, написанные человеком, который ничего не знал про MMX, SSE2, и параллельные конвейеры в x86, c программами, написанными экспертом.

Значит ты взял не assembler-программиста. Тогда о чём вообще речь?

FDS>>Любой компилятор иногда становится некачественным. VС с MFC — малокачественные по сравнению с Delphi, кодга пишешь интерфейсное приложение — на Delphi просто ничего знать не нужно, что бы его написать, а в MFC ещё потрудиться надо, да ещё карты сообщений в коде по ногами путаются всё время.
S>На самом деле это не вполне так. Ты, скорее всего, опять же говоришь про VC 6.0. C тех пор случилось много нового.

Много нового, насколько я помню, случилось в .NET. А в VS for Windows, если только мастера изменились. В прочем, может я что-то важное упустил?!

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

C>В С++ пишешь:
C>typedef boost::strong_typedef<int> NumberOfSymbolInString;

Оп-па! Сколько бустом пользуюсь, а на этот класс внимания не обращал... Буду, буду знать, спасибо.

FDSC wrote:

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

Врет. Строковые команды еще с 486 процессора работают медленнее.

> Много нового, насколько я помню, случилось в .NET. *А в VS for
> Windows, если только мастера изменились. В прочем, может я что-то
> важное упустил?!*

Ну да, а Мерседес отличается от ВАЗа только кузовом.

В VC7.1 (и тем более в VC8.0) компилятор намного лучше, чем в VC6.
Больше оптимизаций, лучше качество работы, меньше глюков. Ну и поддержка
Стандарта С++ почти полная.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>FDSC wrote:

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

C>Врет. Строковые команды еще с 486 процессора работают медленнее.

Минуточку. Медленнее чего? Приведи asm код, который работает быстрее, или хотя бы (если лень) опиши его. Впрочем, я посмотрю VC 7, может найду там что-нибудь интересное.

>> Много нового, насколько я помню, случилось в .NET. *А в VS for
>> Windows, если только мастера изменились. В прочем, может я что-то
>> важное упустил?!*

C>Ну да, а Мерседес отличается от ВАЗа только кузовом.

C>В VC7.1 (и тем более в VC8.0) компилятор намного лучше, чем в VC6.
C>Больше оптимизаций, лучше качество работы, меньше глюков. Ну и поддержка
C>Стандарта С++ почти полная.

И что из этого? Там что, появилась поддержка VCL? Я же говорю не про компилятор. Delphi позволяет разрабатывать приложения быстрее.

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

Т>

Т>type MyType is INTEGER;
Т>

А может быть ещё можно как-то расширить поведение или наоборот — урезать?

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

M>

M>struct PositionInString{int Value;};
M>

M>Оно?

Если сюда все операторы ещё воткнуть, допустимые для целого числа — тогда оно.

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

C>В С++ пишешь:
C>typedef boost::strong_typedef<int> NumberOfSymbolInString;

Любопытно... О какой версии буста идёт речь? В 1.30.2 ещё про strong_typedef ничего не слышно, а в 1.32.0 (которую только что скачал) нет класса boost::strong_typedef, но есть макрос BOOST_STRONG_TYPEDEF.

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

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

WH>>Вот только в С++ с этим проблем нет.

Ибо деструкторы автоматические те за их вызовами следит компилятор.

VD>Гы-гы:
VD>

VD>class A
VD>{
VD>    A() { } // скрытый !!! :)
VD>public:
VD>    ~A()
VD>    {
VD>        printf("Goddammit! This is not supposed to happen!!!\n");
VD>    }
VD>};

VD>void main()
VD>{
VD>    for (int i = 0; i < 10; i++)
VD>        ((A*)&i)->~A();
VD>}
VD>

VD>И что самое поскудное

— это же совершенно корректный код

.

Страуструп говорит про такие случаи приблизительно так: C++ (в отличии от C89/-) защищает от случайного допущения ошибки, но не от преднамеренного жульничества.
P.S. Явный вызов деструктора это клиника, я бы не назвал это корректным кодом.

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

FDS>Нет. Компилятор должен мне вывести граф возможных ситуаций в программе, а я сам посмотрю, что можно, что нельзя.
В проекте на 10 метров кода будет тАкой граф...

FDS>Я же сказал, не всегда компилятор лучше — чем новее компилятор, тем лучше он оптимизирует код, но в некоторых частных случаях всё равно плохо компилирует. Поменьше читай рекламных сообщений. Кстати, времена исполнения помнить совсем не обязательно.

На gamedev.ru бал здоровый флейм на эту тему. Толпа народа пыталась обогнать интеловский компилятор. Ни у кого не получилось даже догнать. Делай выводы.

FDS>А, вот о чём! Согласен. Но в C++ нет некоторых возможностей Delphi — вот я и не могу перейти на него. Иначе бы все уже давно на Delphi плюнули.
На дельфе хорошо только формочки клепать. А как язык дельфи отстает от С++ по всем параметрам.
В принципе есть тандартная связка формочки на VB6 + inproc COM cerver на С++.
В место VB6 можно взять дельфи.

FDS>Попробую, когда время будет хорошо посидеть на этом. Мне тут очень квалифицированный человек говорил, что строковые команды всегда лучше. Надо будет разобратся.
FDS>Может напишу ответ... через месяцок так...

Попробуй, попробуй...

FDS>Как раз в "простых случаях" мне будет очень трудно сделать хороший код — это я знаю не понаслышке, возможно, даже отстану. Но в некоторых сложных — могу обогнать (главное — не забывайте надевать шлем).
Ну-ну...
FDS>Насчёт глобальных оптимизаций — мы сейчас говорим имеено об оптимизациях на исполнения машинных команд, а не алгоритмов. Было бы неплохо, если б компилятор ещё и глобальные оптимизации делал — между прочим, мне такие приходилось делать — вполне доступные для компилятора.
Оптимизаторы становятся все умнее и умнее. Тут гдето пробегал тест в котором VC++8 обогнал VC++6 в несколько раз...
А сейчас в недрах мелкософта создается очень интересный оптимизатор который можно будет расширять своими правилами.

S>>Код, сгенерированный компилятором Intel, ты будешь догонять месяцами. А изучая дизассемблернуый код, будешь периодически всплескивать руками и говорить "не может быть! Это должно работать медленнее, чем у меня".
FDS>Где это я его буду догонять, на своём AMD Athlon?
Ну код интеловского компилятори и на атлонах работает не плохо...

FDS>Много нового, насколько я помню, случилось в .NET. А в VS for Windows, если только мастера изменились. В прочем, может я что-то важное упустил?!
Ну да так по мелочи... довили язык до 98%ного соответствия стандарту, улучшели оптимизатор...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

tarkil wrote:

> C>В С++ пишешь:
> C>typedef boost::strong_typedef<int> NumberOfSymbolInString;
> Любопытно... О какой версии буста идёт речь? В 1.30.2 ещё про
> strong_typedef ничего не слышно, а в 1.32.0 (которую только что
> скачал) нет класса boost::strong_typedef, но есть макрос
> BOOST_STRONG_TYPEDEF.

У меня копия из CVS. У BOOST_STRONG_TYPEDEF есть один недостаток — в нем
определен оператор присваивания из исходного типа.

Выглядит он так:

template<class T> struct strong_typedef : boost::totally_ordered1< 
strong_typedef<T> >
{
    T t;
    explicit strong_typedef(const T t_) : t(t_) {};
    strong_typedef(){};
    strong_typedef(const strong_typedef & t_) : t(t_.t){}
    strong_typedef & operator=(const strong_typedef & rhs) { t = rhs.t; 
return *this;}
    operator T () const {return t; }
    operator T & () { return t; }
    bool operator==(const strong_typedef & rhs) const { return t == rhs.t; }
    bool operator<(const strong_typedef & rhs) const { return t < rhs.t; }
};

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>Когда же прекратят издеваться над школьниками....

Что Вы имеете в виду?

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

C>У меня копия из CVS. У BOOST_STRONG_TYPEDEF есть один недостаток — в нем
C>определен оператор присваивания из исходного типа.

И конструктор. И оператор приведения к исходному типу. Ай-яй-яй...

C>Выглядит он так:
C>

C>template<class T> struct strong_typedef : boost::totally_ordered1< 
C>strong_typedef<T> > ...
C>

У этого класса есть большой минус — больше одного псевдонима int не сделаешь. Наверное, лучше из BOOST_STRONG_TYPEDEF изъять левые методы.

FDSC wrote:

> C>Врет. Строковые команды еще с 486 процессора работают медленнее.
> Минуточку. Медленнее чего? Приведи asm код, который работает быстрее,
> или хотя бы (если лень) опиши его. Впрочем, я посмотрю VC 7, может
> найду там что-нибудь интересное.

Медленнее явного цикла.

> C>В VC7.1 (и тем более в VC8.0) компилятор намного лучше, чем в VC6.
> C>Больше оптимизаций, лучше качество работы, меньше глюков. Ну и
> поддержка
> C>Стандарта С++ почти полная.
> И что из этого?

Ничего, просто работать с ним в разы удобнее, чем с древним VC6.

> Там что, появилась поддержка VCL? Я же говорю не про компилятор.
> Delphi позволяет разрабатывать приложения быстрее.

Это г. под названием VCL давно пора отправить на свалку. Есть нормальные
решения: QT или хотя бы WTL.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

tarkil wrote

> C>У меня копия из CVS. У BOOST_STRONG_TYPEDEF есть один недостаток — в
> нем
> C>определен оператор присваивания из исходного типа.
> И конструктор. И оператор приведения к исходному типу. Ай-яй-яй...

Еще и операторы сравнения, кстати

У них там в CVS еще библиотека физических констант развивается
(медленно), там еще все с поддержкой размерностей сделано было

То есть примерно так:

Force f;
Mass m(12);
Acceleration a(11);
f=m*a; //OK
f=m; //Error

> C>Выглядит он так:
> C>
>
>C>template<class T> struct strong_typedef : boost::totally_ordered1<
>C>strong_typedef<T> > ...
>C>
>
> У этого класса есть большой минус — больше одного псевдонима int не
> сделаешь.

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

> Наверное, лучше из BOOST_STRONG_TYPEDEF изъять левые методы.

С этим никаких проблем нет

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Сергей Губанов wrote:

> C>Когда же прекратят издеваться над школьниками....
> Что Вы имеете в виду?

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

WH>На дельфе хорошо только формочки клепать. А как язык дельфи отстает от С++ по всем параметрам.

Ой-ёй, а Вы Delphi Pascal точно хорошо знаете? Я на нём не писал уже года четыре, но воспоминания самые хорошие. Например, там есть полноценная поддержка RTTI, именованные конструкторы, удобные списки аргументов переменной длины... это что в голову сходу пришло.

tarkil wrote:

> WH>На дельфе хорошо только формочки клепать. А как язык дельфи отстает
> от С++ по всем параметрам.
> Ой-ёй, а Вы Delphi Pascal точно хорошо знаете? Я на нём не писал уже
> года четыре, но воспоминания самые хорошие. Например, там есть
> полноценная поддержка RTTI

RTTI есть в С++ уже лет 10. Reflection'а нет — это недостаток, но он и
не нужен.

> именованные конструкторы, удобные списки аргументов переменной
> длины... это что в голову сходу пришло.

Именованые конструкторы — это фабрики, только интегрированные в язык
(уродство). Аргументы переменной длины в С++ не нужны — есть другие
средства (перегрузка операторов).

Зато в Дельфи нет: умных указателей, автоматических объектов,
темплейтов. Дальше можно не продолжать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

WH>>На дельфе хорошо только формочки клепать. А как язык дельфи отстает от С++ по всем параметрам.
T>Ой-ёй, а Вы Delphi Pascal точно хорошо знаете?
Я с него начинал.
T>Я на нём не писал уже года четыре, но воспоминания самые хорошие.
У меня тоже были хорошие пока С++ не выучил.
T>Например, там есть полноценная поддержка RTTI,
В С++ тоже есть RTTI. Несколько скромнее чем в дельфе но есть.
Что касается полноценности дельфевого RTTI то у меня язык не повернется назвать его полноценным после того как я поработал с reflection'о в .NET.
T>именованные конструкторы,
В дельфе нет конструкторов. В дельфе есть фабрики на уровне языка.
Уродство еще то.
Ктомуже в С++ это делается на раз. Помнится я както развлекался и достиг синтаксиса почти как в дельфе.
T>удобные списки аргументов переменной длины... это что в голову сходу пришло.
В С++ оно тоже есть... вот только никто этим не пользуется ибо нафиг не упало.

За то в С++ есть:
1)Шаблоны.
2)Автоматические деструкторы.
3)Перегрузка операторов.

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

>> У этого класса есть большой минус — больше одного псевдонима int не сделаешь.
C>Кстати да, хотя там где он использовался это было ненужно.
Это раешается добавлением еще одного параметра шаблона.

class strong_typedef_tag{};//Чтобы не поломать старый код
//Хотя я бы поломал ибо работы по починке не много да и компилятор носом ткнет.
template<class T, class TAG = strong_typedef_tag> struct strong_typedef : boost::totally_ordered1< 
strong_typedef<T> >
{
...
};

class NumberOfSymbolInStringTag{};
typedef boost::strong_typedef<int, NumberOfSymbolInStringTag> NumberOfSymbolInString;

class NumberOfSymbolInTextTag{};
typedef boost::strong_typedef<int, NumberOfSymbolInTextTag> NumberOfSymbolInText;

А лишние операторы это они зря

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

C>RTTI есть в С++ уже лет 10. Reflection'а нет — это недостаток, но он и
C>не нужен.

Чую назревание священной войны... RTTI в C++ это убогая тачанка по сравнению с Дельфийским. Там даже поля и методы класса перебрать нельзя. Reflection это типа сериализации — сохранение/восстановление из потока? Ну кому как... Мне — нужен.

C>Именованые конструкторы — это фабрики, только интегрированные в язык
C>(уродство).

Обосновать бы... Вот мне лично кажется что конструктор и фабрика выполняют одни и те же функции и уродским является как раз их разделение (ибо избыточно оно).

C>Аргументы переменной длины в С++ не нужны — есть другие
C>средства (перегрузка операторов).

А с переменные аргументами всё равно часто удобнее. Классика это, конечно, форматирование строк.

// C++ - подобный (оно не скомпилируется, но важна идея!) :-)
string s;
s
  << "Фигня на постном масле = " << obj.getX() << endl
  << width(8) << precision(2) << "Она же, но на сливочном = " << obj.getX();
foo( s );

Кому как, а мне следующий вариант кажется куда как более простым и наглядным:

// C# - подобный
s = new String;
s.Format(
  "Фигня на постном масле = {0}\n"
  "Она же, но на сливочном = {0,8:p2}",
  [obj.getX()]
);
foo( s );

C>Зато в Дельфи нет: умных указателей, автоматических объектов,
C>темплейтов. Дальше можно не продолжать.

Да, там много чего нету, кто б спорил. Темплитами, кстати, почти никто похвастаться не может, кроме C++. А что подразумевается под автоматическими объектами? Которые не через new, а на стеке? Да, пожалуй, их не хватало, как и возможности определить переменную в произвольной точке. Зато в C++ не хватает вложенных функций... Вот, буквально полчаса назад жалел об этом.

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

T>Здравствуйте, Трурль, Вы писали:

Т>>

Т>>type MyType is INTEGER;
Т>>

Подзабыл я Аду. Надо было бы

type MyType is new INTEGER;

T>А может быть ещё можно как-то расширить поведение или наоборот — урезать?
Кое-что мoжно

type  SmallInt is range -1..13;
type  Byte  is mod 2 ** 8; 
type  IntMod35  is mod 35;

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

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

C>>RTTI есть в С++ уже лет 10. Reflection'а нет — это недостаток, но он и
C>>не нужен.

T>Чую назревание священной войны... RTTI в C++ это убогая тачанка по сравнению с Дельфийским. Там даже поля и методы класса перебрать нельзя. Reflection это типа сериализации — сохранение/восстановление из потока? Ну кому как... Мне — нужен.

Reflection — это как раз и есть возможность перебрать поля и методы класса.

C>>Именованые конструкторы — это фабрики, только интегрированные в язык
C>>(уродство).

T>Обосновать бы... Вот мне лично кажется что конструктор и фабрика выполняют одни и те же функции и уродским является как раз их разделение (ибо избыточно оно).

А зачем они, если вы всегда можете объвить статическую функцию в классе, которая будет создавать вам объект? По сути тоже самое

C>>Аргументы переменной длины в С++ не нужны — есть другие
C>>средства (перегрузка операторов).

T>А с переменные аргументами всё равно часто удобнее. Классика это, конечно, форматирование строк.

Не нравится не кури... или кури strintf

...

T>Да, там много чего нету, кто б спорил. Темплитами, кстати, почти никто похвастаться не может, кроме C++.
Зато шарп может ими постыдиться...

T>А что подразумевается под автоматическими объектами? Которые не через new, а на стеке?
Да — которые на стеке, причём в любом месте локальной области видимости и содержат в себе те, которые создаются динамически, причём доступ к динамическим прозрачный и они уничтожаются вместе со статическими... Имеется в виду auto_ptr...

T>Зато в C++ не хватает вложенных функций... Вот, буквально полчаса назад жалел об этом.

Зато в C++ есть локальные классы, что суть есть тоже самое, только круче, потому что они могут быть даже шаблонами и быть вложены в шаблоны...

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

T>>Например, там есть полноценная поддержка RTTI,
WH>В С++ тоже есть RTTI. Несколько скромнее чем в дельфе но есть.

Ага, несколько. "Москвич-412" он тоже несколько хуже, чем Toyota Mark II.

WH>Что касается полноценности дельфевого RTTI то у меня язык не повернется назвать его полноценным после того как я поработал с reflection'о в .NET.

Sure. Всё течёт, всё развивается, Дельфи уже устаревший язык. Но в C++ нету reflection, мы ж о нём, не о .NET?

T>>именованные конструкторы,
WH>В дельфе нет конструкторов. В дельфе есть фабрики на уровне языка.

Второй раз слышу этот тезис. Кто-нибудь мне расскажет о том, в чём концептуальной отличие фабрики от конструктора?! Вроде б и та и тот задачей ставят создание целостного объекта (банду четырёх я читал, не помогло).

T>>удобные списки аргументов переменной длины... это что в голову сходу пришло.
WH>В С++ оно тоже есть... вот только никто этим не пользуется ибо нафиг не упало.

Форматирование строк. Поточный вывод не слишком-то удобен на практике оказался, хотя концепция и реализация очень изящны. Ещё пару применений можно придумать.

WH>1)Шаблоны.
WH>2)Автоматические деструкторы.
WH>3)Перегрузка операторов.

Ага. Это здорово. Только исходное сообщение было в том духе, что "Дельфи вчистую проигрывает C++". Я и привёл пару примеров, где он выигрывает. Не заявляя об идеальности. А C++ в целом на порядок мощнее, кто б спорил — это ж целый огромный полигон для экспериментов.

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

VD>И что самое поскудное

— это же совершенно корректный код

.

Да, использование С-подобных приведений типов позволяет произвольно интерпретировать память.

Поэтому в С++ ввели дополнительные "почти безопасные" static_cast<>. Если в твоем примере использовать его, то пример не скомпилируется.

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

D>P.S. Явный вызов деструктора это клиника, я бы не назвал это корректным кодом.

Да нет, не клиника, весь STL на этом держится.

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

C>FDSC wrote:

>> C>Врет. Строковые команды еще с 486 процессора работают медленнее.
>> Минуточку. Медленнее чего? Приведи asm код, который работает быстрее,
>> или хотя бы (если лень) опиши его. Впрочем, я посмотрю VC 7, может
>> найду там что-нибудь интересное.

C>Медленнее явного цикла.

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

// Vinogradov S.V. 2005 jun.
// TestAsm.cpp. For RSDN Forum.
// Сравнение производительности цикла поиска в целочисленном массиве для C++ и asm кода.
// MS VS 7.1.3088

// Результаты (с обычным while):
//1: VC compiler: 2407 (33554431); asm: 2328 (33554431)
//2: VC compiler: 2344 (33554431); asm: 2328 (33554431)
//3: VC compiler: 2359 (33554431); asm: 2313 (33554431)
//4: VC compiler: 2359 (33554431); asm: 2312 (33554431)
//5: VC compiler: 2360 (33554431); asm: 2328 (33554431)

// Результаты (с модифицированным while):
//1: VC compiler: 1734 (33554431); asm: 2328 (33554431)
//2: VC compiler: 1656 (33554431); asm: 2329 (33554431)
//3: VC compiler: 1656 (33554431); asm: 2312 (33554431)
//4: VC compiler: 1672 (33554431); asm: 2313 (33554431)
//5: VC compiler: 1672 (33554431); asm: 2312 (33554431)


#include "stdafx.h"
#include <windows.h>
#include <conio.h>
#include <stdio.h>

int _tmain(int argc, _TCHAR* argv[])
{
    const K = 1024*1024 * 32 /* *4 = 128 Мб */;
    const MaxTestIteration = 5, MaxRepeat = 10;
    int A;
    int B = 7;
    int * C;

    int LC = 0, LA = 0;

    C = (int *) ::LocalAlloc( LPTR, K * sizeof(int) );

    if (NULL == C) return 1;
    
    C[K - 1] = B;


    SYSTEMTIME ST, ST2, ST3;
    int RepeatCount, E = 0;

    for (int iTestIteration = 0; iTestIteration++ < MaxTestIteration;)
    {

        GetSystemTime(&ST);

        // Обычный while
        /*for (RepeatCount = 0; RepeatCount++ < MaxRepeat;)
        {
            A = 0;
            while (C[A++] != B && A < K);
        }*/

            
        // Модифицированный while
        int I, T;
        for (RepeatCount = 0; RepeatCount++ < MaxRepeat;)
        {
            A = 0;
            while (C[A] != B  &&  A < K - 1023)
            {                
                for (T = 16; T < 1024; T += 16) 
                {
                    E += C[A + T];
                }
                
                I = 1;
                while (C[A + I++] != B && I < 1024);
                A += I;
                if (I < 1024 ) break;
            }
        }

        LC = A - 1;

        GetSystemTime(&ST2);

        for (RepeatCount = 0; RepeatCount++ < MaxRepeat;)
        __asm{
                pushad
                push    es                

                mov        ax,        ds
                mov        es,        ax

                mov        edi,    [C]
                mov        eax,    [B]
                CLD
                mov        edx,    edi

                mov        ecx,    [K]

                repne    scasd

                sub        edi,    edx
                shr        edi,    2
                dec        edi
                mov        [LA],    edi

                pop        es
                popad
        }

        GetSystemTime(&ST3);

        const hk = 3600*1000, mk = 60*1000, sk = 1000;
    
        int R1 = ST2.wHour * hk + ST2.wMinute * mk + ST2.wSecond * sk + ST2.wMilliseconds -
                 ST .wHour * hk - ST .wMinute * mk - ST .wSecond * sk - ST .wMilliseconds;

        int R2 = ST3.wHour * hk + ST3.wMinute * mk + ST3.wSecond * sk + ST3.wMilliseconds -
                 ST2.wHour * hk - ST2.wMinute * mk - ST2.wSecond * sk - ST2.wMilliseconds;


        printf("%i: VC compiler: %i (%i); asm: %i (%i) \n", iTestIteration, R1, LC, R2, LA);
    }

    ::LocalFree(C);
    
    printf("E = %i", E);

    getch();

    return 0;
}

Получается, что компилятор всё же не оптимизирует код как надо. См. отладчик:

A = 0;

00401070  xor         eax,eax 
            while (C[A++] != B && A < K);
00401072  mov         edx,dword ptr [esi+eax*4] 
00401075  inc         eax  
00401076  cmp         edx,7 
00401079  je          main+82h (401082h) 
0040107B  cmp         eax,2000000h 
00401080  jl          main+72h (401072h)

Стандартный код: хуже трудно сделать. Может настройки не те:
«/O2 /Ot /G6 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc /ML /GS /Yu"stdafx.h" /Fp"Release/TestAsm.pch" /Fo"Release/" /Fd"Release/vc70.pdb" /W3 /nologo /c /Wp64 /Zi /TP»?

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

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

FDS>>Нет. Компилятор должен мне вывести граф возможных ситуаций в программе, а я сам посмотрю, что можно, что нельзя.
WH>В проекте на 10 метров кода будет тАкой граф...

Чушь. Это смотря как его представить.

WH>

На gamedev.ru бал здоровый флейм на эту тему. Толпа народа пыталась обогнать интеловский
компилятор. Ни у кого не получилось даже догнать. Делай выводы.

Сделал.

FDS>>А, вот о чём! Согласен. Но в C++ нет некоторых возможностей Delphi — вот я и не могу перейти на него. Иначе бы все уже давно на Delphi плюнули.
WH>На дельфе хорошо только формочки клепать. А как язык дельфи отстает от С++ по всем параметрам.

Нет.

WH>В принципе есть тандартная связка формочки на VB6 + inproc COM cerver на С++.
WH>В место VB6 можно взять дельфи.

Жуть. Что ты предлагаешь,

!

FDS>>Попробую, когда время будет хорошо посидеть на этом. Мне тут очень квалифицированный человек говорил, что строковые команды всегда лучше. Надо будет разобратся.
FDS>>Может напишу ответ... через месяцок так...

WH>Попробуй, попробуй...

Уже. Где-то тут есть, э-э-э, чёрт, не могу найти, но точно есть ответ.

WH>А сейчас в недрах мелкософта создается очень интересный оптимизатор который можно будет расширять своими правилами.

Откуда знаешь?

S>>>Код, сгенерированный компилятором Intel, ты будешь догонять месяцами. А изучая дизассемблернуый код, будешь периодически всплескивать руками и говорить "не может быть! Это должно работать медленнее, чем у меня".
FDS>>Где это я его буду догонять, на своём AMD Athlon?
WH>Ну код интеловского компилятори и на атлонах работает не плохо...

Это было язвительно замечание.

FDS>>Много нового, насколько я помню, случилось в .NET. А в VS for Windows, если только мастера изменились. В прочем, может я что-то важное упустил?!
WH>Ну да так по мелочи... довили язык до 98%ного соответствия стандарту, улучшели оптимизатор...

А мне то что от этого. Мне наплевать... Мне не то нужно.

Здравствуйте, WolfHound.

ЧУШЬ. ЧУШь. ЧУшь. Чушь. чушь....

Умные указатели в Delphi есть, прада только в строковых типах.

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

C>Сергей Губанов wrote:

>> C>Когда же прекратят издеваться над школьниками....
>> Что Вы имеете в виду?

C>Использовать мертвые, неудобные и никому ненужные языки. Уж лучше бы
C>Питон изучали — от него хоть польза есть.

По моему над школьниками совсем не так издеваются — заставляют их делать всякую чушь.
Эта тема отдельного форума, и не на RSDN.

FDSC wrote:

>00401070 xor eax,eax
> while (C[A++] != B && A < K);
>00401072 mov edx,dword ptr [esi+eax*4]
>00401075 inc eax
>00401076 cmp edx,7
>00401079 je main+82h (401082h)
>0040107B cmp eax,2000000h
>00401080 jl main+72h (401072h)
>
> Стандартный код: хуже трудно сделать. Может настройки не те:
> «/O2 /Ot /G6 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc
> /ML /GS /Yu"stdafx.h" /Fp"Release/TestAsm.pch" /Fo"Release/"
> /Fd"Release/vc70.pdb" /W3 /nologo /c /Wp64 /Zi /TP»?

C:\temp\test\release>test.exe
1: VC compiler: 1253 (33554431); asm: 1001 (33554431)
2: VC compiler: 1002 (33554431); asm: 1012 (33554431)
3: VC compiler: 1008 (33554431); asm: 1002 (33554431)
4: VC compiler: 1002 (33554431); asm: 1012 (33554431)
5: VC compiler: 1055 (33554431); asm: 1041 (33554431)
E = 0

Ассемблерный код писать не буду — они там циклы раскатал. Компилятор:
Intel 8.1, процессор: Intel Pentium M 1.8GHz.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

WH>>В С++ тоже есть RTTI. Несколько скромнее чем в дельфе но есть.
T>Ага, несколько. "Москвич-412" он тоже несколько хуже, чем Toyota Mark II.
А что такого крутого в дельфийском RTTI? Возможность перебрать свойства в published секции?

Вот только толку от этого мало.
А учитывая что в следующем стандарте наверняка появится compile time reflection то дельфя будет мягко говоря нервно курить в углу.
Хотя скорее всего она не доживет ибо ее убъет .НЕТ

T>Второй раз слышу этот тезис. Кто-нибудь мне расскажет о том, в чём концептуальной отличие фабрики от конструктора?! Вроде б и та и тот задачей ставят создание целостного объекта (банду четырёх я читал, не помогло).
Ты вобще понимаешь механику работы конструкторов/деструкторов в С++?

T>Форматирование строк. Поточный вывод не слишком-то удобен на практике оказался, хотя концепция и реализация очень изящны. Ещё пару применений можно придумать.
Смотри boost::format

    cout << format("%1% %2% %3% %2% %1% \n") % "o" % "oo" % "O";
    //          prints  "o oo O oo o \n"

T>Ага. Это здорово. Только исходное сообщение было в том духе, что "Дельфи вчистую проигрывает C++". Я и привёл пару примеров, где он выигрывает. Не заявляя об идеальности. А C++ в целом на порядок мощнее, кто б спорил — это ж целый огромный полигон для экспериментов.
Угу. Вот только на дельфевем RTTI далеко не уедешь, фабрики нужны гораздо реже чем полноценные конструкторы к томуже фабрику легко написать, а вот сэмулировать конструктор на дельфе

, переменное число параметров нафиг не упало см выше.
ИТОГО: Отсутствие необходимых инструментов компенсируется парой сомнительных фичек

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

FDS>ЧУШЬ. ЧУШь. ЧУшь. Чушь. чушь....
Аргументы будут?

FDS>Умные указатели в Delphi есть, прада только в строковых типах.
А толку? Умные указатели нужны везде. Только строки меня не устраивают.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>>В проекте на 10 метров кода будет тАкой граф...

FDS>Чушь. Это смотря как его представить.
Да хоть как ты его представляй. Всеравно утонешь в тысячах классов.

WH>>На дельфе хорошо только формочки клепать. А как язык дельфи отстает от С++ по всем параметрам.
FDS>Нет.
Поработай с мое на разных языках и платвормах...

WH>>В принципе есть тандартная связка формочки на VB6 + inproc COM cerver на С++.
WH>>В место VB6 можно взять дельфи.
FDS>Жуть. Что ты предлагаешь,

!
Во многих приложениях гуи это просто куча несложных формочек. VB и дельфя с формочками хорошо справляются, а вот с написанием кода лучше справляется С++.
А для тех приложений где нужен действительно сложный ГУИ то тут C++ с WTL рулят со страшной силой. Никакая дельфя с ее убогим VCL рядом не валялась ибо VCL это шаг в право, шаг в лево расстрел без права переписки.
Вот например я сейчас создаю собственную систему ГУИ ибо WInForm который очень сильно похож на VCL с задачами не справляется.

WH>>А сейчас в недрах мелкософта создается очень интересный оптимизатор который можно будет расширять своими правилами.
FDS>Откуда знаешь?
http://research.microsoft.com/phoenix/

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

FDSC wrote:

> ЧУШЬ. ЧУШь. ЧУшь. Чушь. чушь....
> Умные указатели в Delphi есть, прада только в строковых типах.

Шутка дня.

Читать здесь: http://en.wikipedia.org/wiki/Smart_pointer и по ссылкам.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

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

C>>Сергей Губанов wrote:

>>> C>Когда же прекратят издеваться над школьниками....
>>> Что Вы имеете в виду?

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

Это Вы про устаревший Turbo Pascal? Согласен, не надо больше так издеваться. Пора учить современный живой удобный нужный Component Pascal.

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

FDS>>Умные указатели в Delphi есть, прада только в строковых типах.
WH>А толку? Умные указатели нужны везде. Только строки меня не устраивают.
А мне умные указатели не нужны нигде.

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

FDS> ...или, вообще, придумать другой язык... Чтоб ошибок в 100 раз меньше было, ведь от средства разработки то же многое зависит.

Такой язык есть — Оберон

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

FDS>>>Умные указатели в Delphi есть, прада только в строковых типах.
WH>>А толку? Умные указатели нужны везде. Только строки меня не устраивают.
Т>А мне умные указатели не нужны нигде.
Есть всего 3 врианта
1)ГЦ. В дельфе нет.
2)Умные указатели. В дельфе нет.
3)Озвереешь ловить утечки памяти. В дельфе...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Сергей Губанов wrote:

> C>>Использовать мертвые, неудобные и никому ненужные языки.
> Это Вы про устаревший Turbo Pascal? Согласен, не надо больше так
> издеваться. Пора учить современный живой удобный нужный Component Pascal.

К сожалению, он не живой, ни удобный, ни современный.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Сергей Губанов wrote:

> FDS> ...или, вообще, придумать другой язык... Чтоб ошибок в 100 раз
> меньше было, ведь от средства разработки то же многое зависит.
> Такой язык есть — Оберон
> <http://rsdn.ru/Forum/Message.aspx?mid=1221310&only=1>

Let the flame begin!

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Это Вы про устаревший Turbo Pascal? Согласен, не надо больше так издеваться. Пора учить современный живой удобный нужный Component Pascal.

А у меня мелькнула мысль: а зачем их учить какому-то языку? Им бы русский выучить, и то хорошо.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

D>P.S. Явный вызов деструктора это клиника, я бы не назвал это корректным кодом.
И будем хранить большие коллекции объектов в стеке?

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

VD>>Там компилятор был не причем. Там были махинации со своим пулом памяти и вручную вызывались деструкторы. Конструктор же вызывался дважды из-за прохода по памяти в одном из деструкторов (или еще где... уже не помню).

WH>Те наплевал на все защиты С++, что-то наворотил шаловливыми ручками, а С++ виноват? Прэлесно!

Все в рамках правил языка. В общем, не фига — не фига. Это у вас, доктор, картиночки такие...

Если эти возможности в языке не нужны, тогда что они в нем делают? И зачем были включены?

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

WH>И что это доказывает? В C# тоже можно написать unsafe и натворить тАкое

Ну, справидливости ради в C#, да и в любом дотнетом языке тот же диспоз можно вызывать хоть до посинения. Но его и проектируют так чтобы это проблем не вызвало.

А главное, что если то, то тебя остановит контроль типов. Что же до ансэйва, то лично я его не применяю. Думаю ты тоже. Он очень хорошо выделен. Прибегая к нему ты идешь на обдуманный риск и всячески это демонстрируешь... в отличии от...

WH>Если начал приводить что попало к чему попало, вызывать деструкторы руками так сам себе злобный буратино.

Не, не. Не надо грязи. Я в начале сказал о совершенно реальной ситуаци где меня привлекли для поиска "очень странной ошибки". Причем те кто ее реально создал отнюдь не выпендривались и не ламерили по чем зря.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

D>Страуструп говорит про такие случаи приблизительно так: C++ (в отличии от C89/-) защищает от случайного допущения ошибки, но не от преднамеренного жульничества.

Это С++ то защищаеть от случайных ошибок?

D>P.S. Явный вызов деструктора это клиника, я бы не назвал это корректным кодом.

Клиника это язык в котором такое море граблей. По сему добрую половину (а то и больше) С++-ного кода не удается назвать корректным кодом.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>Да, использование С-подобных приведений типов позволяет произвольно интерпретировать память.

В моем примере приведение типов нужно постольку по скольку. Дело не в нем.

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

V>Поэтому в С++ ввели дополнительные "почти безопасные" static_cast<>. Если в твоем примере использовать его, то пример не скомпилируется.

Очень верно, что слова "почти безопасные" ты взял в ковычки.

Потому как это тоже самое что "чуть-чуть беременная". Нет никаких проблем натварить любого бреда и со static_cast-ами:

for (int i = 0; i < 10; i++)
    static_cast<A*>(static_cast<void*>(&i))->~A();

Этот код скопилируется без броблем. А по стути он аналогичен предыдущему.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>Все в рамках правил языка. В общем, не фига — не фига. Это у вас, доктор, картиночки такие...
Хочешь я сейчас в шарпе напишу unsafe и все уроню? Короче завязывай с демогогией. Та ЯВНО обошол защиту, ты ЯВНО вызвал деструктор.
VD>Если эти возможности в языке не нужны, тогда что они в нем делают? И зачем были включены?
Они иногда нужны. Например подобные фокусы используются при реализации контейнеров в STL.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

VD>Ну, справидливости ради в C#, да и в любом дотнетом языке тот же диспоз можно вызывать хоть до посинения. Но его и проектируют так чтобы это проблем не вызвало.
А если его спроектируют по другому?
К томуже диспос работает несколько иначе чем деструктор.
VD>А главное, что если то, то тебя остановит контроль типов. Что же до ансэйва, то лично я его не применяю. Думаю ты тоже. Он очень хорошо выделен. Прибегая к нему ты идешь на обдуманный риск и всячески это демонстрируешь... в отличии от...
Тут ты тоже явно обошол защиту. Так что...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Хочешь я сейчас в шарпе напишу unsafe и все уроню? Короче завязывай с демогогией. Та ЯВНО обошол защиту, ты ЯВНО вызвал деструктор.

Ты оп осторожнее с ярлычками вроде демоггии. Прочитай еще раз ветку. Я заранее сказал, что "в безопасном режиме Шарпа и Яве (где другого режима нет)...".

Ансэйф режим для хаков и введен. Но это не означает, что весь язык должен быть одним большим ансэйвом (хаком).

VD>>Если эти возможности в языке не нужны, тогда что они в нем делают? И зачем были включены?
WH>Они иногда нужны. Например подобные фокусы используются при реализации контейнеров в STL.

Думаю ты представляшь как на том же Шарпе в безопасном режиме написать очень даже эффективный контейнер. Значит таки можно жить без хаков на каждом шагу? А ведь чем человек не опытнее, тем его больше тянет на подвиги. И без разумного контроля — это приводит к очень неприятным резултатам.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>>Ну, справидливости ради в C#, да и в любом дотнетом языке тот же диспоз можно вызывать хоть до посинения. Но его и проектируют так чтобы это проблем не вызвало.
WH>А если его спроектируют по другому?

То будут проблемы. Но это будет нарушение паттерна, а не хитрое использование возможностей языка. Да и проблемы будут куда более просто локализуемы.

WH>К томуже диспос работает несколько иначе чем деструктор.

Да зачастую смысло то их существования один и тот же.

VD>>А главное, что если то, то тебя остановит контроль типов. Что же до ансэйва, то лично я его не применяю. Думаю ты тоже. Он очень хорошо выделен. Прибегая к нему ты идешь на обдуманный риск и всячески это демонстрируешь... в отличии от...
WH>Тут ты тоже явно обошол защиту. Так что...

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

C>FDSC wrote:

>>00401070 xor eax,eax
>> while (C[A++] != B && A < K);
>>00401072 mov edx,dword ptr [esi+eax*4]
>>00401075 inc eax
>>00401076 cmp edx,7
>>00401079 je main+82h (401082h)
>>0040107B cmp eax,2000000h
>>00401080 jl main+72h (401072h)
>>
>> Стандартный код: хуже трудно сделать. Может настройки не те:
>> «/O2 /Ot /G6 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /FD /EHsc
>> /ML /GS /Yu"stdafx.h" /Fp"Release/TestAsm.pch" /Fo"Release/"
>> /Fd"Release/vc70.pdb" /W3 /nologo /c /Wp64 /Zi /TP»?

C>

C>C:\temp\test\release>test.exe
C>1: VC compiler: 1253 (33554431); asm: 1001 (33554431)
C>2: VC compiler: 1002 (33554431); asm: 1012 (33554431)
C>3: VC compiler: 1008 (33554431); asm: 1002 (33554431)
C>4: VC compiler: 1002 (33554431); asm: 1012 (33554431)
C>5: VC compiler: 1055 (33554431); asm: 1041 (33554431)
C>E = 0

C>Ассемблерный код писать не буду — они там циклы раскатал. Компилятор:
C>Intel 8.1, процессор: Intel Pentium M 1.8GHz.

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

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

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

FDS>>>>Умные указатели в Delphi есть, прада только в строковых типах.
WH>>>А толку? Умные указатели нужны везде. Только строки меня не устраивают.
Т>>А мне умные указатели не нужны нигде.
WH>Есть всего 3 врианта
WH>1)ГЦ. В дельфе нет.
WH>2)Умные указатели. В дельфе нет.
WH>3)Озвереешь ловить утечки памяти. В дельфе...

Не бывает в Delphi утечек памяти. Там всё равно всё освобождается.
А вот деструктор можно и забыть вызвать.

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

C>FDSC wrote:

>> ЧУШЬ. ЧУШь. ЧУшь. Чушь. чушь....
>> Умные указатели в Delphi есть, прада только в строковых типах.

C>

Шутка дня.

C>Читать здесь: http://en.wikipedia.org/wiki/Smart_pointer и по ссылкам.

Прочитал. Ну и что? ANSIString и т.д. типичные Smart pointer.

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

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

WH>>>В проекте на 10 метров кода будет тАкой граф...

FDS>>Чушь. Это смотря как его представить.
WH>Да хоть как ты его представляй. Всеравно утонешь в тысячах классов.

Граф можно представлять частями и т.п. Не надо мне говорить, что я утону — я видел прототип.

WH>А для тех приложений где нужен действительно сложный ГУИ то тут C++ с WTL рулят со страшной силой. Никакая дельфя с ее убогим VCL рядом не валялась ибо VCL это шаг в право, шаг в лево расстрел без права переписки.

Поверю наслово.

WH>>>А сейчас в недрах мелкософта создается очень интересный оптимизатор который можно будет расширять своими правилами.
FDS>>Откуда знаешь?
WH>http://research.microsoft.com/phoenix/

Спасибо.

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

GZ>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Это Вы про устаревший Turbo Pascal? Согласен, не надо больше так издеваться. Пора учить современный живой удобный нужный Component Pascal.

GZ>А у меня мелькнула мысль: а зачем их учить какому-то языку? Им бы русский выучить, и то хорошо.

Истина в первой инстанции.

Приговор окончателен. Обжалыванию не подлежит. Заседание и дело объявляю закрытым.

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

WH>3)Озвереешь ловить утечки памяти. В дельфе...

Кстати, не то чтобы дофига.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

Здравствуйте, Sinclair, Вы писали:
S>...

Все же специалист на конкретном железе всегда сделает программу.

S>Что это означает? Что асм применяют сейчас почти только те, кто пользуется некачественным компилятором. Ребята, возьмите нормальный компайлер. Это сэкономит вам сотни часов бессмысленно потраченного времени.

А вот с этим согласен. Все же тратить свою жизнь на борьбу с битами глупо.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

C>RTTI есть в С++ уже лет 10. Reflection'а нет — это недостаток, но он и
C>не нужен.

Так недостаток или не нужен?

Если серьезно, то главное приемущество Дельфи — это то что это был компонетный язык. Ну, возможно есть.

C>Именованые конструкторы — это фабрики, только интегрированные в язык
C>(уродство).

Ага. А if, for, switch это просто немного улучшенные макросы MASM-а.

C> Аргументы переменной длины в С++ не нужны

Действительно. Нафиг они если можно просто по памяти жахнуь?

C>- есть другие
C>средства (перегрузка операторов).

Да, да. Потом ожно про эффетивность поговрить... про инлайникнг. А тем временем удивляться почему:

printf("%d", myDoubleVar);

дает странные результаты.

C>Зато в Дельфи нет: умных указателей, автоматических объектов,
C>темплейтов. Дальше можно не продолжать.

Мама купит мне казу я тебе не показу. Спорьте музчины.

ЗЫ

Ночилась эра и дельфи и плюсов. Кто не спрятался... я не виноват.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

T>Reflection это типа сериализации — сохранение/восстановление из потока? Ну кому как... Мне — нужен.

Куль! И мне такой... травы.

T>Кому как, а мне следующий вариант кажется куда как более простым и наглядным:

T>

T>// C# - подобный
T>s = new String;
T>s.Format(
T>  "Фигня на постном масле = {0}\n"
T>  "Она же, но на сливочном = {0,8:p2}",
T>  [obj.getX()]
T>);
T>foo( s );
T>

Однако не вооруженным взглядом ясно, что Дельфи (8) рулит.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

WH>>>В С++ тоже есть RTTI. Несколько скромнее чем в дельфе но есть.
T>>Ага, несколько. "Москвич-412" он тоже несколько хуже, чем Toyota Mark II.
WH>А что такого крутого в дельфийском RTTI? Возможность перебрать свойства в published секции?

Ну, почему только свойства? И почему только в паблишь?

WH>Вот только толку от этого мало.

О... Это называется компонентным программированием. Это то что даже с мидлом и разными утилитами на С++ выглядит полной задницей. Если бы Страуструп был несколько дальновднее...

WH>А учитывая что в следующем стандарте наверняка появится compile time reflection

Гы. Мечтать не вредно. Боюсь, что в следующем стандарте будет еще больше расуждений о том, что все проблемы лучше решать в библиотеках.

WH> то дельфя будет мягко говоря нервно курить в углу.

Да, оно давно присоседилось к дотнету и курит в середине комнаты.

WH>Хотя скорее всего она не доживет ибо ее убъет .НЕТ

Тяжело умереть от собственного рантайма.

WH>Ты вобще понимаешь механику работы конструкторов/деструкторов в С++?

В дельфи конструктор действительно круче. А деструкторы... Да кому они теперь нужны?

WH>ИТОГО: Отсутствие необходимых инструментов компенсируется парой сомнительных фичек

Хорошая фраза. Подставляшь любое средство разработки и оно остаетвя в силе.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

FDS>>Умные указатели в Delphi есть, прада только в строковых типах.
WH>А толку? Умные указатели нужны везде. Только строки меня не устраивают.

Ты вот сейчас на дотнете пишешь. Так? И часто тебенужны умные указатели?

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

WH>Есть всего 3 врианта
WH>1)ГЦ. В дельфе нет.

Эта... ты ничего не путашь? Купи на досуге диск с современной дельфёй.

WH>3)Озвереешь ловить утечки памяти. В дельфе...

Это есть везде. Вот только в С++ чувствуется острее всего.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

>> C>>Использовать мертвые, неудобные и никому ненужные языки.
>> Это Вы про устаревший Turbo Pascal? Согласен, не надо больше так
>> издеваться. Пора учить современный живой удобный нужный Component Pascal.

C>К сожалению, он не живой, ни удобный, ни современный.

Тю... всего три недостатка?

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, FDSC, Вы писали:

FDS>> ...или, вообще, придумать другой язык... Чтоб ошибок в 100 раз меньше было, ведь от средства разработки то же многое зависит.

СГ>Такой язык есть — Оберон

Ну понеслась не скажу что по кочкам... А я то всё ждал, когда это слово вновь упомянут!

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

VD>Ты оп осторожнее с ярлычками вроде демоггии. Прочитай еще раз ветку. Я заранее сказал, что "в безопасном режиме Шарпа и Яве (где другого режима нет)...".
VD>Ансэйф режим для хаков и введен. Но это не означает, что весь язык должен быть одним большим ансэйвом (хаком).
Ты всетки объясни мне какая разница между ЯВНЫМ обходом тапизации и unsafe.

VD>Думаю ты представляшь как на том же Шарпе в безопасном режиме написать очень даже эффективный контейнер.
Для value типов нет.
VD>Значит таки можно жить без хаков на каждом шагу?
Так ведь и в С++ нормальные люди без хаков живут. А те хаки которые есть скрыты под мощьной защитой.
VD>А ведь чем человек не опытнее, тем его больше тянет на подвиги. И без разумного контроля — это приводит к очень неприятным резултатам.

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

VD>Эта... ты ничего не путашь? Купи на досуге диск с современной дельфёй.
Толку то от этой дельфи... какой смысл ее использовать? В лучшем случае ее ожидает судьба J#'а.

VD>Это есть везде. Вот только в С++ чувствуется острее всего.

Я знаю ты мне не веришь но у меня их нет. Что я делаю не так?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>>Тут ты тоже явно обошол защиту. Так что...
VD>Какую?
Дурака выключи.
VD>Я просто пользовался штатными возможностями языка.
unsafe тоже вполне себе штатная возможность языка.
VD>Более того, так как язык не позволяет автоматически управлять памятью, я буду вынужден писать подобный код реализуя свои контейнеры. И мест для ошибок приводящих к очень неприятным последствиям тут хоть отбавляй. И все в следствии дизайна языка.
1)Контейнеры уже давно написаны.
2)Контейнеры должны писать опытные люди. Если опыта не хватает то надо использовать STL.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

FDS>Не бывает в Delphi утечек памяти. Там всё равно всё освобождается.

Вероятно, при завершении приложения? Так это заслуга исключительно Винды

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

WH>1)ГЦ. В дельфе нет.
WH>2)Умные указатели. В дельфе нет.
WH>3)Озвереешь ловить утечки памяти. В дельфе...

4) Аккуратное программирование. В конце-концов, создавать объект приписывая к нему try-finally и писать в деструкторе уничтожение всего вложенного не так уж трудно — я быстро привык

Однако, 1 или 2 поприятнее, да.

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

MN>Reflection — это как раз и есть возможность перебрать поля и методы класса.

Ага, я уже просветился, спасибо

Под RTTI я подразумевал RTTI+Reflection (положа руку на сердце — это разные части одного и того же).

MN>А зачем они, если вы всегда можете объвить статическую функцию в классе, которая будет создавать вам объект? По сути тоже самое

Вот-вот. Есть конструктор, есть статическая функция-фабрика — а делают одно и то же. То что в Delphi их объединили в одно понятие мне нравится.

T>>А с переменные аргументами всё равно часто удобнее. Классика это, конечно, форматирование строк.
MN>Не нравится не кури... или кури strintf

...

Там правильно смайлик стоит.

Его и курю, за неимением лучшего, но пару раз накалывался на несоответствии типа... я — пару раз, в силу въедливости, а коллеги чаще. Правда тут подсказали с boost::format познакомиться...

T>>Да, там много чего нету, кто б спорил. Темплитами, кстати, почти никто похвастаться не может, кроме C++.
MN>Зато шарп может ими постыдиться...

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

T>>Зато в C++ не хватает вложенных функций... Вот, буквально полчаса назад жалел об этом.

MN>Зато в C++ есть локальные классы, что суть есть тоже самое, только круче, потому что они могут быть даже шаблонами и быть вложены в шаблоны...

Ага, мне уже приелась эта новомодная заморочка — в ответ на "хотелось бы немножко эту функцию улучшить" отвечают "а ты сделай из функции класс; а лучше — два". Хотя нужна-то мне функция.

tarkil wrote:

> T>>Зато в C++ не хватает вложенных функций... Вот, буквально полчаса
> назад жалел об этом.
> MN>Зато в C++ есть локальные классы, что суть есть тоже самое, только
> круче, потому что они могут быть даже шаблонами и быть вложены в
> шаблоны...
> Ага, мне уже приелась эта новомодная заморочка — в ответ на "хотелось
> бы немножко эту функцию улучшить" отвечают "а ты сделай из функции
> класс; а лучше — два". Хотя нужна-то мне функция.

void func()
{
    struct
    {
       void operator ()(int a, int b)
       {
          ....
       }
    } inner;

    inner(1,2);
}

Чем не функция?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

T>4) Аккуратное программирование. В конце-концов, создавать объект приписывая к нему try-finally и писать в деструкторе уничтожение всего вложенного не так уж трудно — я быстро привык

Однако, 1 или 2 поприятнее, да.
Весьма хреновый выход ибо если надо создать несколько объектов причем конструктор каждого из них может кинуть искольчение...
disclaimer: на дельфе не писал очень давно.

begin
    obj1 := SomeClass.Create;
    try
    begin
        obj2 := SomeClass.Create;
        try
        begin
            obj3 := SomeClass.Create;
            try
            begin
...
            end
            finally
            begin
                obj3.Free();
            end
        end
        finally
        begin
            obj2.Free();
        end
    end
    finally
    begin
        obj1.Free();
    end
end;

Или тоже самое на С++

{
    SomeClass obj1;
    SomeClass obj2;
    SomeClass obj3;
}

или если хочется создать все в динамической памяти то так

{
    SmartPtr<SomeClass> obj1 = new SomeClass();
    SmartPtr<SomeClass> obj2 = new SomeClass();
    SmartPtr<SomeClass> obj3 = new SomeClass();
}

Думаю бъяснения почему второй вариант лучше излишне.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Ты всетки объясни мне какая разница между ЯВНЫМ обходом тапизации и unsafe.

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

WH>Так ведь и в С++ нормальные люди без хаков живут. А те хаки которые есть скрыты под мощьной защитой.

мощная защита? Расскажи плиз, я просто умираю от любопытства.

WH>Последствия конечно будут не столь разрушительны как на С++ но легче от этого не становится.

Как это не становится?

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

Д>разница в том, что все блоки unsafe находятся с помощью простого текстовго поиска по файлам проекта. При желании эту возможность можно вобще запретить.
Д>Мне чертовски интересно узнать, как ты будешь контролировать нарушения типизации в проекте, над которым работают десятки людей.
codereview в любом случае нужен.

WH>>Так ведь и в С++ нормальные люди без хаков живут. А те хаки которые есть скрыты под мощьной защитой.
Д>мощная защита? Расскажи плиз, я просто умираю от любопытства.
Ну попробуй взломать STL'ный контейнер без явных хаков.

WH>>Последствия конечно будут не столь разрушительны как на С++ но легче от этого не становится.
Д>Как это не становится?

Да вот так. Пользователю без разници свалилось приложение по AV или по NullReferenceException захватив с собой все что сделал пользователь.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>А что такого крутого в дельфийском RTTI? Возможность перебрать свойства в published секции?

WH>Вот только толку от этого мало.

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

(hint: я, наверное, употребил в прошлый раз термин RTTI немного не в общепринятом смысле, включая в него и reflection).

WH>Хотя скорее всего она не доживет ибо ее убъет .НЕТ

Я думаю так и будет. Но мы же о прошлом, не о будущем, правда? Сегодня у Дельфи уже нет преимуществ перед C#... что и закономерно, учитывая, что у них один создатель, правда?

T>>Второй раз слышу этот тезис. Кто-нибудь мне расскажет о том, в чём концептуальной отличие фабрики от конструктора?! Вроде б и та и тот задачей ставят создание целостного объекта (банду четырёх я читал, не помогло).
WH>Ты вобще понимаешь механику работы конструкторов/деструкторов в С++?

Прекрасно понимаю. Только "конструктор в C++" и "конструктор вообще" суть разные вещи. Задача конструктора — сконструировать экземпляр класса, "по-моему так" (c) Винни-Пух. Если не прав — поправляйте (ссылка на источник строго приветствуется, но и без неё покатит). И конструктор C++ и конструктор Дельфи и "фабричный метод" конструируют экземпляр класса. В общем случае, я бы выделил в этом процессе две стадии:

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

2. Собственно, конструирование. Это то, что в C++ предлагается выносить в особые фабрики. Произвольный код для окончательного построения класса. Виртуальные функции работают правильно — вызывая самого нижнего потомка, где они переопределены.

Достоинство дельфийских конструкторов в том, что они совмещают обе этих стадии, а беда — что не разделяют их чётко.

Любителям обызывать конструкторы Дельфи недофабриками напомню, что есть масса народа, которая конструкторы C++ обызвает инициализаторами и сокрушается "а вот если бы там были настоящие конструкторы..."

WH>Смотри boost::format

Гляну. Но я прямо сейчас могу сказать, что там рожается >=4 временных объектов, которые постепенно накапливают все необходимые форматные параметры. Лишнее копирование, лишние классы. Нет, оно работает, верю, только решение с одной функцией, получающей форматную строку и массив параметров куда проще и понятней. Я ж говорю, что C++ это мощный экспериментальный полигон, где забабахать почти любую вещь можно.

WH>Угу. Вот только на дельфевем RTTI далеко не уедешь, фабрики нужны гораздо реже чем полноценные конструкторы к томуже фабрику легко написать, а вот сэмулировать конструктор на дельфе

Расшифруйте термин "полноценный конструктор", pls. Пока мне Дельфийские конструкторы кажутся более полноценными (хоть и более опасными).

WH>переменное число параметров нафиг не упало см выше.

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

В Дельфи просто: getMax( [a, b, c, d] ). В C++ нужна вторая строчка:

type tmp[] = (a, b, c, d);
getMax( tmp, tmp + sizeofa(tmp) ); // следуя стилю STL с итератором начала и конца; sizeofa(x) = sizeof x/sizeof x[0]

WH>ИТОГО: Отсутствие необходимых инструментов компенсируется парой сомнительных фичек

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

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

WH>codereview в любом случае нужен.

вопрос только — насколько нужен. Обнаружить, кому давать по балде за несанкционированное применение unsafe, можно почти без усилий

А искать нарушение правил приведения типов ты как будешь? Просматривать код файл за файлом?

WH>Ну попробуй взломать STL'ный контейнер без явных хаков.

что значит — "взломать"? Поконкретнее, пожалуйста.

WH>Да вот так. Пользователю без разници свалилось приложение по AV или по NullReferenceException захватив с собой все что сделал пользователь.

Ну во первых — NullReferenceException говорит только о логической ошибке, и в большинстве случаев он не мешает продолжать работу проги. Как минимум — освободить все взятые ресурсы. Если произойдет AV, никакая работа приложения уже невозможна.
Во вторых — рассмотрим программирование серверов приложений. Одно дело, когда один клиент получил сообщение об ошибке. Другое дело — когда сервер с треском упал и все сеансы работы умерли. Есть все-таки разница, не правда ли?

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

C>

C>void func()
C>{
C>    struct
C>    {
C>       void operator ()(int a, int b)
C>       {
C>          ....
C>       }
C>    } inner;

C>    inner(1,2);
C>}
C>

C>Чем не функция?

Самого главного не хватает — возможности обращаться к локальным переменным func'а.

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

WH>Думаю бъяснения почему второй вариант лучше излишне.

Читаем внимательнее: Однако, 1 или 2 поприятнее, да. Могу ещё добавить слово "намного".

Дарней wrote:

> WH>Да вот так. Пользователю без разници свалилось приложение по AV или
> по NullReferenceException захватив с собой все что сделал пользователь.
> Ну во первых — NullReferenceException говорит только о логической
> ошибке, и в большинстве случаев он не мешает продолжать работу проги.
> Как минимум — освободить все взятые ресурсы. Если произойдет AV,
> никакая работа приложения уже невозможна.

С использованием SEH — вполне возможна, лично такое писал.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

tarkil wrote:

>C>void func()
>C>{
>C> struct
>C> {
>C> void operator ()(int a, int b)
>C> {
>C> ....
>C> }
>C> } inner;
>
>C> inner(1,2);
>C>}
>C>
>
> C>Чем не функция?
> Самого главного не хватает — возможности обращаться к локальным
> переменным func'а.

Можно, хотя и немного сложнее.

void func()
{
    int var=...;
    struct
    {
       int &var;
       void operator ()(int a, int b)
       {
          ....
       }
    } inner={var};

    inner(1,2);
}

С небольшой долей фантазии можно сделать и closure'ы.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>С использованием SEH — вполне возможна, лично такое писал.

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

Дарней wrote:

> C>С использованием SEH — вполне возможна, лично такое писал.
> Я в курсе, что возможна.
> Только имеет ли смысл работа с данными, которые (вероятно) повреждены
> проходом по памяти?

Физически разделять данные на разные домены, находящиеся в разных
приватных кучах. Так по жизни делают unmanaged сервера приложений типа
MTS или реализаций CORBA.

> Если в обработчике SEH делаются любые операции с бизнес-данными — то
> за такие фокусы разработчика надо кастрировать и повесить на входной
> двери офиса, чтобы не распространял свой генофонд.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

C>Можно, хотя и немного сложнее.

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

C>С небольшой долей фантазии можно сделать и closure'ы.

Как-как ты сматерился?

tarkil wrote:

> C>Можно, хотя и немного сложнее.
> Так это почти то же, что и передать ссылки на переменные параметрами
> operator(). Энто ж самое главное западло — что их все перечислять надо
> тем или иным способом и никуда не сбежишь от этого. А перечислять-то и
> не хочется.

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

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

> C>С небольшой долей фантазии можно сделать и closure'ы.
> Как-как ты сматерился?

http://en.wikipedia.org/wiki/Closure_%28computer_science%29

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

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

T>>4) Аккуратное программирование. В конце-концов, создавать объект приписывая к нему try-finally и писать в деструкторе уничтожение всего вложенного не так уж трудно — я быстро привык

Однако, 1 или 2 поприятнее, да.
WH>Весьма хреновый выход ибо если надо создать несколько объектов причем конструктор каждого из них может кинуть искольчение...
WH>disclaimer: на дельфе не писал очень давно.
WH>

WH>begin
WH>    obj1 := SomeClass.Create;
WH>    try
WH>    begin
WH>        obj2 := SomeClass.Create;
WH>        try
WH>        begin
WH>            obj3 := SomeClass.Create;
WH>            try
WH>            begin
WH>...
WH>            end
WH>            finally
WH>            begin
WH>                obj3.Free();
WH>            end
WH>        end
WH>        finally
WH>        begin
WH>            obj2.Free();
WH>        end
WH>    end
WH>    finally
WH>    begin
WH>        obj1.Free();
WH>    end
WH>end;
WH>

А теперь то же самое руками квалифицированного девелопера:

  obj1:= nil;
    obj2:= nil;
    obj3:= nil;
    try
        obj1 := SomeClass.Create;
    obj2 := SomeClass.Create;
    obj3 := SomeClass.Create;
  finally
    FreeAndNil(obj3);
    FreeAndNil(obj2);
    FreeAndNil(obj1);
  end

Здесь мы пользуемся тем, что вызов Free на nil безопасен. Поэтому в какой бы момент ни было брошено исключение, finally отработает корректно.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

S>Здесь мы пользуемся тем, что вызов Free на nil безопасен. Поэтому в какой бы момент ни было брошено исключение, finally отработает корректно.
В любом случае на С++ короче и безопеснее ибо контролирует компилятор.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

VD>>Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов.

Д>Будут проблемы со срезкой.

С чего бы?
Единственный, как бы, недостаток состоит в том, что переменная на 4 байта больше (чтобы хранить тэг типа).

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

WH>Толку то от этой дельфи... какой смысл ее использовать? В лучшем случае ее ожидает судьба J#'а.

Цитирую:

1)ГЦ. В дельфе нет.

Надо объяснять насколько ты заблуждаешся?

VD>>Это есть везде. Вот только в С++ чувствуется острее всего.

WH>Я знаю ты мне не веришь но у меня их нет. Что я делаю не так?

Все у тебя есть. Ты сам говоришь насколько быстрее программировать на Шарпе. Так вот отсуствие траха с "этим" — это очень некислая часть того самого ускорения.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

WH>codereview в любом случае нужен.

Ага. И юнит-тесты. Где-то я это уже слышал.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

WH>>>Тут ты тоже явно обошол защиту. Так что...
VD>>Какую?
WH>Дурака выключи.

Что за мовитон Шура? Я вас умоляю...

И все же какая такая защита у нас появилась в плюсах?

WH>1)Контейнеры уже давно написаны.

Все? Как бежит время...

WH>2)Контейнеры должны писать опытные люди. Если опыта не хватает то надо использовать STL.

И СТЛ должны использовать опытные люди. Да и опытным людям нужны разные костыли вроде баунд-чекеров. И все по причине зелания жить на грани крутизны.

Не, спасибо, я пешком постаю.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

C>Физически разделять данные на разные домены, находящиеся в разных
C>приватных кучах. Так по жизни делают unmanaged сервера приложений типа
C>MTS или реализаций CORBA.

от прохода по памяти это все равно не спасет

C>В обработчике SEH можно поставить сохранение данных и попытку
C>самовосстановления. Естественно, надо сделать так, чтобы не испортились
C>существующие записи.

А как ты определишь. какие данные повреждены а какие нет?

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

VD>Очень верно, что слова "почти безопасные" ты взял в ковычки.

Потому как это тоже самое что "чуть-чуть беременная". Нет никаких проблем натварить любого бреда и со static_cast-ами:
VD>

VD>for (int i = 0; i < 10; i++)
VD>    static_cast<A*>(static_cast<void*>(&i))->~A();
VD>

VD>Этот код скопилируется без броблем. А по стути он аналогичен предыдущему.

Да, хак статик-каста через void известен, как и то, что это именно хак. Любые compile-time приведения через void* потенциально опасны ввиду нарушения адресной арифметики.

Мне напомнить про то, что я могу в unsafe режиме в донете и не такое сделать непосредственно в рамках C#?

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

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

Знаю, что ты давно пересел на 2.0, но у нас коммерческие проекты, и они, разумеется, на 1.1. И сильной статической типизации плюсов порой ой как не хватает.

Для того, чтобы избежать "обезличенных" сигнатур, типа

Method1(int, int);
Method2(object, object);

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

Например.

public enum ObjectIdT { eNoObject };

— пустой енум, мы его используем как типизированный int, используя весь диапазон int-значений. Это немного неккоректно, зато помогло найти несколько ошибок, при добавлении типизации в метод:

Method1(ObjectIdT, int);

C object — та же кухня, только еще хуже. Вводим пустые интерфейсы-таги, типа:

public interface I1 {};

чтобы написать затем типа такого:

Method2(I1, object);

Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

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

VD>Какую? Я просто пользовался штатными возможностями языка. Более того, так как язык не позволяет автоматически управлять памятью, я буду вынужден писать подобный код реализуя свои контейнеры. И мест для ошибок приводящих к очень неприятным последствиям тут хоть отбавляй. И все в следствии дизайна языка.

Типизация спасает и здесь, типа так:

template<typename T>
class MyContainer {
    T* m_buff;
    size_t m_reserved;
    size_t m_used;
[...]
    void Destroy(T* buff, int size) {
        for(int i=0; i<size; ++i)
            buff[i].~T();
    }
}

Если намеренно не обходить защиту в виде типизации, то все будет ok.

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

VD>Клиника это язык в котором такое море граблей. По сему добрую половину (а то и больше) С++-ного кода не удается назвать корректным кодом.

Да тут проблема иная, и это уже озвучивалось.
Проблема в том, что понятие "грабли" неумолимо расширяется год от года.

Вполне нормальная ситуация, типа:
— запрос ресурса
— использование ресурса
— освобождение ресурса
никогда не вызывала проблем еще буквально лет 7-8 назад.

Однако, с некоторых пор, добрая половина т.н. программистов, коя "разбавила" собой IT-отрасль считает такую ситуацию граблями. И под них, родимых, этот паттерн сократили до:
— запрос ресурса
— использование ресурса
в современных managed и IDisposable средах.
(Кстати, популярные идиомы С++ тоже помогают в приведении паттерна к такому виду)

Но это еще не предел, в некоторых "еще более хороших языках" этот паттерн сузился до апофеоза:
— просто используем ресурс (а там разбирайтесь сами)

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

Я уверен, что "супер язык" C# и тот же VB.Net содержат ну просто невообразимое количество граблей для среднего программиста образца эдак 2015-го года. И ведь индустрия опять под него, под этого программиста прогнется.

<утопия>Или случится чудо, и количество программ(истов) постепенно перейдет в качество</утопия>

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

T>>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

VD>Если не ошибаюсь, в D нечто подобное возможно. Было в Паскале... перекочивало в Аду. Эта концепция вообще-то была во многих языках. Называлась по разному, но суть одна неких typedef, но порождающий не алиас, а новый тип. По-моему очень полезная концепция. Ну, да можно жить и без нее. Все же и копипыст, и шаблоны, и дженерики для этого применимы. И лучше помучиться с ними, чем постоянно вставлять проверки и молиться.

VD>Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов. Пусть даже без полиморфизма. А с полиморфизмом так вообще была бы круть.

мы используем для типизации int в C# enum.

Порой помогает. http://www.rsdn.ru/Forum/Message.aspx?mid=1228621&only=1

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

MN>Господа! Вы Обероны забыли! Господин Губанов, где вы! АУУУ!!!

Он здесь!
И как всегда Мистер Оберон перешёл в решительное наступление!

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

V>Если намеренно не обходить защиту в виде типизации, то все будет ok.

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

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>...Однако, с некоторых пор, добрая половина т.н. программистов, коя "разбавила" собой IT-отрасль считает такую ситуацию граблями.

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

V>Я уверен, что "супер язык" C# и тот же VB.Net содержат ну просто невообразимое количество граблей для среднего программиста образца эдак 2015-го года. И ведь индустрия опять под него, под этого программиста прогнется.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>мы используем для типизации int в C# enum.

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

Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>Мне напомнить про то, что я могу в unsafe режиме в донете и не такое сделать непосредственно в рамках C#?

Напомни. Может кто забыл. За одно напоми себе о том, что на Шарпе без проблем можно программировать без unsafe. А unsafe требует специльных опций компилятора и ручного указания unsafe-кода.

V>Почему мы все время говорим о том, что "а вот у здесь можно вот такую-то лажу нагнать", вместо того, чтобы обсудить, где удобнее не нагнать эту лажу.

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

V> В дотнете в interop вообще все можно уронить с пол-пинка, однако же пользуемся.

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

V>Я вообще не вижу причин огорчаться в случае, если некорректная программа падает, дык — это корректное поведение неккоректной программы.

Огорчаться приходится из-за времени потраченного на отладку и потери данных (или сюжета в играх).

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

Меня тоже. И таких возможностей намного больше в языках которые проектировались специально для этого.

V>Знаю, что ты давно пересел на 2.0, но у нас коммерческие проекты, и они, разумеется, на 1.1. И сильной статической типизации плюсов порой ой как не хватает.

Думаю, что нехватать вам может только возможностей обобщенного программирования. Потому как в общем, шарп в сэйф-режиме полностью типобезопасен, а С++ нет.

V>Для того, чтобы избежать "обезличенных" сигнатур, типа
V>

V>Method1(int, int);
V>Method2(object, object);
V>

V>мы извращаемся как можем, и, на мой взгляд, не всегда корректно применяем имеющиеся штатные ср-ва. Однако, они себя окупают.

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

V>Например.
V>

V>public enum ObjectIdT { eNoObject }; 
V>

V>- пустой енум, мы его используем как типизированный int, используя весь диапазон int-значений. Это немного неккоректно, зато помогло найти несколько ошибок, при добавлении типизации в метод:
V>

V>Method1(ObjectIdT, int);
V>

Да можно было и структуру-обертку создать. Хотя оригинально конено.

V>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

Что-то говорит мне, что обосновать это утверждение тебе не удастся.

Но попробовать стоит. Это будет интересно.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.

О как... А исходя из чего такое причудливое ограничение?

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

C>

C>void func()
C>{
C>    struct
C>    {
C>       void operator ()(int a, int b)
C>       {
C>          ....
C>       }
C>    } inner;

C>    inner(1,2);
C>}
C>

C>Чем не функция?

а как сделать такое

void func(int A,int B)
{
  int C=0;
  int D=0;
  void inner(int E, int F)
  {
     C += (A * E);  
     D -= (B * F);
  };

    inner(1,2);
    inner(3,4);
    inner(5,6);
    inner(7,8);
    inner(9,0);
}

icWasya wrote:

> C>Чем не функция?
> а как сделать такое
>
>void func(int A,int B)
>{
> int C=0;
> int D=0;
> void inner(int E, int F)
> {
> C += (A * E);
> D -= (B * F);
> };
>
> inner(1,2);
> inner(3,4);
> inner(5,6);
> inner(7,8);
> inner(9,0);
>}
>
>


void func(int A,int B)
{
  int C=0;
  int D=0;

  struct inner(int E, int F)
  {
     int &A,&B,&C,&D;
     void operator()(int E,int F)
     {
        C += (A * E);  
        D -= (B * F);
     }
  } inner={A,B,C,D};

  inner(1,2);
  inner(3,4);
  inner(5,6);
  inner(7,8);
  inner(9,0);
}

Некрасиво, но такое нужно бывает очень редко.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

VD>>Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.

ПК>О как... А исходя из чего такое причудливое ограничение?

Содрали м С++.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>Содрали м С++.

VD>Вообще по мне так дуроное ограничение. И не нужное. Можно было извернуться.

Может я не понял суть вопроса, но если речь шла о перегрузке операторов enum-типов в рамках C++, то это может выглядеть так:

enum EA
{
    IS = 0,
    BOX
};

EA operator++(EA &ea, int i)
{
    EA ret = ea;
    ea = (EA)((int)ea+1);
    return ret;
}

EA operator++(EA &ea)
{
    return ea = (EA)((int)ea+1);
}

Использование:

EA ea = IS;
EA pref_ea = ++ea; // префиксный
EA post_ea = ea++; // постфиксный

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

D>Может я не понял суть вопроса, но если речь шла о перегрузке операторов enum-типов в рамках C++, то это может выглядеть так:

Прочти внимательно о чем идет речь.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

V>>...Однако, с некоторых пор, добрая половина т.н. программистов, коя "разбавила" собой IT-отрасль считает такую ситуацию граблями.

VD>О... как забавно. Может чем выделять себя в особую касту подкинуть аргументов?

ниже...

V>>Я уверен, что "супер язык" C# и тот же VB.Net содержат ну просто невообразимое количество граблей для среднего программиста образца эдак 2015-го года. И ведь индустрия опять под него, под этого программиста прогнется.

VD>Несомненно со временем цензы качества должны повыситься. Но почему увеличение ценза качества подменяется странным ярлыком "прогнется"?

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

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

--------
Кстати, качество от этого не повысится. У качества несколько иное определение.

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

V>> В дотнете в interop вообще все можно уронить с пол-пинка, однако же пользуемся.

VD>Можно примеры? Я вот на практике убедился в обратном.

Неправильно call-conversion указан, или аттрибуты по управлению маршаллингом. Получаем неверную интерпретацию памяти, прямо как в С++ при неккоректном кастинге. Такие же незаметные глазу ошибки, кстати.

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

VD>Меня тоже. И таких возможностей намного больше в языках которые проектировались специально для этого.

Они еще недопроектировались. И не доросли. Посмотрим на C# 3.0 ... Пока что мы приобретаем не больше чем теряем, переходя на C# (речь о языке, а не о фреймворке). Из твоих аргументов я выделяю лишь возможность "уронить" С++ программу при выходе за пределы массива или неккоректном кастинге. Однако, на С++ есть довольно сильная культура кода, не нарушая которую можно писать вполне надежные приложения. Я предвижу возражение: "нарушить же элементарно"... Украсть кусок мыла в магазине тоже элементарно, и даже прокатит в 99%, но вот стоит ли рисковать...

V>>Знаю, что ты давно пересел на 2.0, но у нас коммерческие проекты, и они, разумеется, на 1.1. И сильной статической типизации плюсов порой ой как не хватает.

VD>Думаю, что нехватать вам может только возможностей обобщенного программирования. Потому как в общем, шарп в сэйф-режиме полностью типобезопасен, а С++ нет.

Да нет, речь идет именно о статической типизации.

V>>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

VD>Что-то говорит мне, что обосновать это утверждение тебе не удастся.

Но попробовать стоит. Это будет интересно.

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

Откуда, если не секрет, набралось 20 приведений в статической структуре редактора?

Шутка...

Ну, а если у нас бизнес-сущностей более 50-ти, например? И есть базовые классы-имплементации. Сейчас у нас неудобства примерно такие как от использования стандартных контейнеров. Ручками дохрена приходится типизировать в наследниках от базовых классов (напомню, речь об 1.1.). Если же ручками не типизировать, то опять будет как та ситуация со стандартными контейнерами — пихай куда хошь что хошь под безликий object, и в коде приводи постоянно к нужному типу при извлечении... В общем, раздражает этот типизационный копипейст, коего в том же С++ просто не было бы.

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

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

D>>Может я не понял суть вопроса, но если речь шла о перегрузке операторов enum-типов в рамках C++, то это может выглядеть так:

VD>Прочти внимательно о чем идет речь.

Действительно не понятно, что именно ты сказал в том посте (из-за описки). Но в С++ можно перегружать операторы для enum.

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

VD>>>Использование enum — это конечно оригинально, но при этом ведь прийдется приводить эго к int при банальных арифмитических рассчетах. А ведь операторов для энума не сделашь.

ПК>>О как... А исходя из чего такое причудливое ограничение?

VD>Содрали м С++.

Мне, как и Denis2005 с vdimas, не понятно, в чем именно заключалось "сдирание" этого ограничения с C++, если в C++ операторы для enum делать можно

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

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

V>>Если намеренно не обходить защиту в виде типизации, то все будет ok.

VD>Не спасет, так как ошибиться и вызвать деструктор дважды проще простого. А заставить всех писать деструкторы в реинтерабильной манере невозможно.

Ну, Влад, это уже перегиб. Ошибится и вызвать деструктор многократно в какоим-нить самописном векторе — это совершенно надуманный аргумент. Я видел многократные вызовы деструкторов лишь в случае, если они были "размазаны" по объемному коду, безо всякой инкапсуляции. Ну дык, это понятно — налицо было нарушение идиомы RAII.

Если же "все как положено", то в самих инкапсулированных имплементациях ошибится сложнее.

— За сколько телегу почините?
— За пол-дня починим?
— А за день?
— Ну... если постараться, можно и за день...
— А за неделю???
— Ну, тут уж без помощника не обойтись.

VD>Что же касается обхода защиты... в С++ ее настолько просто обойти и это приходится делать настолько часто, что подобные проблемы не редкость и в программах написанных матерыми профи, а про среднего программиста (к коим на этом форуме оносится 80% народу) — это воощбе нормальная ситуация.

Да нет, Влад. Сведения устарели. Обход защиты — это нонсенс в современном мире С++ (речь о прикладном коде). В одном из проектов 2-х летней давности мне пришлось пойти на одиночное приведение в стиле старого С, и то, перед этим долго обсуждали с напарником — нет ли другого выхода? (исходники были недоступны, а залезть "внутрь" надо было). Событие было неординарное и оттого запомнилось.

А так — мне даже трудно представить, где мне потребуется подобное приведение в прикладном коде. А что касается системных вещей, то разве что в самописных менеджерах памяти происходят неявные приведения к void* (через сигнатуру оператора new). Остальное большинство системных задач ныне присутствуют в готовом и отлаженном виде.

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

ПК>Мне, как и Denis2005 с vdimas, не понятно, в чем именно заключалось "сдирание" этого ограничения с C++, если в C++ операторы для enum делать можно

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

VladD2,

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

Понял. В узком смысле невозможности перегружать операции внутри enum это ограничение в C++ тоже присутствует.

Posted via RSDN NNTP Server 2.0 beta

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

VD>Да, тут я не прав. Но для шарпа, где операторы можно реализовывать толко внутри типов это ограничение существует.

Ограничение существует, но можно попробывать его обойти, классом-оберткой над enum. В принципе на производительность это почти не повлияет (в такие моменты бывает жаль, что .NET-компиляторы/оптимизаторы не признают inline

).

enum EA
{
    Is,
    Box
}

struct EAWrapper
{
    private EA ea;

    public EAWrapper(EA ea)
    {
        this.ea = ea;
    }

    // какой-нибудь "хитрый" инкремент
    public static EAWrapper operator++(EAWrapper eaw)
    {
        eaw.ea++;
        return eaw;
    }

    public static implicit operator EA(EAWrapper eaw)
    {
        return eaw.ea;
    }
}

Использование:

EAWrapper eaw_a = new EAWrapper(EA.Is);
EAWrapper eaw_b = new EAWrapper(EA.Is);
EA ea_pref = ++eaw_a;
EA ea_post = eaw_b++;

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

V>Ну, Влад, это уже перегиб. Ошибится и вызвать деструктор многократно в какоим-нить самописном векторе — это совершенно надуманный аргумент.

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

V> Я видел многократные вызовы деструкторов лишь в случае, если они были "размазаны" по объемному коду, безо всякой инкапсуляции. Ну дык, это понятно — налицо было нарушение идиомы RAII.

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

V>Да нет, Влад. Сведения устарели. Обход защиты — это нонсенс в современном мире С++

Я плякаль. Ты давно на соотвествующий форум заходил? А как на счет взова разных АПИ? А как на счет компонентных моделей вроде КОМ или Корбы?

Нонсенс говоришь...

V> (речь о прикладном коде). В одном из проектов 2-х летней давности мне пришлось пойти на одиночное приведение в стиле старого С, и то, перед этим долго обсуждали с напарником — нет ли другого выхода?

Ну, ты крут. Вот для тебя и ПК и сделан С++. Остальным он противопоказан.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>>О... как забавно. Может чем выделять себя в особую касту подкинуть аргументов?

V>ниже...

Не нашел там ничго про т.н. программистов и т.п.

VD>>Несомненно со временем цензы качества должны повыситься. Но почему увеличение ценза качества подменяется странным ярлыком "прогнется"?

V>Потому как за все это конечный пользователь платит потерей эффективности.

По худшим подсчетам современный джит и ХЦ до двух раз менее эффективен по сравнению с самыми эффктивными компиляторами и ручным управлением всем чем попало. Неуже ли эта такая неподъемная плата? А что будет, когда качество джита и ЖЦ поднимится?

V> Соответственно, все эти "улучшения" приходят лишь в тот момент, когда снижение эффективности становится "незаметной на глаз", т.е. отрасль глотает эти потери без особого ущерба.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>Неправильно call-conversion указан, или аттрибуты по управлению маршаллингом. Получаем неверную интерпретацию памяти, прямо как в С++ при неккоректном кастинге. Такие же незаметные глазу ошибки, кстати.

Не нужно придумывать и домысливать. Ты лучше попробуй. Укажи невреный кол-конвеншон или еще что. Увидишь, что в 90% случаев тебе выдадут диагностику, а прохода по памяти и вылета не будет вовсе. Я когда пытался специально завалить фрэйворк через интероп приизрядно попотеть. Только зная адрес стека я смог с помощью memcpy порушить стэк. А такая фигня как call-conversion сразу же вылезает в отладочном окне в виде диагностики под отладчиком, стэк то не сходится.

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

V>Они еще недопроектировались. И не доросли. Посмотрим на C# 3.0

C# уже в версии 1.1 даст фору плюсам по надежности и устойчивости. Не идеал конечно, но все же не дырявое корыто.

V> ... Пока что мы приобретаем не больше чем теряем, переходя на C#

Ну, завали его в безопасном режиме, а потом и поговорим.

V> (речь о языке, а не о фреймворке).

Дык они проектировались вместе. Дотнет рантайм для шарпа. Шарп основной язык для дотнета. Писать конечно можно на чем угодно. Но толку от этого не много.

V>Из твоих аргументов я выделяю лишь возможность "уронить" С++ программу при выходе за пределы массива или неккоректном кастинге.

С++ раняются на раз любым неосторожным действием. Опечаткой... не проинициализированной переменной...

V> Однако, на С++ есть довольно сильная культура кода,

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

V> не нарушая которую можно писать вполне надежные приложения.

А зачем в языке нужны фичи которые нужно не нарушать? Это что игра такая?

V> Я предвижу возражение: "нарушить же элементарно"... Украсть кусок мыла в магазине тоже элементарно, и даже прокатит в 99%, но вот стоит ли рисковать...

О! Доказательство по аналогии? Ла еще и привентивное? Обожаю. Тогда пререйдем к аналогиям...
Зачем связыаться с ручным разваливающимся пресом боясь остаться без пальцев если можно пользоваться автоматизированной линией в которой и человеку то делать нечего?
В общем, можешь придумать сам что хочешь. А мне можно оставить факты. А факты пока простые. Наделать ошибок приводящих к жутчайшим проблемам на С++ проще простого. Для этого не нужно нарушать защиту специльно. Защиты просто нет. Просто то и дело приходится возиться с указателями и делать безусловные приведения типов. Просто нет человеческого контроля за инициализированностью переменных. И просто грабли в языке разложены как будто нарочно. Специалист высокого класса может толко сократить объем ошибок, но они все равно будут. И платить за них прийдется пользователям. И все это при том, что можно просто использовать языки и средства недопускающие 90% ошибок во все. Мене квалифицированный программист не сможет наделать ошибок которые приведут к ночному траху более опытных. А более опытный соможет резко поднять свою эффективность не тратя время на разные проблемы.

VD>>Думаю, что нехватать вам может только возможностей обобщенного программирования. Потому как в общем, шарп в сэйф-режиме полностью типобезопасен, а С++ нет.

V>Да нет, речь идет именно о статической типизации.

Покажи, плиз приемущества статической типизации в С++ в необобщенном коде.

V>>>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

VD>>Что-то говорит мне, что обосновать это утверждение тебе не удастся.

Но попробовать стоит. Это будет интересно.

Даже пытаться не будешь?

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

V>Откуда, если не секрет, набралось 20 приведений в статической структуре редактора?

V>Шутка...

Я тебе уже указал что к ним привело. Половина из приведений это случаи вроде приведения результата сложения символов с константами к char. Могу описать все случаи. Уверен, что в своих программах ты их даже выделить не сможшь.

V>Ну, а если у нас бизнес-сущностей более 50-ти, например?

Гы. 50-ни. Пользуйся ООП и паттернами проектирования.

V> И есть базовые классы-имплементации. Сейчас у нас неудобства примерно такие как от использования стандартных контейнеров. Ручками дохрена приходится типизировать в наследниках от базовых классов (напомню, речь об 1.1.). Если же ручками не типизировать, то опять будет как та ситуация со стандартными контейнерами — пихай куда хошь что хошь под безликий object, и в коде приводи постоянно к нужному типу при извлечении... В общем, раздражает этот типизационный копипейст, коего в том же С++ просто не было бы.

Возмите код-смит и сгенерируйте себе столько коллекций сколько потребуется.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

VD>>Да, тут я не прав. Но для шарпа, где операторы можно реализовывать толко внутри типов это ограничение существует.

D>Ограничение существует, но можно попробывать его обойти, классом-оберткой над enum.

А зачем мне тогда enum? Структура уже тип. Все что нужно я в ней сделаю. Только это куча кода. И все ради типа который почти 1 в 1 с int-ом.

D> В принципе на производительность это почти не повлияет (в такие моменты бывает жаль, что .NET-компиляторы/оптимизаторы не признают inline

).

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

D>> В принципе на производительность это почти не повлияет (в такие моменты бывает жаль, что .NET-компиляторы/оптимизаторы не признают inline

).

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

Влад, это и ежу понятно, что inline допустим только под Release. Итак, у меня FW v1.0.3705.

Смотрим код:
EAWrapper eaw_a = new EAWrapper(EA.Is);
EAWrapper eaw_b = new EAWrapper(EA.Is);
EA ea_pref = ++eaw_a;
EA ea_post = eaw_b++;

Смотрим IL (сборка Release):

  IL_0000:  ldloca.s   V_0
  IL_0002:  ldc.i4.0
  IL_0003:  call       instance void ConsoleApplication1.Class1/EAWrapper::.ctor(valuetype ConsoleApplication1.Class1/EA)
  IL_0008:  ldloca.s   V_1
  IL_000a:  ldc.i4.0
  IL_000b:  call       instance void ConsoleApplication1.Class1/EAWrapper::.ctor(valuetype ConsoleApplication1.Class1/EA)
  IL_0010:  ldloc.0
  IL_0011:  call       valuetype ConsoleApplication1.Class1/EAWrapper ConsoleApplication1.Class1/EAWrapper::op_Increment(valuetype ConsoleApplication1.Class1/EAWrapper)  IL_0016:  dup
  IL_0017:  stloc.0
  IL_0018:  call       valuetype ConsoleApplication1.Class1/EA ConsoleApplication1.Class1/EAWrapper::op_Implicit(valuetype ConsoleApplication1.Class1/EAWrapper)  IL_001d:  pop
  IL_001e:  ldloc.1
  IL_001f:  dup
  IL_0020:  call       valuetype ConsoleApplication1.Class1/EAWrapper ConsoleApplication1.Class1/EAWrapper::op_Increment(valuetype ConsoleApplication1.Class1/EAWrapper)  IL_0025:  stloc.1
  IL_0026:  call       valuetype ConsoleApplication1.Class1/EA ConsoleApplication1.Class1/EAWrapper::op_Implicit(valuetype ConsoleApplication1.Class1/EAWrapper)  IL_002b:  pop
  IL_002c:  ret

Влад, честно говоря я пишу под .NET с декабря 2001 поэтому сильно удивлен насчет возможности встраивания.
Может в FW v.2.0 допускается inline-оптимизация?

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

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

V>>Неправильно call-conversion указан, или аттрибуты по управлению маршаллингом. Получаем неверную интерпретацию памяти, прямо как в С++ при неккоректном кастинге. Такие же незаметные глазу ошибки, кстати.

VD>Не нужно придумывать и домысливать. Ты лучше попробуй. Укажи невреный кол-конвеншон или еще что. Увидишь, что в 90% случаев тебе выдадут диагностику, а прохода по памяти и вылета не будет вовсе. Я когда пытался специально завалить фрэйворк через интероп приизрядно попотеть.

странно... у меня это выходило на раз...
вызываю ф-ию API в которую надо передать адрес буфера, куда данные возвращаются. Малость "недоигрался" со StringBuilder и аттрибутами — и приплыли.

VD>Только зная адрес стека я смог с помощью memcpy порушить стэк. А такая фигня как call-conversion сразу же вылезает в отладочном окне в виде диагностики под отладчиком, стэк то не сходится.

Они разные бывают, эти call convertions, иногда отличаются лишь порядком следования аргументов, а не только стороной ответственности за прочистку стека.

VD>C# уже в версии 1.1 даст фору плюсам по надежности и устойчивости. Не идеал конечно, но все же не дырявое корыто.

Заблуждение и пропаганда. Программы все так же кишат ошибками (наблюдаю много их на C#). Разница лишь в том, что приложение не просто падает, а перед этим имеет возможность вывести сообщение об ошибке (опять же — если программист позаботился, а заботятся далеко не все). А с т.з. юзера — однофигственно, упало и упало, уже не поднять.

VD>Ну, завали его в безопасном режиме, а потом и поговорим.

Знаешь, играл как-то и экспериментировал с RFD пол-года назад (там генерирование типов налету). Ну, по неопытности применял команды, предназначенные для объектных ссылок, к структурам. Самое интересное, что приложение работало полностью в безопасном режиме. И при генерации типов никаких ошибок не было. Но вот при создании экземпляров неоднократно получал сообщения типа "Virtual Machine .Net разрушена и не может продолжать свою работу. Приложение будет закрыто.".

V>> Однако, на С++ есть довольно сильная культура кода,

VD>О, да. Надо об этом пользователям расскзать. Может они смирятся с вылетами и глюками. Ведь культура же.

Наблюдаю вылеты и глюки и в программах на C#. В чем суть твоего аргумента? Ошибки делает не среда, а люди.

V>> не нарушая которую можно писать вполне надежные приложения.

VD>А зачем в языке нужны фичи которые нужно не нарушать? Это что игра такая?

Именно. Под названием — "системное + прикладное программирование эффективных решений".

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

А ты не делай безусловные приведения. Тебе уже 100 раз об этом сказали.

VD>Просто нет человеческого контроля за инициализированностью переменных.

В дотнете тоже нет. Там контроль на уровне компилятора. VC 7.1 прекрасно ругается в аналогичных случаях. Если очень надо — задай опцию: "warnings as errors".

VD>И просто грабли в языке разложены как будто нарочно. Специалист высокого класса может толко сократить объем ошибок, но они все равно будут.

Ошибки есть в большом количестве (и будут впредь) и в программах на C#. Я уже повидал некоторое количество "живых" реальных проектов, и вижу, что творится. Ты Влад, свою рубаху на других не надевай. Я тебе прямо скажу — просто кошмар что творится в коде обычно. В С++ я давно такого не видел (и есть от чего).

VD>И платить за них прийдется пользователям. И все это при том, что можно просто использовать языки и средства недопускающие 90% ошибок во все.

Да не там ошибки обычно, где ты говоришь. Если мы и встречали ошибки, связанные с вылетом за диапазон массива или неправильной адресной арифметикой, то этих ошибок и 10% не набирается в "живом" проекте. Не знаю, с какого неба ты хватаешь свою статистику (по своему опыту?

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

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

VD>Мене квалифицированный программист не сможет наделать ошибок которые приведут к ночному траху более опытных. А более опытный соможет резко поднять свою эффективность не тратя время на разные проблемы.

Ой-ли???

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

V>>Да нет, речь идет именно о статической типизации.

VD>Покажи, плиз приемущества статической типизации в С++ в необобщенном коде.

Кто-то кого-то не понимает (похоже, преднамеренно). В С++ используют типизацию/обертки на каждый чих, и правильно делают, ибо в run-time это ничего не стоит. Есть куча compile-time проверок. А в C# 2.0 мы даже не сможем обощить алгоритмы на различные типы int, floаt, double и т.д. Я не могу элементарно сложить 2 числа и подсчитать сумму "обощенного" типа. Я уже молчу о еще более мелкой типизации и подстройке алгоритмов — стратегиях и св-вах, управление которыми доступно нам через выводимые и зависимые типы.

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

V>>>>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

VD>>>Что-то говорит мне, что обосновать это утверждение тебе не удастся.

Но попробовать стоит. Это будет интересно.

VD>Даже пытаться не будешь?

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

И даже еще больше. В предыдущем абзаце я повторил немногое.

V>>Ну, а если у нас бизнес-сущностей более 50-ти, например?

VD>Гы. 50-ни. Пользуйся ООП и паттернами проектирования.

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

V>> И есть базовые классы-имплементации. Сейчас у нас неудобства примерно такие как от использования стандартных контейнеров. Ручками дохрена приходится типизировать в наследниках от базовых классов (напомню, речь об 1.1.). Если же ручками не типизировать, то опять будет как та ситуация со стандартными контейнерами — пихай куда хошь что хошь под безликий object, и в коде приводи постоянно к нужному типу при извлечении... В общем, раздражает этот типизационный копипейст, коего в том же С++ просто не было бы.

VD>Возмите код-смит и сгенерируйте себе столько коллекций сколько потребуется.

У нас не коллекции, а имплементации, но сути не меняет. Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

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

VD>>>О... как забавно. Может чем выделять себя в особую касту подкинуть аргументов?

V>>ниже...

VD>Не нашел там ничго про т.н. программистов и т.п.

Там про т.н. эффективность. Привычка связывать эти термины еще не искоренилась.

VD>По худшим подсчетам современный джит и ХЦ до двух раз менее эффективен по сравнению с самыми эффктивными компиляторами и ручным управлением всем чем попало. Неуже ли эта такая неподъемная плата? А что будет, когда качество джита и ЖЦ поднимится?

Ты хотел сказать — по лучшим подсчетом. Ибо у меня упорно получается разница в среднем примерно 3 раза. В 2 раза я получал разницу лишь на простейших 2-х строчных циклах for(int i= blah, blah), но и это удивительно, ибо подобные алгоритмы джит должен был бы вообще переводить идеально в машинный вариант и показывать идентичное быстродействие (где он там в 3-х соснах заблудился?). Отчего-то не показывает.

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

D>Влад, это и ежу понятно, что inline допустим только под Release.

Не только под релиз, но и без отладчика, и не в IL, а в x86 коде. Посмотреть наличие инлайнинга можно только в cordbg со специальной опцией, либо сгененрировать исключение и посмотрев callstack.

D>Итак, у меня FW v1.0.3705.

Хоть бы 1.1 поставил.

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

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

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

D>>Влад, это и ежу понятно, что inline допустим только под Release.

AVK>Не только под релиз, но и без отладчика, и не в IL, а в x86 коде. Посмотреть наличие инлайнинга можно только в cordbg со специальной опцией, либо сгененрировать исключение и посмотрев callstack.

Проще говоря JIT-компилятор занимается inline-ингом, а речь шла про .NET-компиляторы (Code -> MSIL).

D>>Итак, у меня FW v1.0.3705.

AVK>Хоть бы 1.1 поставил.

Если бы я мог, проекты крупные и соотв. дорогие, и я не уверен в том, что совместимость между 1.0 и 1.1 = 100%.
Сейчас рассматривается переход под 2.0.

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

D>Проще говоря JIT-компилятор занимается inline-ингом, а речь шла про .NET-компиляторы (Code -> MSIL).

С чего ты взял?

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

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

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

D>>Проще говоря JIT-компилятор занимается inline-ингом, а речь шла про .NET-компиляторы (Code -> MSIL).

AVK>С чего ты взял?

Насколько я понимаю JIT-компилятор осуществляет MSIL -> Native. Это уже совсем другой уровень, и насколько я знаю поведение JIT-компилятора MS особо не регламентирует. Меня интересует возможно ли то, что в след. версиях встраивание станет возможным (опционально) на уровне Code -> MSIL.

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

D>Насколько я понимаю JIT-компилятор осуществляет MSIL -> Native. Это уже совсем другой уровень,

И что из того?

D> и насколько я знаю поведение JIT-компилятора MS особо не регламентирует.

Ну касательно инлайнинга кое что в MSDN есть.

D> Меня интересует возможно ли то, что в след. версиях встраивание станет возможным (опционально) на уровне Code -> MSIL.

Вряд ли. Политика МС — большинство оптимизаций делает JIT.

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

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

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

D>>Насколько я понимаю JIT-компилятор осуществляет MSIL -> Native. Это уже совсем другой уровень,

AVK>И что из того?

Для небольших проектов не под Windows, рассматривается вариант использования nix + mono. Понятное дело, что как JIT-компилятор будет там реализован, знает только его разработчик, т.е. у меня нет гарантий, что я получу инлайнинг в тех или иных случаях. Если бы встраивание происходило на уровне Code -> MSIL я бы имел такие гарантии. Согласитесь, что это более декларативно, когда ILDASM-ом можно посмотреть "шалости" оптимизатора.

D>> Меня интересует возможно ли то, что в след. версиях встраивание станет возможным (опционально) на уровне Code -> MSIL.

AVK>Вряд ли. Политика МС — большинство оптимизаций делает JIT.

Я считаю причина в том, что MS свято верит в надобность существования возможности MSIL -> Code, а в таком случае разумно действительно отказаться от идеи оптимизации на уровне Code -> MSIL.

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

D>Для небольших проектов не под Windows, рассматривается вариант использования nix + mono. Понятное дело, что как JIT-компилятор будет там реализован, знает только его разработчик, т.е. у меня нет гарантий, что я получу инлайнинг в тех или иных случаях. Если бы встраивание происходило на уровне Code -> MSIL я бы имел такие гарантии.

Нет, не имел бы. Поскольку компилятор в mono тоже собственный.

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

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

D> Насколько я понимаю JIT-компилятор осуществляет MSIL -> Native. Это уже совсем другой уровень, и насколько я знаю поведение JIT-компилятора MS особо не регламентирует. Меня интересует возможно ли то, что в след. версиях встраивание станет возможным (опционально) на уровне Code -> MSIL.

По-моему C++/CLI должен это уметь.

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

D>Для небольших проектов не под Windows, рассматривается вариант использования nix + mono. Понятное дело, что как JIT-компилятор будет там реализован, знает только его разработчик, т.е. у меня нет гарантий, что я получу инлайнинг в тех или иных случаях. Если бы встраивание происходило на уровне Code -> MSIL я бы имел такие гарантии. Согласитесь, что это более декларативно, когда ILDASM-ом можно посмотреть "шалости" оптимизатора.
Ты что-то остановился конкретно на инлайнинге. А ведь оптимизаций кода значительно больше. И при этом некоторые из них зависят от типа процессора и вообще архитектуры железа.

Во вторых, случаи когда применяется инлайнинг (по крайней мере Microsoft) описаны. Как и принципы оптимизации. В третьих, стандарт открытый. И каждый может написать свой компилятор JIT как это сделали в Mono и ввести свои оптимизации. В четвертых, inlining на языке высокого уровня — плохо, поскольку эти процедуры могут использоваться и на других языках. Это одно из основных свойств Net. В пятых, посмотри Hotspot для Java, и ты поймешь что оптимизация бывает не только при компиляции но и при выполнении.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

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

VD>Видимо мне не везет. Я то подобную хрень был вынужден вычищать собственными ручками. Много времени убил пока понял, что к чему.

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

V>> Я видел многократные вызовы деструкторов лишь в случае, если они были "размазаны" по объемному коду, безо всякой инкапсуляции. Ну дык, это понятно — налицо было нарушение идиомы RAII.

VD>Меня всегда умиляют таки правидные речи. Типа мы то код пишем правильный, безошибочный и очень легко читаемый. И почему в реальных проектах все время попададтся горы малопонятного кода с кучай ошибок?

Ну, где как. Я и в проектах на VB видел тонны мусора. В противовес этому — наблюдал красивые и стройные программы и на Forth-e и на Asm-e.

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

VD>

Я плякаль. Ты давно на соотвествующий форум заходил? А как на счет взова разных АПИ? А как на счет
компонентных моделей вроде КОМ или Корбы?

Ну, используем CORBA в проекте. Там получаем сначала общую объектную ссылку по URI на клиенте, а потом выполняем статический метод MyClass_ptr MyClass::narrow(Object_ptr); Этот метод весьма типизирован и описан стандартным маппингом CORBA на C++. Не требуется обход защиты.

VD>Вот для тебя и ПК и сделан С++. Остальным он противопоказан.

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

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

Ты же считаешь, что дотнет покрывает все нужды современного программинга, да еще пошел в крестовый поход на плюсы. Похоже, ожесточенные дисскуссии на эту тему сотрясают только rsdn. Как Java никуда не особо-то потеснила плюсы, так и дотнет не вытеснит. Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

Кстати, а на какой технологии Microsoft собралась делать следующий офис?

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

V>Ты хотел сказать — по лучшим подсчетом. Ибо у меня упорно получается разница в среднем примерно 3 раза. В 2 раза я получал разницу лишь на простейших 2-х строчных циклах for(int i= blah, blah), но и это удивительно, ибо подобные алгоритмы джит должен был бы вообще переводить идеально в машинный вариант и показывать идентичное быстродействие (где он там в 3-х соснах заблудился?). Отчего-то не показывает.

Код в студию.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, vdimas, Вы писали:
V>Заблуждение и пропаганда. Программы все так же кишат ошибками (наблюдаю много их на C#). Разница лишь в том, что приложение не просто падает, а перед этим имеет возможность вывести сообщение об ошибке (опять же — если программист позаботился, а заботятся далеко не все). А с т.з. юзера — однофигственно, упало и упало, уже не поднять.
Не устаю напоминать что это верно только для однопользоательских приложений. Тут, конечно, пользователю стек трейс не всунешь. Но как только речь заходит про сервер...
Решения с изоляцией пользовательских процессов — тяжелы. Процессы не могут разделять общий кэш и все такое.
Выполнение пользовательских запросов в рамках одного процесса — страшный риск в неуправляемой среде. Маленький завал — и все, остальные три тыщи пользователей падают ни за что ни про что. Утечки памяти в 10 байт на пользователя в минуту не имеют практического значения в настольной системе. В сервере это означает, что 30000 пользователей за час съедят 18 метров. Что в свою очередь означает еженедельный перезапуск сервера с привлечением админа.

Я поигрался с Yukon и Reporting Services. Кто отлаживал что-нибудь типа расширения для Windows Explorer? Конечно, при соблюдении культуры программирования все зашибись. Но как только она несоблюдена — все, труба. Ты даже поотлаживаться не сможешь (потому, что студия, как и все, использует Open Dialog, расположенный в том самом шелле, который только что упал или завис). Положить этих товарищей путем подсовывания в них чего попало вообще невозможно. Пытаюсь бесконечную рекурсию в UDT в Yukon засунуть — упс, при селекте мне просто приезжает нормальный такой Message типа stack overflow все дела. Транзакция откатилась, остальные пользователи прекрасно себя чувствуют. Попробовал в репортинг сервисе каку в екстеншене сделать — хрен. Все работает, только мой екстеншн нигде не светится. Посмотрел я на логи — ага, секурити его не пропустила. Ничего, все остальное работает! Да, лично мне не менее обидно, чем если бы весь репортинг нафиг упал — я-то своего не добился. Нет, вру — менее обидно. Потому как AV или прочий низкоуровневый стуфф мне ничего не скажет о том, где я напортачил. А управляемая среда меня носом тыкает ровно в то место, где свалилось. И заботливо все в лог кладет, вместо тупого падения в дамп.
Ну да ладно. Я не об этом, а о том, что все остальные пользователи этого же сервера ничего даже не заметят!

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

V>Тебе давно пора согласится, что код бывает разного качества.

С этим утверждением я не спорил.

V> И этот факт, к сожалению, никак не зависит ни от языка, ни от фреймворка. Ты же пытаешься обнаружить корреляцию.

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

V>Ну, где как.

Я так понимаю у вас код идеальный.

V>Я и в проектах на VB видел тонны мусора. В противовес этому — наблюдал красивые и стройные программы и на Forth-e и на Asm-e.

Ясно. Во всем виноват ВБ.

V>Ну, используем CORBA в проекте. Там получаем сначала общую объектную ссылку по URI на клиенте, а потом выполняем статический метод MyClass_ptr MyClass::narrow(Object_ptr); Этот метод весьма типизирован и описан стандартным маппингом CORBA на C++. Не требуется обход защиты.

Т.е. ты считашь, что приведение засунутое в narrow кошернее чем вызванное напрямую?

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

Хм... Я тоже для некоторых задач наверно предпочту С++. Разница у нас в том, что я предпочту С++ для 1% задач, а ты для 99%.

V>Ты же считаешь, что дотнет покрывает все нужды современного программинга, да еще пошел в крестовый поход на плюсы.

Я так не считаю. Что я считаю я уже сказал.

V> Похоже, ожесточенные дисскуссии на эту тему сотрясают только rsdn. Как Java никуда не особо-то потеснила плюсы, так и дотнет не вытеснит.

Да ява с дотнетом уже очень сильно их потеснила. Но дело не в этом. Меня не интиресуют пристрастия миллионов. Меня интересует надежный софт и комфортные условия его создания.

Как тут кто-то очень хорошо сказал "безопасный язык является одной из обязательных составляющих получения надежного ПО".

V> Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

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

V>Кстати, а на какой технологии Microsoft собралась делать следующий офис?

Чего не знаю, того не знаю. Слышал о перекомпиляции части Офиса в менеджед-режиме на МС++. Но какова цель этого действа непонятно.

А ведь именно офис, точнее Ворд, я хотел бы видеь в менеджед-виде в первую очередь. Уж больгл сильно он ключит.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>Ты хотел сказать — по лучшим подсчетом. Ибо у меня упорно получается разница в среднем примерно 3 раза. В 2 раза я получал разницу лишь на простейших 2-х строчных циклах for(int i= blah, blah), но и это удивительно, ибо подобные алгоритмы джит должен был бы вообще переводить идеально в машинный вариант и показывать идентичное быстродействие (где он там в 3-х соснах заблудился?). Отчего-то не показывает.

Позволю себе усомниться в данных утверждениях.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>странно... у меня это выходило на раз...

Пока что только на словах.

V>вызываю ф-ию API в которую надо передать адрес буфера, куда данные возвращаются. Малость "недоигрался" со StringBuilder и аттрибутами — и приплыли.

Как тут правильно заметил один товарищь: код в студию!

V>Они разные бывают, эти call convertions, иногда отличаются лишь порядком следования аргументов, а не только стороной ответственности за прочистку стека.

Ты под АПИ что имел в виду? И какое по-твоему саглашение использует ВиньАпи?

В любом случае контроль интеропа не сравним с ручной возней с типами в С++. Так что твои утверждния мягко говоря натянуты.

VD>>C# уже в версии 1.1 даст фору плюсам по надежности и устойчивости. Не идеал конечно, но все же не дырявое корыто.

V>Заблуждение и пропаганда.

В некоторых кругах это называют фактами. А вот как назвать твои голословные утверждения я даже не знаю.

V> Программы все так же кишат ошибками (наблюдаю много их на C#).

Кишат, но не так же.

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

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

VD>>Ну, завали его в безопасном режиме, а потом и поговорим.

V>Знаешь, играл как-то и экспериментировал с RFD пол-года назад (там генерирование типов налету). Ну, по неопытности применял команды, предназначенные для объектных ссылок, к структурам. Самое интересное, что приложение работало полностью в безопасном режиме.

Самому то не смешно?

V> И при генерации типов никаких ошибок не было. Но вот при создании экземпляров неоднократно получал сообщения типа "Virtual Machine .Net разрушена и не может продолжать свою работу. Приложение будет закрыто.".

В безопасном режиме без вызова небезопасного кода это невозможно в принципе (ну, разве что ошибка в рантайм-коде). У тебя же был просто небезопасный код сгенерирован.

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

V>Наблюдаю вылеты и глюки и в программах на C#. В чем суть твоего аргумента?

И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

V>Ошибки делает не среда, а люди.

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

V>Именно. Под названием — "системное + прикладное программирование эффективных решений".

Оставим системное. (Хотя тут тоже большой вопрос нужно ли для него С++. Про Сингулярити думаю слышал?) Но прикладное то, да еще критическое к сбоям и серверное закаким писать на средстве не обеспечивющем полноценный контроль типов?

V>А ты не делай безусловные приведения. Тебе уже 100 раз об этом сказали.

Я и не делаю. Для этого лучшим решением является отказ от плюсов.

Оглянить вокруг. Погляди на примеры кода на этом сайте. Приведения всюду и тоннами. Неинициализированные переменные вообще песня без слов.

VD>>Просто нет человеческого контроля за инициализированностью переменных.

V>В дотнете тоже нет. Там контроль на уровне компилятора.

Сможешь доказать это утверждение?

V> VC 7.1 прекрасно ругается в аналогичных случаях. Если очень надо — задай опцию: "warnings as errors".

И в релизе? И даже кода объекты создаются разными хитрыми спосабами?

V>Ошибки есть в большом количестве (и будут впредь) и в программах на C#.

Старая песня...

V>Да не там ошибки обычно, где ты говоришь. Если мы и встречали ошибки, связанные с вылетом за диапазон массива или неправильной адресной арифметикой, то этих ошибок и 10% не набирается

Найденных? А не найденных?

VD>>Мене квалифицированный программист не сможет наделать ошибок которые приведут к ночному траху более опытных. А более опытный соможет резко поднять свою эффективность не тратя время на разные проблемы.

V>Ой-ли???

Ой, ой...

V>Я достаточно трахался с чужим C# кодом. Были случаи по многопоточной синхронизации. Мне в тот момент было абсолютно все-равно на чем проект, ибо ошибки были обще-алгоритмического плана. В общем, как обычно, все пришлось переделывать нах.

Многпоточность есть многопоточность. Но опять же разница огромная. Одно дело когда это управляемый код с гарантией того что память не портится и отличным колфрэймом, а другое гадание в плюсовая прогармма скомпилированная в релиз в которй черт знает что случилось.

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

VD>>Покажи, плиз приемущества статической типизации в С++ в необобщенном коде.

V>Кто-то кого-то не понимает (похоже, преднамеренно). В С++ используют типизацию/обертки на каждый чих, и правильно делают, ибо в run-time это ничего не стоит. Есть куча compile-time проверок. А в C# 2.0 мы даже не сможем обощить алгоритмы на различные типы int, floаt, double и т.д. Я не могу элементарно сложить 2 числа и подсчитать сумму "обощенного" типа. Я уже молчу о еще более мелкой типизации и подстройке алгоритмов — стратегиях и св-вах, управление которыми доступно нам через выводимые и зависимые типы.

Ясно опять пустые слова. Показать ты никаких приемуществ не можешь. Оно и понятно. Не может иметь приемуществ нетипобезопасный язык над типобезопасным.

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

V>>>>>Да, "шаблонность" нам малость поможет потом частично разрулить эти безобразия, однако, прежнего удобства от наличия сильной статической модели кода, какую привык наблюдать в С++, все-равно не получим даже в 2.0. (У меня Express, все ограничения дженериков уже просек).

VD>>>>Что-то говорит мне, что обосновать это утверждение тебе не удастся.

Но попробовать стоит. Это будет интересно.

VD>>Даже пытаться не будешь?

V>Тебе же уже неоднократно все эти аргументы приводили.

И даже еще больше. В предыдущем абзаце я повторил немногое.

Аргументы? Нда. Ты бы хоть один пример привел.

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

Аннулировать? Ты о чем? ООП для проектирования нужно применять, и для замены кривых прямолинейных решений.

V>У нас не коллекции, а имплементации, но сути не меняет.

Что такое "имплементации" я не знаю.

V> Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

За-то я знаю что кучи приведений говорит о качестве проектирования.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

D>Смотрим IL (сборка Release):

Инлайнит JIT! Смотреть в msil бессмысленно.

D>Может в FW v.2.0 допускается inline-оптимизация?

Доступны начиная с 1.0. Запускать надо не под отладчиком. Можешь убедиться в моих словах запустив программу под cordbg с включенной опцией оптимизации. При этом ты увидишь реальный ассемблерный код сгенерированный джитом.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

D>...я знаю поведение JIT-компилятора MS особо не регламентирует.

Все он регламентирует, вернее документирует. О инлайнинге сто раз уже писалось в МСДН-е.

D> Меня интересует возможно ли то, что в след. версиях встраивание станет возможным (опционально) на уровне Code -> MSIL.

Никогда в жизни. Инлайнинг реализован на уровне джита.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

ПК>По-моему C++/CLI должен это уметь.

Это умел и МС++ 1.0. Это заслуга не менеджед-расширения, а побочный продукт того факта что исходный компилятор имеет оптимизатор на уровне собственного промежуточного кода.

Смысла в этом практически нет. Но за счет того, что эвристики у VC по лучше и результат иногда получается более впечатляющий. Думаю, точку над i поставит Феникс.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

S>Пытаюсь бесконечную рекурсию в UDT в Yukon засунуть — упс, при селекте мне просто приезжает нормальный такой Message типа stack overflow все дела.

А хвостовая рекурсия там не оптимизируется?

... << RSDN@Home 1.1.4 beta 6a rev. 438>>

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

V>>вызываю ф-ию API в которую надо передать адрес буфера, куда данные возвращаются. Малость "недоигрался" со StringBuilder и аттрибутами — и приплыли.

VD>Как тут правильно заметил один товарищь: код в студию!

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

V>>Они разные бывают, эти call convertions, иногда отличаются лишь порядком следования аргументов, а не только стороной ответственности за прочистку стека.

VD>Ты под АПИ что имел в виду? И какое по-твоему саглашение использует ВиньАпи?

Кто сказал, что мне нужен только вынь-апи?

VD>В любом случае контроль интеропа не сравним с ручной возней с типами в С++. Так что твои утверждния мягко говоря натянуты.

Я не понял смысла туманной фразы "с ручной возней с типами в С++". Если сигнатуры типизированы (без всяких void*), то возни нет в принципе.

VD>>>C# уже в версии 1.1 даст фору плюсам по надежности и устойчивости. Не идеал конечно, но все же не дырявое корыто.

V>>Заблуждение и пропаганда.

VD>В некоторых кругах это называют фактами. А вот как назвать твои голословные утверждения я даже не знаю.

Замечательно подходит абсолютно под все твои утверждения. Кстати весь предыдущий пост был написан в твоем стиле, не заметил?

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

V>> Программы все так же кишат ошибками (наблюдаю много их на C#).

VD>Кишат, но не так же.

Нет так же. Кишат.

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

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

Хорошо. Реальная статистика. Проект делали примерно 2 года примерно 20 чел. Около 500 баг-репортов накопилось во время разработки. Из них записей "про падения — крэш" примерно 15 шт (3%). Остальная масса ошибок — не так перерисовывается контрол, не туда что-то пишется, ошибка логики при таких-то входных данных и т.д. и т.п.

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

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

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

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

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

VD>>>Ну, завали его в безопасном режиме, а потом и поговорим.

V>>Знаешь, играл как-то и экспериментировал с RFD пол-года назад (там генерирование типов налету). Ну, по неопытности применял команды, предназначенные для объектных ссылок, к структурам. Самое интересное, что приложение работало полностью в безопасном режиме.

VD>Самому то не смешно?

Нет. Ты же говорил про опции unsafe?

V>> И при генерации типов никаких ошибок не было. Но вот при создании экземпляров неоднократно получал сообщения типа "Virtual Machine .Net разрушена и не может продолжать свою работу. Приложение будет закрыто.".

VD>В безопасном режиме без вызова небезопасного кода это невозможно в принципе (ну, разве что ошибка в рантайм-коде). У тебя же был просто небезопасный код сгенерирован.

А какого хрена TypeBuilder позволил нагенерить несовместимые инструкции??? (код был не безопасный, он был принципиально неккоректный — в фомирование команд, предназначенных для классов, я подал тип структуры, и это никак не проверилось)

VD>И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

О, опять ты про "очевидное". Ну я тебе в ответ напоминаю про реальную стоимость твоего "очевидного" — 3%.

V>>Ошибки делает не среда, а люди.

VD>Люди, люди. Вопрос в том, помогает ли это делать язык и рантайм, или препятствует. Ну, и в результате получаемом в конце.

Если ты рисуешь неправильно контрол, или у тебя логика в цикле пропускает последний/первый элемент, и т.д. и т.п. То результат будет одинаков, независимо от среды. Мне уже интересно, что у тебя там произошло с плюсами, что ты настойчиво повторяешь одно и то же? Ну не существенно это.

Кстати, а в плане рисования тех же контролов. Несмотря на то, что объектная модель и GDI+ более удобен, чем вынь-апи, я наблюдая гораздо больше ошибок и неккоректностей в реализайии контролов на C#. (Просмотри форум .Net GUI). Как ты подобну странность прокоментируешь???

V>>Именно. Под названием — "системное + прикладное программирование эффективных решений".

VD>Оставим системное. (Хотя тут тоже большой вопрос нужно ли для него С++. Про Сингулярити думаю слышал?) Но прикладное то, да еще критическое к сбоям и серверное закаким писать на средстве не обеспечивющем полноценный контроль типов?

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

V>>В дотнете тоже нет. Там контроль на уровне компилятора.

VD>Сможешь доказать это утверждение?

В смысле, сгенерить через TypeBuilder метод с переменной в стеке, например int, и вывести ее значение в Console без предварительного присвоения? Самому не смешно?

V>> VC 7.1 прекрасно ругается в аналогичных случаях. Если очень надо — задай опцию: "warnings as errors".

VD>И в релизе? И даже кода объекты создаются разными хитрыми спосабами?

Если у меня в C# переменная объявлена как член класса, то ее инициализацию даже компилятор не проверяет. Разве что Решарпер.

VD>Многпоточность есть многопоточность. Но опять же разница огромная. Одно дело когда это управляемый код с гарантией того что память не портится и отличным колфрэймом, а другое гадание в плюсовая прогармма скомпилированная в релиз в которй черт знает что случилось.

Как это память не портится при многопоточности. Именно в этом ошибки и проявляются. (Например, пишем в буфер что-то).

VD>Что же до многопоточности... тут замечательно подходят функциональные языки. В них данные не перезаписываются что практически исключает необходимость в синхронизации.

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

V>>Кто-то кого-то не понимает (похоже, преднамеренно). В С++ используют типизацию/обертки на каждый чих, и правильно делают, ибо в run-time это ничего не стоит. Есть куча compile-time проверок. А в C# 2.0 мы даже не сможем обощить алгоритмы на различные типы int, floаt, double и т.д. Я не могу элементарно сложить 2 числа и подсчитать сумму "обощенного" типа. Я уже молчу о еще более мелкой типизации и подстройке алгоритмов — стратегиях и св-вах, управление которыми доступно нам через выводимые и зависимые типы.

VD>Ясно опять пустые слова. Показать ты никаких приемуществ не можешь. Оно и понятно. Не может иметь приемуществ нетипобезопасный язык над типобезопасным.

По-моему все сказал.

VD>Аргументы? Нда. Ты бы хоть один пример привел.

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

VD>Аннулировать? Ты о чем? ООП для проектирования нужно применять, и для замены кривых прямолинейных решений.

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

V>>У нас не коллекции, а имплементации, но сути не меняет.

VD>Что такое "имплементации" я не знаю.

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

V>> Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

VD>За-то я знаю что кучи приведений говорит о качестве проектирования.

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

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

V>>Ну, используем CORBA в проекте. Там получаем сначала общую объектную ссылку по URI на клиенте, а потом выполняем статический метод MyClass_ptr MyClass::narrow(Object_ptr); Этот метод весьма типизирован и описан стандартным маппингом CORBA на C++. Не требуется обход защиты.

VD>Т.е. ты считашь, что приведение засунутое в narrow кошернее чем вызванное напрямую?

Да, там достаточно логики, т.к. иногда вызывается внутрення команда протокола у удаленного серверного объекта, этот метод протокола — "_is_a()", и позволяет получить другой интерфес объекта. Кстати, в CORBA этот момент проработан немного лучше, чем в .Net Remoting. Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает. А ведь вполне используемая техника (Interface1 -> Interface2) в локальных задачах, по крайней мере регулярно наблюдаю в коде на .Net.

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

VD>Хм... Я тоже для некоторых задач наверно предпочту С++. Разница у нас в том, что я предпочту С++ для 1% задач, а ты для 99%.

Если пошло такое оценивание, то я бы был более скурпулезен:

— формочки GUI -> .Net
— серверы бизнес-приложений (слово "бизнес" — ключевое, т.е. задачи типа — отсюда взять, туда положить) -> .Net
— вычисления -> C++
— компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)
— "продвинутые" текстовые редакторы -> С++
— редакторы графики -> С++
— САПР-ы -> С++
— движки БД -> С++
— движки 3D (не роперы, типа Managed DirectX, а именно движки) -> C+
— сетевые протоколы и фильтры -> С++
— маааленькие GUI приложения/утилитки -> все-таки С++, из-за того, что дотнетные приложения стартуют довольно долго независимо от размера, а маленькие GUI приложения на С++ — мгновенно.
— серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++
— моделирование объемных вещей (например, волнений моря или аэродинамика) -> C++
— для маленьких моделей допустим .Net

, например, промоделировать картину общего доступа к радиоточкам при количестве абонентов не более нескольких тысяч, если речь о многих миллионах, то я бы не рискнул выбрать .Net в качестве платформы.

V>>Как Java никуда не особо-то потеснила плюсы, так и дотнет не вытеснит.

VD>Да ява с дотнетом уже очень сильно их потеснила.

VD>Как тут кто-то очень хорошо сказал "безопасный язык является одной из обязательных составляющих получения надежного ПО".

V>> Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

По моим наблюдениям Java и дотнет гораздо более теснят весь остальной рынок: Дельфи, PHP/Perl и кучу другой всякой экзотики.
По сути, в живых остается Java, .Net и С++. Меж ними и раздел.

VD>А ведь именно офис, точнее Ворд, я хотел бы видеь в менеджед-виде в первую очередь. Уж больгл сильно он ключит.

Насколько я знаю, в основном плагины под него глючат. Но не в этом суть. Какой объем памяти потребует ворд для документа объемом > 2M, хотя бы???

Т.е., пока не все так гладко, как хотелось бы.

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

V>Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает.

Чего то не понял о чем ты. Объект либо реализует интерфейс, либо не реализует. Что такое "явно описано"?

V>- компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)

А у меня не входят даже 4. Что я делаю не так?

V>- "продвинутые" текстовые редакторы -> С++

Почему?

V>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

Почему?

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

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

V>>Кстати, а на какой технологии Microsoft собралась делать следующий офис?

VD>Чего не знаю, того не знаю. Слышал о перекомпиляции части Офиса в менеджед-режиме на МС++. Но какова цель этого действа непонятно.

VD>А ведь именно офис, точнее Ворд, я хотел бы видеь в менеджед-виде в первую очередь. Уж больгл сильно он ключит.
Лично я не связываю особых надежд с менеджед офисом. Дело в том, что глюки ворда, раздражающие лично меня, связаны вовсе не с низкоуровневой безопасностью. Там проблемы в архитектуре. То, что у него сейчас периодически срывает крышу при разметке таблиц — ну так и будет срывать. То, что у него сейчас применение стиля "список" сшибает все форматирование — ну так там достаточно заскриптовать то, что они делают. Если люди вместо прямой смены свойства "продолжать нумерацию предыдущего списка" вызывают метод типа "применить шаблон списка с такими-то параметрами" — ну так они и на дотнете будут его вызывать. И проблем типа "ой, у нас что-то не получилось, так что мы пожалуй закроемся и напишем в микрософт" меньше не станет — это ж либо InvaligOperationException либо NullReferenceException. Документы сохранять при падении они уже и так научились.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

S>Лично я не связываю особых надежд с менеджед офисом. Дело в том, что глюки ворда, раздражающие лично меня, связаны вовсе не с низкоуровневой безопасностью. Там проблемы в архитектуре. То, что у него сейчас периодически срывает крышу при разметке таблиц — ну так и будет срывать. То, что у него сейчас применение стиля "список" сшибает все форматирование — ну так там достаточно заскриптовать то, что они делают. Если люди вместо прямой смены свойства "продолжать нумерацию предыдущего списка" вызывают метод типа "применить шаблон списка с такими-то параметрами" — ну так они и на дотнете будут его вызывать. И проблем типа "ой, у нас что-то не получилось, так что мы пожалуй закроемся и напишем в микрософт" меньше не станет — это ж либо InvaligOperationException либо NullReferenceException. Документы сохранять при падении они уже и так научились.

Ты очень сильно заблуждаешся. Проблемы вроде не такоего форматирования как ожидалось хотя и могут досаждать, но решаемы и не так критичны. Лично у меня с этим особых проблем нет. Во всяком случае аналоги в сумме создают подобных проблем куда больше.

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

Я сейчас пишу статью про редактор кода написанный на шарпе, так вот в процессе ее написания я вылетел такое количество раз, что в какой-то момент я плюнул на ворд, написал для своего редактора автозамену (так как эта фича ворда мне нужна больше всего) и продолжил писать статью в своем редакторе. Причем сделал это я точно зная, что в редакторе есть ошибка приводящая к вызоду за границу массива! Я не сколько не испугался этого (смертельного для программ написанных на С++) глюка, так как максим что может произойти — вылетит диалог с сообщением об ошибке. Нажав "Continue" я спокойно продолжу работу.

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

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>Повторяю опять — в функцию передаем адрес буфера, куда данные возвращаются (из этой ф-ии). Подойдет любой пример.

Повторюсь, еще раз. Код в студию! И не нужно вешать лапшу на уши.

VD>>Ты под АПИ что имел в виду? И какое по-твоему саглашение использует ВиньАпи?

V>Кто сказал, что мне нужен только вынь-апи?

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

К тому же ты ведь делашь общее утверждение, что интероп-код не безопаснее лабания на С++. Так? Дык даже если безопаснее оказывается хотя бы вызов ВыньАпи, то твое утврждение уже не врено.

VD>>В любом случае контроль интеропа не сравним с ручной возней с типами в С++. Так что твои утверждния мягко говоря натянуты.

V>Я не понял смысла туманной фразы "с ручной возней с типами в С++". Если сигнатуры типизированы (без всяких void*), то возни нет в принципе.

И как ты хочешь вызвать АПИ типизированно? Даже при возне с КОМ-ом типизация то и дело идет лесом. Тут и там появляется код живущий на предположениях о совпадении типов. А уж при возне с разными handle-ами о типизации и речи быть не может.

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

V>Замечательно подходит абсолютно под все твои утверждения. Кстати весь предыдущий пост был написан в твоем стиле, не заметил?

Не заметил. Видимо ты постоянно пишешь "в моем стиле". Вот этот пост видимо тоже.

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

V>>> Программы все так же кишат ошибками (наблюдаю много их на C#).

VD>>Кишат, но не так же.

V>Нет так же. Кишат.

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

V>Хорошо. Реальная статистика.

Где?

V>Продолжая озвучивать свой опыт скажу, что отлов тех 15 ошибок, приводящих к крэшу — весьма легок. Лично я нахожу их мгновенно. Ну сразу в глаза бросаются места, где может быть ошибка. А вот ошибки логики приходится "пилить" порой долго и нудно. Тут затрачиваемый объем усилий совершенно несравним.

Ну, ты просто крут и этим все объясняется. А то что ваши продукты не заткнули всех конкурентов — так это происки врагов.

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

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

Да, совершенно не значимый. Типобезопасность это сказка и блеф. А фрэймворк удобный по каким-то загадочным причинам. Ну, а то что МС и Сан выпячивают эту типобезопасность на передний план, так это рекламная шумиха.

V>Я согласен лишь с тем, что при наличии ошибок дотнет помогает изолировать их от общего процесса (в серверах). Но он практически никак не помогает эти ошибки не делать (3% — это абсолютно несущественно).

Сдается мне, что твои 3% высасаны из пальца.

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

А ты не задумывался над тем, почему эта тонна написана на C#, а не на С++ и не оформлена в виде С++-ных файлов или библиотек?

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

V>Т.е., если быть честнее, то озвучивать стоит именно аргументы подобного плана, а не собственные "неприятные ощущения от С++", коими ты заливаешь все топики, вдалбливая в голову юношей незрелых незначащие аргументы.

То что мои аргументы тебя не удовлетворяют еще ничего не означает. Твои аргументы удовлетворяют в основном ярых адептов С++. Так что это просто разные точки зрения.

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

Просто ребята из МС взяли и реализовали в одном продукте те передовые идеи которые они смогли заметить. А ты пыташся свалить все на банальный объем библиотек, путая причину со следствием. Типа, ветер дует от того что деревья качаются.

V>Нет. Ты же говорил про опции unsafe?

Я говорил про безопасный код. Код сгенерированный Emit-ом не гарантированно безопасен.

V>А какого хрена TypeBuilder позволил нагенерить несовместимые инструкции???

Несовместимые с чем? Он позволяет сгенерировать любой msil-код. В том числе и небезопасный. Что видимо и произошло.

V> (код был не безопасный, он был принципиально неккоректный — в фомирование команд, предназначенных для классов, я подал тип структуры, и это никак не проверилось)

Что значит "я подал". Безопасный значит типобезопасный! В таком коде просто не должно быть возможности подсунуть один тип вместо другого. Код обяазан быть рассчитанн на определенные типы. Ну, нельзя подсунуть структуру туда где ожидается ссылка на класс. А если это можно, то код автоматически не типобезопасный.

VD>>И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

V>О, опять ты про "очевидное". Ну я тебе в ответ напоминаю про реальную стоимость твоего "очевидного" — 3%.

А я о высосаности этого процента из пальца.

V>Если ты рисуешь неправильно контрол, или у тебя логика в цикле пропускает последний/первый элемент, и т.д. и т.п. То результат будет одинаков, независимо от среды. Мне уже интересно, что у тебя там произошло с плюсами, что ты настойчиво повторяешь одно и то же? Ну не существенно это.

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

V>Кстати, а в плане рисования тех же контролов. Несмотря на то, что объектная модель и GDI+ более удобен, чем вынь-апи, я наблюдая гораздо больше ошибок и неккоректностей в реализайии контролов на C#. (Просмотри форум .Net GUI). Как ты подобну странность прокоментируешь???

А я как раз вижу только уменьшение количества ошибок и их проблематичности при использовании GDI+. Это очередное твое голословное утвержедение. Хотя тут язык в общем-то не причем. GDI+ — это С-шная библиотека. Просто она спроектирована в очень похожих на дотнет манере и заточена на паттерны работы с ресурсами используемые в дотнете.

V>Да про серверные понятно. Я же уже говорил, что не согласен с тем, что дотнет помогает делать меньше ошибок. Он их может помочь хоть как-то изолировать, в тех же серверах.

Очередной спор с очевидным. Да еще и загадочные фразы вроде "как-то изолировать".

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

V>>>В дотнете тоже нет. Там контроль на уровне компилятора.

VD>>Сможешь доказать это утверждение?

V>В смысле, сгенерить через TypeBuilder метод с переменной в стеке, например int, и вывести ее значение в Console без предварительного присвоения? Самому не смешно?

С локальными переменными я не прав. Однако первое же требование к безопсному коду — это полная инициализированность. Так что код порожденный компилятором не инициализирующим стековую переменную не будет проходить верификацию и не бует типобезопасным.

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

V>Если у меня в C# переменная объявлена как член класса, то ее инициализацию даже компилятор не проверяет. Разве что Решарпер.

Если переменная член класса, то она инициализируется нулевыми значениями еще при выделении памяти из хипа.

V>Как это память не портится при многопоточности. Именно в этом ошибки и проявляются. (Например, пишем в буфер что-то).

Так. У тебя может быть случай двойной записи в один объект, но никогда не будет случайной записи в произвольный объект (область памяти).

Я ловил как-то ошибки связанные с наложением многопоточности и прохода по памяти. Чертовски неприятное занятие. Наличие типобезопасности убирает одно измерение в котором нужно искать ошибку. Это очень не пало. Хотя и не является решением проблемы многопоточности.

V>На функциональных языках нелегко делать числодробилки. А любой бизнес-приложение, где есть хоть какая-то отчетность или промежуточная статистика того требуют.

Все с точносью до наоборот. Для рассчетов ФЯ подходят изумительно. Они же из математики свои корни берут. Не даром половина примеров в ФЯ — это вычислительная математика.

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

VD>>Ясно опять пустые слова. Показать ты никаких приемуществ не можешь. Оно и понятно. Не может иметь приемуществ нетипобезопасный язык над типобезопасным.

V>По-моему все сказал.

А ты покажи. Что языком то трепать? Ты "Покажи, плиз приемущества статической типизации в С++ в необобщенном коде." на примере. Ну, создай не обобщенный код который будет типобезопасным на С++ и который нельзя будет сделать типобезопасным на C#.

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

VD>>Аннулировать? Ты о чем? ООП для проектирования нужно применять, и для замены кривых прямолинейных решений.

V>Я вот не пойму о чем ты.

Это я не понимаю. Что все же значит "ее аннулировать"?

V> Ты экстрасенс, способен выдавать решения не видя постановки? Могу прислать на мыло небольшую часть постановки, а ты нам попытаешься количество сущностей уменьшить вдвое, ok?

ОК. Заплатите денег — сделаю.

V>>> Я уже ручками давно все сделал, просто показал явное место, где у нас куча динамических приведений. И это явно не на пользу эффективности.

VD>>За-то я знаю что кучи приведений говорит о качестве проектирования.

V>Это говорит о невозможности обощенного программирования в среде, которую используем прямо сейчас для коммерческих проектов.

Всегда можно найти приемлемое решение. Выкладывай примеры... поглядим.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>Я сейчас пишу статью про редактор кода написанный на шарпе, так вот в процессе ее написания я вылетел такое количество раз, что в какой-то момент я плюнул на ворд, написал для своего редактора автозамену (так как эта фича ворда мне нужна больше всего) и продолжил писать статью в своем редакторе. Причем сделал это я точно зная, что в редакторе есть ошибка приводящая к вызоду за границу массива! Я не сколько не испугался этого (смертельного для программ написанных на С++) глюка, так как максим что может произойти — вылетит диалог с сообщением об ошибке. Нажав "Continue" я спокойно продолжу работу.
Значит у нас с тобой разные паттерны использования ворда. Мой 2003 конечно падает, но ооочень редко. И с ревиженами он у нас отлично работал (правда, на объемах в пределах 50 страниц). Тока тормозил. А вот ошибок алгоритмического рода в нем великое множество.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

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

V>>Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает.

AVK>Чего то не понял о чем ты. Объект либо реализует интерфейс, либо не реализует. Что такое "явно описано"?

Например, на клиенте известен некий тип (наследник MBR), поддерживающий некий интерфейс, и клиент запрашивает этот объект по удаленному URI. На сервере реально сидит очередной его наследник, имплеиментирующий так же и другие интерфейсы, но этот тип наследника неизвестен на клиенте. Как их запросить на клиенте те другие интерфейсы?

V>>- компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)

AVK>А у меня не входят даже 4. Что я делаю не так?

А у тебя гиг или больше памяти или проекты небольшие.

V>>- "продвинутые" текстовые редакторы -> С++

AVK>Почему?

V>>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

AVK>Почему?

Оба ответа — из-за потребляемой памяти. Экономнее, чем в С++, вряд ли удасться обойтись с этим ресурсом.

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

V>Да, там достаточно логики, т.к. иногда вызывается внутрення команда протокола у удаленного серверного объекта, этот метод протокола — "_is_a()", и позволяет получить другой интерфес объекта. Кстати, в CORBA этот момент проработан немного лучше, чем в .Net Remoting. Попробуй в дотнете получить произвольный интерфейс у удаленного объекта, если явно не описано, что он этот интерфейс поддерживает. А ведь вполне используемая техника (Interface1 -> Interface2) в локальных задачах, по крайней мере регулярно наблюдаю в коде на .Net.

Тут я согласен с АВК. Тип есть тип. Или он релизует интрфейс или нет. Прокси содержит такое же описание что и сам класс. Так что о чем ты ведешь речь я не понял. Поясни.

V>Если пошло такое оценивание, то я бы был более скурпулезен:

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

V>- вычисления -> C++

Многие компиляторы С++ уже сегодня проигрывают в вычислительных тестах дотнету и Яве. А учитыва, что в дальнейшем компиляторы того же МС будут делаться на базе общего бэк-энда — это утверждение вообще становится сомнительным.

V>- компиляторы -> С++ (на машине с Resharper у меня две студии просто входят в ступор при обычной работе, с VA такого не было)

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

Безосновательность этого утверждения так же подтверждается тем, что R# и компилятор Моно написаны на чистом C#. При этом особых проблем не заметно. А вот удобство видно сразу. АСТ на C# просто иделно в отличии от плюсового.

V>- "продвинутые" текстовые редакторы -> С++

Это типа Синтилы и редатора VS? Спешу тебя огорчить. Я как раз тут по случаю один написал. Особых пролем не заметил. Наоборот получилось намного проще.

V>- редакторы графики -> С++

Опять же есть реализации на C# и опять же не вдино неприодалимых трудностей.

V>- САПР-ы -> С++

А здесь, то что?

V>- движки БД -> С++

Движки БД даже на Яве есть. А уж на шарпе, на котором ОС делать пытаются и подавно это осуществимо.

V>- движки 3D (не роперы, типа Managed DirectX, а именно движки) -> C+

3D-движки работают поверх DirectX или OpenGL. И есть не одна реализация менеджед-движка. Некоторые по проивзодительности обходят родителей.

V>- сетевые протоколы и фильтры -> С++

Для каких ОС? Есл для написанных на С, то конечно. Если для какой-нить Сингулярити, то однозначно нет.

V>- маааленькие GUI приложения/утилитки -> все-таки С++, из-за того, что дотнетные приложения стартуют довольно долго независимо от размера, а маленькие GUI приложения на С++ — мгновенно.

Ну, будучи скомпилированными (а то и приджитнутыми) на втором фрэймворке приложения запускаются очень даже шустро (на относительно современном железе). Для калькулятора или блокнока более чем достаточно, по крайней мере. Хотя кое где действительно С++-ные программки (в прочем как и Дельфевые, например) все же имеют приемущество. Например, если нужно встроить Хук в чужие процессы, то конечно грузить в каждый из них CLR не разумно. Но это опять таки речь о создании модулей для ОС созданных на С. Для ОС созданой на Шарпе проблем не будет. CLR ведь и так будет в любом процессе и загрузка будет молниеносной.

V>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

У нас на сервере бэкапы дифятся программкой написанной на C# первой версии. Объем БД под 4 гига. И ничего справляется. Сайт весь на C# и перекачивает десятки гиг в день отвечая на запросы 15 тысяч пользователей. И при этом CVS на дотнете написат нельзя. Не уж-то исходники такие огромные? Ну, не поверю я в команду программистов состоящую из 15 000 человек комитящую исходники по 400 штук за раз.

V>- моделирование объемных вещей (например, волнений моря или аэродинамика) -> C++

Тут то что за проблемы? Оптимизатор? Тогда см. выше.

V>- для маленьких моделей допустим .Net

, например, промоделировать картину общего доступа к радиоточкам при количестве абонентов не более нескольких тысяч, если речь о многих миллионах, то я бы не рискнул выбрать .Net в качестве платформы.

В общем, попытайся обосновать хотя эти свои утверждения. Лично для меня они выглядят смехотворно.

Мой список задач не для дотнета:
1. Код создаваемый для систем где проблематично встраивание CLR (например, встраеваемые системы написанные на С).
2. Создание модулей расширения ОС написанных на неуправляемых языках (драйверы, перехватчики клавиатурных нажатий и т.п.).
3. Системы рельного времени (и то до тех пор пока не создан RTS-CLR).
4. Мелкие утилиты предназначенные для скачивания через слабые Интернет-каналы. И то до тех пор пока фрэймворк не расползется на все машины. Полсе того как Лонгхорн стане основной ОС и этот фактор уйдет в прошлое. Даже на поборот, дотнетные модули будут существнно меньше по объему.
5. Применение при разработке ПО опасного для жизни и здоровья людей. Ну, это потому что фрэймворк от МС на С++ частично написан.

Если какая нибудь Сингулярити дойдет до релиза и в ней реализуют RTS-CLR, то и это будет возможно. (мечты-мечты). Однако этот пункт для С++-программ принципиально должен быть закрыт.

V>>> Просто эти платформы корчуют "новые" рынки (распределенные приложения, например), и теснят всякие Дельфи и ActiveX с территории GUI.

V>По моим наблюдениям Java и дотнет гораздо более теснят весь остальной рынок: Дельфи, PHP/Perl и кучу другой всякой экзотики.
V>По сути, в живых остается Java, .Net и С++. Меж ними и раздел.

О! Ты уже сам с собой споришь.

Кстати, ActiveX-рынок — это С++-рынок. Еще немгого и С++ на рынке ПО для бизнеса будет нонсоном. Глядишь через 10 лет останутся только низкоуровневые феньки для ОС. Даже расширения ОС будут на дотнете, так как в Лонгхорне пол Эксплорера на нем.

V>Насколько я знаю, в основном плагины под него глючат. Но не в этом суть.

Ну, если ревижены — это плагины, то возможно. Меня вот этот режим больше всего напрягает.

V> Какой объем памяти потребует ворд для документа объемом > 2M, хотя бы???

Предположим даже 100 метров. Мне плевать. У меня ее гиг. 10% я переживу. А 2 метра — это очень большой документ.

V>Т.е., пока не все так гладко, как хотелось бы.

Вот тут нельзя не согласиться. До золотых гор еще далеко. Ворд похоже еще долго будет глючить. Но прогресс на лицо.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

V>>Повторяю опять — в функцию передаем адрес буфера, куда данные возвращаются (из этой ф-ии). Подойдет любой пример.

VD>Повторюсь, еще раз. Код в студию! И не нужно вешать лапшу на уши.

Просто облом было писать эти 2 строки, неужели непонятно выразился???

держи:

p2.cpp

#include "stdafx.h"
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

__declspec(dllexport)
int __stdcall f1(wchar_t *str) {
    static wchar_t str1[] = L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!"
        L"HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!HELLO!";

    memcpy(str, str1, sizeof(str1));

    return sizeof(str1)/sizeof(wchar_t);
}

f1() — возвращает данные в буфер, аналогично работают все API-функции связанные с глобализацией. (возвращают форматы, строки и т.д.)

p2.def

EXPORTS
f1

(это чтобы подавить name-mangling)

C#

    class Class1
    {
        static void Main(string[] args)
        {
            string s;
            f1(out s);
            Console.WriteLine(s.ToString());
        }

        [DllImport("p2", CallingConvention = CallingConvention.Cdecl)]
        static extern int f1(out string sb);
    }

До команды Console.WriteLine(s.ToString()); программа не доходит. Приложение молча схлопывается без единого сообщения об ошибке.

Я получал еще более интересные эффекты пару лет назад (ну нет ТОГО кода, он давно исправлен и работает). Так вот эффект заключался в том, что у меня в строке был мусор ооочень большой длины. Не иначе как проход по памяти, откуда взяться мусору длиной в несколько килобайт, если АПИ ф-ии глобализации возвращают самое длинное слово "Понедельник".

V>>Кто сказал, что мне нужен только вынь-апи?

VD>Ну, мне так ничего больше и не нужно. Но если тебе нужно, то приведи пример.

Z-lib, да и вообще, интероп он именно интероп — взаимодействие с унаследованным кодом, а не с вынь-апи. Они предполагали, что с ней, родимой, как раз возится и не надо — фреймворк по идее на себя все взять должен был.

VD>К тому же ты ведь делашь общее утверждение, что интероп-код не безопаснее лабания на С++. Так? Дык даже если безопаснее оказывается хотя бы вызов ВыньАпи, то твое утврждение уже не врено.

Что-то логика отсутствует.

VD>>>В любом случае контроль интеропа не сравним с ручной возней с типами в С++. Так что твои утверждния мягко говоря натянуты.

V>>Я не понял смысла туманной фразы "с ручной возней с типами в С++". Если сигнатуры типизированы (без всяких void*), то возни нет в принципе.

VD>И как ты хочешь вызвать АПИ типизированно? А уж при возне с разными handle-ами о типизации и речи быть не может.

Windows.h в опцией STRICT дает именно типизированное АПИ, т.е. хендлы именно типизированы, перепутать невозможно без явного обхода защиты.

VD>Даже при возне с КОМ-ом типизация то и дело идет лесом. Тут и там появляется код живущий на предположениях о совпадении типов.

Бинарная сериализация тоже исходит из предположения о совпадении типов. COM работает из предположения, что контракт на интерфейс соблюдается всеми сторонами. Что не так? (Более того, однажды введенный интерфейс не подлежит модернизации)

VD>В общем, твои утверждения о неотличимости безопасности интеропа от прямой работы с указателями и т.п. в С++ не соотвествует действительности. Проблемы конечно можно поиметь и с интеропом, но контроль в нем таки есть. Все же маршалинг может отловить кучу ошибок.

Не отловил. Молча схлопнулся. В реальном приложении — потеря данных. Я добивался эффекта, когда не схлопывался, но данные получал глючные. Поиграть надо размером строк и взаимными ситуациями.

VD>В общем, кончай сотрясать воздух и попробуй поэксперементировать с интеропом. Уверяю тебя ждет немало интересного.

Я уже прошел через немало интересного. Чем вызвано твое недоверие к сообщениям коллег — непонятно.

V>>Хорошо. Реальная статистика.

VD>Где?

В предыдущем посте.

V>>Продолжая озвучивать свой опыт скажу, что отлов тех 15 ошибок, приводящих к крэшу — весьма легок. Лично я нахожу их мгновенно. Ну сразу в глаза бросаются места, где может быть ошибка. А вот ошибки логики приходится "пилить" порой долго и нудно. Тут затрачиваемый объем усилий совершенно несравним.

VD>Ну, ты просто крут и этим все объясняется. А то что ваши продукты не заткнули всех конкурентов — так это происки врагов.

И с чего ты всегда изобретаешь? Продукт используется очень крупной фирмой в штатах. Могу на мыло дать название фирмы — ты ее прекрасно знаешь и даже сам пользуешься ее продуктами/товарами.

VD>Да, совершенно не значимый. Типобезопасность это сказка и блеф. А фрэймворк удобный по каким-то загадочным причинам. Ну, а то что МС и Сан выпячивают эту типобезопасность на передний план, так это рекламная шумиха.

Ну и пусть они выпячивают, тебе-то чего? Тебе за рекламу платят?

Существует мнение, что программ без ошибок не бывает. Далее, я привел тебе РЕАЛЬНУЮ статистику распределений ошибок немаленького проекта, где участвовал весьма разношерстный коллектив в плане скилов. Ты продолжаешь брыкаться и все отрицать совершенно беспричинно.

V>>Я согласен лишь с тем, что при наличии ошибок дотнет помогает изолировать их от общего процесса (в серверах). Но он практически никак не помогает эти ошибки не делать (3% — это абсолютно несущественно).

VD>Сдается мне, что твои 3% высасаны из пальца.

Надо писать так: высосаны.
И желательно по другому поводу. Корректней тебе было бы сказать: "меня твоя статистика не устраивает".

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

VD>А ты не задумывался над тем, почему эта тонна написана на C#, а не на С++ и не оформлена в виде С++-ных файлов или библиотек?

Блин, ну в рефлектор загляни, а??? Как ни интересный момент — так ф-ия с внутренней линковкой. А на чем написаны остальные A+B это вообще не важно. Учитывая, что C# от VB.Net недалеко ушел, то я и говорить не стану, почему...

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

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

К тому же, не забывай про настпление Java и метод "ответных ходов".

V>>Т.е., если быть честнее, то озвучивать стоит именно аргументы подобного плана, а не собственные "неприятные ощущения от С++", коими ты заливаешь все топики, вдалбливая в голову юношей незрелых незначащие аргументы.

VD>То что мои аргументы тебя не удовлетворяют еще ничего не означает. Твои аргументы удовлетворяют в основном ярых адептов С++. Так что это просто разные точки зрения.

Мои аргументы — реальная статистика. А твои — лишь личные ощущения. Я вообще ввязался в ветку с целью хоть как-то уравновесить твои огульные высказывания и попытаться расставить акценты более правильно.

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

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

VD>Просто ребята из МС взяли и реализовали в одном продукте те передовые идеи которые они смогли заметить. А ты пыташся свалить все на банальный объем библиотек, путая причину со следствием. Типа, ветер дует от того что деревья качаются.

Мдааа... Идеи ради идей... приплыли.

Этот аспект не продвигает даже сама Microsoft. Они как раз прикладную платформу с тонной функционала и двигают. Или, по твоему, можно двигать голые идеи сейчас, когда есть мегатонны унаследованного кода.

Только предоставив готовую реализацию многого из того самого унаследованного кода, можно пытаться хоть как-то это двигать.

И про язык C# они говорят вполне скромно — mainstream for .Net. А в самом дотнете более выделяют его потенциальную роль как связующего элемента для проектов на различных языках и его возможность быстро строить сложные приложения, ввиду мощной поддержки фреймворком.

V>> (код был не безопасный, он был принципиально неккоректный — в фомирование команд, предназначенных для классов, я подал тип структуры, и это никак не проверилось)

VD>Что значит "я подал". Безопасный значит типобезопасный! В таком коде просто не должно быть возможности подсунуть один тип вместо другого. Код обяазан быть рассчитанн на определенные типы. Ну, нельзя подсунуть структуру туда где ожидается ссылка на класс. А если это можно, то код автоматически не типобезопасный.

Я имел ввиду тот факт, что генерирование неверной IL-команды могло быть предотвращено самим TypeBulder-ом (MethodBuilder-ом), если бы потщательнее подошли к вопросу.

VD>>>И разницы с плюсовыми программами не видишь? Ну, тут говорить не о чем. Опровергать оспаривание очевидного работа не для меня.

V>>О, опять ты про "очевидное". Ну я тебе в ответ напоминаю про реальную стоимость твоего "очевидного" — 3%.

VD>А я о высосаности этого процента из пальца.

Правильно писать так: высосанности.

V>>Если ты рисуешь неправильно контрол, или у тебя логика в цикле пропускает последний/первый элемент, и т.д. и т.п. То результат будет одинаков, независимо от среды. Мне уже интересно, что у тебя там произошло с плюсами, что ты настойчиво повторяешь одно и то же? Ну не существенно это.

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

Ладно, это лирика все. Если у тебя операция записи зависит от расчитанного индекса, то используй контейнер с проверкой диапазонов.

VD>Далее следуют бессонные ночи в поиске истинной ошибки. Если ошибка ловится верификаторами, то хорошо, а если они не были заточены на нее, то приплыли.

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

V>>Кстати, а в плане рисования тех же контролов. Несмотря на то, что объектная модель и GDI+ более удобен, чем вынь-апи, я наблюдая гораздо больше ошибок и неккоректностей в реализайии контролов на C#. (Просмотри форум .Net GUI). Как ты подобну странность прокоментируешь???

VD>А я как раз вижу только уменьшение количества ошибок и их проблематичности при использовании GDI+. Это очередное твое голословное утвержедение. Хотя тут язык в общем-то не причем. GDI+ — это С-шная библиотека. Просто она спроектирована в очень похожих на дотнет манере и заточена на паттерны работы с ресурсами используемые в дотнете.

Ты не понял. Я просил тебя просмотреть топик .Net GUI и оценить общий уровень контролописательства сейчас. (несмотря на более удобную объектную модель контрола и GDI+ как листа для рисования). Когда я только познакомился с дотнетом, то воспринял задачу написания контролов в этой среде как разновидность развлечения (настолько это было проще чем в вынь АПИ и даже в MFC/ATL).

Так что же не так, а? Почему так туго-то?

А может быть, С++ дает (вернее — требует, а оттого и дает) больше понимания в сути происходящих вещей?

Вот ты прошел через С++ и многое другое. Теперь ты прекрасно понимаешь, что и как именно происходит в дотнет, а потому адекватно используешь этот инструмент. А как быть тем, кто с него начинает?

Кстати, я более чем уверен, что посади тебя после дотнета опять на С++ (ну мало ли, вообразим ситуацию, что тебе за это стали платить $100к в месяц), то ты будешь писать совсем не так, как раньше (до дотнета). И ты будешь искать способы писать безопасный софт и найдешь их, никуда не денешься.

V>>Да про серверные понятно. Я же уже говорил, что не согласен с тем, что дотнет помогает делать меньше ошибок. Он их может помочь хоть как-то изолировать, в тех же серверах.

VD>Очередной спор с очевидным. Да еще и загадочные фразы вроде "как-то изолировать".

Что тут загадочного? Логические ошибки могут портить общие данные, например.

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

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

VD>С локальными переменными я не прав. Однако первое же требование к безопсному коду — это полная инициализированность. Так что код порожденный компилятором не инициализирующим стековую переменную не будет проходить верификацию и не бует типобезопасным.

Хммм. посмотрим

VD>В общем, не важно кто обеспечивает типобезопасность. Важно что она обеспечивается в полном объеме, а не доводится до некоторого уровня утилитами по отлову потенциальных глюков.

Если неважно кто обеспечивает типобезопасность, то мне VC7.1 достаточно

V>>Если у меня в C# переменная объявлена как член класса, то ее инициализацию даже компилятор не проверяет. Разве что Решарпер.

VD>Если переменная член класса, то она инициализируется нулевыми значениями еще при выделении памяти из хипа.

В С++ аналогично.

V>>На функциональных языках нелегко делать числодробилки. А любой бизнес-приложение, где есть хоть какая-то отчетность или промежуточная статистика того требуют.

VD>Все с точносью до наоборот. Для рассчетов ФЯ подходят изумительно. Они же из математики свои корни берут. Не даром половина примеров в ФЯ — это вычислительная математика.

Я имел ввиду Лисп, когда писал это. Не подходит он для числодробилок из-за своего быстродействия. Пролог аналогично.

VD>А ты покажи. Что языком то трепать? Ты "Покажи, плиз приемущества статической типизации в С++ в необобщенном коде." на примере. Ну, создай не обобщенный код который будет типобезопасным на С++ и который нельзя будет сделать типобезопасным на C#.

Ага, кажется я понял, где тебя зацепило. Слово необобщенный - лишнее, я это не имел ввиду, иначе речь у нас шла бы не о С++. Позволь, все-таки, говорить об обощенном коде и о том, где я вижу бенефиты С++ даже по сравнению с C# 2.0.

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

Например, у нас стоит задача эмулировать нечто из фиизики. Я могу вводить обощенные типы-заместители элементарным типам, которые не отберут ни тика в runtime. Затем вводить более конкретные типы, например Velocity, Mass, Time и т.д.

Затем могу переопределять глобальные операторы так, чтобы Time * Velocity возвращала тип Distance. Суть понятна?

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

Могу я аналогичное сделать на C#? — НЕТ!!!
Насчет обобщенных вычислений и value-типов там какая-то непродуманность. Мне придется многое копипейстить ручками, чтобы получить "нормальный" синтаксис.

А в С++ я один раз опишу тип, например:

template<typename numberT, typename uniqT>
struct number_wrapper {
// тут операции
};

Затем сделаю что-то типа такого:

struct Kind{ struct Time{}; struct Velocity {}; }

typedef number_wrapper<double, Kind::Time> Time;
typedef number_wrapper<double, Kind::Velocity> Velocity;

inline Distance operator*(const Time& t, const Velocity& v) 
{ return Distance(t.value * v.value); }

(последнюю ф-ию можно сделать шаблонной, не стал писать лишнее, хочу показать суть)

V>> Ты экстрасенс, способен выдавать решения не видя постановки? Могу прислать на мыло небольшую часть постановки, а ты нам попытаешься количество сущностей уменьшить вдвое, ok?

VD>ОК. Заплатите денег — сделаю.

Уверен, что уменьшишь?

V>>Это говорит о невозможности обощенного программирования в среде, которую используем прямо сейчас для коммерческих проектов.

VD>Всегда можно найти приемлемое решение. Выкладывай примеры... поглядим.

Пример простой.

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

Я не хочу в коде приводить результаты/агрументы методов фабрик и десткрипторов к конкретному типу бизнес-объекта, т.е. нужны типизированные методы — обертки. Про них речь и шла.

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

V>Например, на клиенте известен некий тип (наследник MBR), поддерживающий некий интерфейс, и клиент запрашивает этот объект по удаленному URI. На сервере реально сидит очередной его наследник, имплеиментирующий так же и другие интерфейсы, но этот тип наследника неизвестен на клиенте. Как их запросить на клиенте те другие интерфейсы?

А в чем проблема? В ObjRef передаются все публичные интерфейсы, которые реализует объект. Следовательно если локально эти интерфейсы доступны, то и приведение к ним работает. Если же хочется каких то извращений, то можно отказаться от стандартной механики и формировать сообщения собственным способом. Только вот непонятно зачем это может понадобиться. Я конечно не сторонник SOA, но мысль о том, что не стоит слишком уж сильно равнять локальные и удаленные вызовы вполне здравая.

AVK>>А у меня не входят даже 4. Что я делаю не так?

V>А у тебя гиг или больше памяти

Гиг. А у тебя что, меньше?

V> или проекты небольшие.

17 мег исходников в 3.5К файлов. Достаточно?

V>>>- "продвинутые" текстовые редакторы -> С++

AVK>>Почему?

V>>>- серверные приложения, предназначенные для переливки и обработки больших объемов данных (напр. CVS сервер) -> C++

AVK>>Почему?

V>Оба ответа — из-за потребляемой памяти. Экономнее, чем в С++, вряд ли удасться обойтись с этим ресурсом.

А оно надо? Мне лично от экономии пары мег оперативки ни холодно ни жарко.

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

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

VD>Несовместимые с чем? Он позволяет сгенерировать любой msil-код. В том числе и небезопасный. Что видимо и произошло.

Да не, небезопасный бог бы с ним. Он позволяет сгенерировать код невалидный (к примеру позвать приватный метод извне напрямую, без рефлекшена). А попытка выполнить невалидный код приводит к тому что JIT выкидывает тот самый ужасный ExecutionEngineException.

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

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

V>Например, у нас стоит задача эмулировать нечто из фиизики. Я могу вводить обощенные типы-заместители элементарным типам, которые не отберут ни тика в runtime. Затем вводить более конкретные типы, например Velocity, Mass, Time и т.д.

V>Затем могу переопределять глобальные операторы так, чтобы Time * Velocity возвращала тип Distance. Суть понятна?
Тут можно поступить горазо болие цинично.
Определяем одни шаблон

template<class NumType, int Time, int Distance>
struct PhysicType
{
    explicit PhysicType(NumType value)
        :value(value)
    {}
    
    friend PhysicType operator + (PhysicType const& l, PhysicType const &r)
    {
        return PhysicType(l.value + r.value);
    }
    
    friend PhysicType operator - (PhysicType const& l, PhysicType const &r)
    {
        return PhysicType(l.value - r.value);
    }
    
    template<int Time1, int Distance1, int Time2, int Distance2>
    friend PhysicType<NumType, Time1 + Time2, Distance1 + Distance2> operator * (PhysicType<NumType, Time1, Distance1> const& l, PhysicType<NumType, Time2, Distance2> const &r)
    {
        return PhysicType<NumType, Time1 + Time2, Distance1 + Distance2>(l.value * r.value);
    }
    
    template<int Time1, int Distance1, int Time2, int Distance2>
    friend PhysicType<NumType, Time1 - Time2, Distance1 - Distance2> operator / (PhysicType<NumType, Time1, Distance1> const& l, PhysicType<NumType, Time2, Distance2> const &r)
    {
        return PhysicType<NumType, Time1 - Time2, Distance1 - Distance2>(l.value / r.value);
    }
    
private:
    NumType value;
};
typedef PhysicType<float, 1, 0> Time;
typedef PhysicType<float, 0, 1> Distance;
typedef PhysicType<float, -1, 1> Velocity;
typedef PhysicType<float, -2, 1> Acceleration;

Идея я думаю ясна...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

Правда, выглядеть аналогичный шаблон для 20-ти связанных величин будет страшно, не находишь?

Хотя, сэкономит кучу строк кода.

К тому же, автоматически разгребет ситуацию, типа 2*S/t^2. (т.е. тип промежуточной величины t^2 будет введен самостоятельно, хе).

Спасибо за идею!

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

V>Да, идея прикольная. И расширяемая на другие физические величины.
V>Правда, выглядеть аналогичный шаблон для 20-ти связанных величин будет страшно, не находишь?

Re[12]: В поисках семантической корректности

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

S>Значит у нас с тобой разные паттерны использования ворда. Мой 2003 конечно падает, но ооочень редко. И с ревиженами он у нас отлично работал (правда, на объемах в пределах 50 страниц). Тока тормозил. А вот ошибок алгоритмического рода в нем великое множество.

Отлично говоришь? Открой документ с 15+ коментариями и правками и попробуй просто добавить кментарий. Погляди как временами глючит окошко со списком коментариев. А если попишешь по дольше то наткнешся на класскую бяку... это окно просто перестает принимать ввод и если пишешь не в слепую, то можно просто потяреть все написанное. Ну, а когда это дело пересикается с ревижонами, то переодически начинаются вылеты.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

VD>В общем, тут вопрос в общеме работы с Вордом.
Ну прямо мои слова

VD>Просто мы слишком часто с ним трахаемся, вот и нарываемся на глюки. А на пустом новом документе глюков в общем-то нет.
Просто у нас редко бывает 15+ ревижнов. Мы обычно просто включаем track changes и все. При этом вся история никого не интересует; очередной ревьюер просто принимает все те правки, с которыми согласен. Поэтому проблем и не испытываем. Ревижны я как-то пробовал использовать — не понравилось. Документ пухнет со страшной скоростью, а никаких удобств они не добавляют.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

FDS>Дело в том, что компилятор можно вполне научить распознавать нужные ситуации. Знания семантики тут не требуется. Ему нужно только распознать возможные ситуации, а программист сам сделает всё остальное

А ещё его можно научить писать программы по одному лишь ТЗ. Но вот сколько же сил придется вложить в это обучение.

С уважением, Василий. Posted by RSDN@HOME.

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

S>Просто у нас редко бывает 15+ ревижнов. Мы обычно просто включаем track changes и все. При этом вся история никого не интересует; очередной ревьюер просто принимает все те правки, с которыми согласен. Поэтому проблем и не испытываем. Ревижны я как-то пробовал использовать — не понравилось. Документ пухнет со страшной скоростью, а никаких удобств они не добавляют.

В выделенном скорее всего и разница. Я заметил, что Ворд особенно глючит когда правок много.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

V>До команды Console.WriteLine(s.ToString()); программа не доходит. Приложение молча схлопывается без единого сообщения об ошибке.

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

VD>>К тому же ты ведь делашь общее утверждение, что интероп-код не безопаснее лабания на С++. Так? Дык даже если безопаснее оказывается хотя бы вызов ВыньАпи, то твое утврждение уже не врено.

V>Что-то логика отсутствует.

Да уж. Напрочь. Если ты даже этого понять не можешь.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

AVK>...JIT выкидывает тот самый ужасный ExecutionEngineException.

А чем он так ужасен?

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

V>>До команды Console.WriteLine(s.ToString()); программа не доходит. Приложение молча схлопывается без единого сообщения об ошибке.

VD>Вот то-то и оно, что не доходит. И ты без труда найдешь место с ошибкой. И это при том, что ты указал не вреный кол-конвеншон.

Так ведь — специально неверный, ты уже забыл начало?

Когда у меня схлопывается приложение С++, я тоже без труда нахожу ошибку, и именно потому, что приложение куда-то не доходит. О чем мы спорим?

V>>Ты тут нам обещал продемонстрировать простоту прохода по памяти с помощью интеропа. И наложенные глюки появляющиеся после этого. Вот и продемонстрируй. А не сможешь, так просто признай, что интпроп с его маршалингом значительное безопаснее прямого вызова в С++.

Приложение схлопнулось от прохода по памяти. Я добивался эффектов (неспециально), когда не схлопывалось. Это зависит, знаешь ли, от взаимного расположения байт в памяти и звезд на небе.

Ты же специалист, должен понимать, что чудес не бывает. И что не все дыры интеропа можно заткнуть с помощью специальных magic numbers, которые щедро рассыпает в памяти имплементация от Microsoft, в надежде поймать эти проходы.

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

VD>>>К тому же ты ведь делашь общее утверждение, что интероп-код не безопаснее лабания на С++. Так? Дык даже если безопаснее оказывается хотя бы вызов ВыньАпи, то твое утврждение уже не врено.

V>>Что-то логика отсутствует.

VD>Да уж. Напрочь. Если ты даже этого понять не можешь.

Да нет, просто фраза "хотя бы" притянута. Кстати, а ты смотрел на WFC? Если нет, потрать 2 мин, плиз, и скажи потом — так что безопасней, интероп или явная типизация/обертки?

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

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

AVK>>...JIT выкидывает тот самый ужасный ExecutionEngineException.

VD>А чем он так ужасен?

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

От:	FDSC	consp11.github.io блог
Дата:	13.06.05 12:41
Оценка:

От:	Oyster	https://github.com/devoyster
Дата:	13.06.05 12:52
Оценка:	+7 -2

От:	FDSC	consp11.github.io блог
Дата:	13.06.05 13:09
Оценка:	-5

	От:	Cyberax
	Дата:	13.06.05 13:09
	Оценка:	6 (1) +1

От:	FDSC	consp11.github.io блог
Дата:	13.06.05 13:13
Оценка:

	От:	0xDEADBEEF
	Дата:	13.06.05 13:22
	Оценка:	8 (2) +3 -2

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	13.06.05 14:27
Оценка:	1 (1) -1

От:	VladD2	www.nemerle.org
Дата:	13.06.05 16:32
Оценка:

От:	tarkil	http://5209.copi.ru/
Дата:	14.06.05 09:38
Оценка:

	От:	Трурль
	Дата:	14.06.05 09:47
	Оценка:	1 (1)

От:	Gaperton	http://gaperton.livejournal.com
Дата:	14.06.05 11:56
Оценка:	+4

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	14.06.05 12:42
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	14.06.05 13:57
Оценка:	1 (1) +1

От:	Mr. None	http://mrnone.blogspot.com
Дата:	15.06.05 03:26
Оценка:	+1

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	15.06.05 03:46
Оценка:

	От:	WolfHound
	Дата:	16.06.05 09:24
	Оценка:	14 (1) +1

	От:	Дарней
	Дата:	16.06.05 09:41
	Оценка:	21 (1)

	От:	vdimas
	Дата:	17.06.05 21:00
	Оценка:	1 (1) +1 -2

	От:	Павел Кузнецов
	Дата:	19.06.05 22:42
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	24.06.05 08:49
Оценка:	1 (1)

От:	ЯпонИц	www.yaponiz.com
Дата:	29.06.05 09:38
Оценка: