Re[3]: Применим ли Си++ в серьезном коде?
От: Шахтер Интернет  
Дата: 12.06.04 03:19
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

G>>Да чушь полная. ООП — это такой же инструмент как и любой другой. Все зависит от того

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

MSS>Типичное возражение, и совершенно неверное.


MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.


MSS>Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.


MSS>Использование оператора сдвига для печати — в минус.


MSS>Это вопросы азов эргономики.


size_t s=...;

printf("%u\n",s);


Слабо найти и исправить баг в этом коде? Как там с азами эргономики поиска багов?
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[5]: Применим ли Си++ в серьезном коде?
От: Шахтер Интернет  
Дата: 12.06.04 03:19
Оценка:
Здравствуйте, VladD2, Вы писали:

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


E>>P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.


VD>Можно узнать чем ООП может помешать драйверам?


Имея соответстующий опыт, могу уверено сказать -- поможет. Наблюдая, как люди средствами C изображают полиморфизм, например, хочется плякать.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[3]: Применим ли Си++ в серьезном коде?
От: Шахтер Интернет  
Дата: 12.06.04 03:19
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>> Творческое пользование темплейтами также сможет доставить потомкам

MSS>>> немало приятных минут.
S>>Бывает. Но если нет шаблонов, то вместо них на помощь приходят макросы... А
S>>это вообще жопа.

MSS>Темплейты как раз хорошая фича. Одна из лучших в Си++.


MSS>>> Вышли из блока -- значит, вышли, и нечего кроме.

S>>И забыли закрыть половину хэндлов....

MSS>Сразу видно. Локально видно. Легко править.


Сказок, пожалуйста, не надо рассказывать.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[11]: Применим ли Си++ в серьезном коде?
От: Шахтер Интернет  
Дата: 12.06.04 03:39
Оценка: +1
Здравствуйте, AndreyT, Вы писали:

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

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


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


AT>Когда Максим говорит про перегрузку, он совершенно прав.

AT>Правило коммутативности обязано выполнятся, стало быть, те ситуации, которые по разному интерпретируют (a+b) и (b+a) должны идти в сад. Во избежание.

Сложение строк не коммутативно.

AT>Maxim S. Shatskih, мой respect.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[12]: Применим ли Си++ в серьезном коде?
От: Дарней Россия  
Дата: 12.06.04 06:27
Оценка:
Здравствуйте, VladD2, Вы писали:

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

к примеру, "ленивые вычисления" были бы весьма полезны
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: Применим ли Си++ в серьезном коде?
От: Геннадий Майко США  
Дата: 12.06.04 08:33
Оценка: 13 (2)
Здравствуйте, Maxim S. Shatskih, Вы писали:


MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.

--
С последней фразой можно поспорить.
Например, интересно проследить тенденцию в рекомендациях использования языка программирования для системного программирования от той же самой Microsoft.

Если раньше Microsoft не рекомендовала вообще использовать С++ в программировании драйверов, то в последних их докуметнах и презентациях уже встречаются слова типа "Microsoft neither endorses nor prohibits the use of C++ for kernel-mode drivers" (здесь) или "We moved the development language debate from Assembly versus C to C versus C++", а в DDK уже сравнительно давно встречаются примеры кода, написанного на С++ (см. src\wdm\audio\msvad\savedata.*).

С уважением,
Геннадий Майко.
Re[8]: Применим ли Си++ в серьезном коде?
От: Дарней Россия  
Дата: 12.06.04 08:35
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Longhorn?
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Применим ли Си++ в серьезном коде?
От: vstrogov Россия  
Дата: 12.06.04 10:23
Оценка:
Здравствуйте, Дарней, Вы писали:

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


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


Д>Longhorn?


Нет, это NT
Re[8]: Применим ли Си++ в серьезном коде?
От: Воронков Василий Россия  
Дата: 12.06.04 10:24
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


А что такое "жлабэйсик"?
... << Rsdn@Home 1.1.4 beta 1 >>
Re[9]: Применим ли Си++ в серьезном коде?
От: vstrogov Россия  
Дата: 12.06.04 10:51
Оценка:
VD>>Я вот жду когда же все таки (и кто) решится на написание ОС следущего поколения. NT ведь в свое время была написана с чистого листа (только на основе опыта и знаний). Сейчас как раз такой же момент. Опыта и знаний накопилось много. Имеющиеся ОС уже настолько перелатаны, что развивать их далее уже сложно. Пора знаете ли таки сделать каую-нить Каиру.



Не стоит рассматривать вещи отвлеченно от жизни и бизнеса.

Гейтс однажды сказал примерно следующее: "То, что сделали Дейв(Катлер) и другие, сравнимо с проектом полета на Луну".

Это колоссальное капиталовложение. Проект NT как переносимой OC был одним из главных средств захвата рынков,
на момент начала работ (1988, а до этого были VMS и исследовательский проект (Prism если не ошибаюсь) Катлера в Digital) было совсем не ясно, какая аппаратная платформа будет доминировать в 90-е.
Re[12]: Применим ли Си++ в серьезном коде?
От: Maxim S. Shatskih Россия  
Дата: 12.06.04 13:21
Оценка: -2
>незвоможно (да и библиотеки порой всретчаются у которых нет исходников). Так что
>приходится верить. Именно поэтому придумали такую вещь как инкапсуляция.

Инкапсуляция — это другое. Это отделение интерфейса от имплементации, и запрет лазить к деталям имплементации в обход оговоренного интерфейса.

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

>Слова о вреде полиморфизма слышу впервые.


А где они?

>операторов? Да не так часто их и переопределяет. Слава богу те идиоты просто не

>справятся с перегрузкой.

Нет. Справятся, и справятся так, что потом умный не разберется в их бреде.

Любой дурак может юзать любую фичу. А понимать, нужна ли она — ума требует.

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

VD>МС сделала верный выбор спроектировав Шарп снуля.


Точнее, скопировав с Джавы в значительной степени.

>Очень многих проблем они избежали.

>И я совсем не понимаю почему не забыть об откровенно пережившем себя С, забить на С++ и
>пользоваться современным языком избавленным от большинства проблем.

То-то практически все серьезное (т.е. системное) программирование делают на Си.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[8]: Применим ли Си++ в серьезном коде?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.06.04 13:46
Оценка: 26 (4)
Здравствуйте, Дарней, Вы писали:

Д>я бы сказал, очень маленькое. Если взять в качестве примера FCL, то мне даже подумать страшно, сколько там всего функций (точнее, методов). На порядок больше — это точно.


Количество публичных методов:
1.1.4322
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.VisualBasic.Vsa.dll - 132
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft_VsaVb.dll - 52
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\cscompmgd.dll - 52
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.JScript.dll - 5050
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.VisualBasic.dll - 2090
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.VisualC.Dll - 49
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Configuration.Install.dll - 411
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Drawing.Design.dll - 2168
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Runtime.Remoting.dll - 1674
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Runtime.Serialization.Formatters.Soap.dll - 297
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Security.dll - 1005
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Management.dll - 2362
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Accessibility.dll - 22
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\CustomMarshalers.dll - 305
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\IEHost.dll - 66
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\IIEHost.dll - 12
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\ISymWrapper.dll - 178
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\RegCode.dll - 50
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Windows.Forms.dll - 32911
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\IEExecRemote.dll - 11
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.EnterpriseServices.dll - 2217
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Web.RegularExpressions.dll - 570
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\mscorcfg.dll - 15014
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\mscorlib.dll - 17139
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.dll - 9916
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Web.dll - 11639
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Drawing.dll - 4089
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Messaging.dll - 1791
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Data.dll - 7460
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Web.Services.dll - 3190
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.XML.dll - 8762
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Design.dll - 25134
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.DirectoryServices.dll - 662
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.ServiceProcess.dll - 929
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Web.Mobile.dll - 16877
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\System.Data.OracleClient.dll - 1532
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\vjscor.dll - 112
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\VJSharpCodeProvider.DLL - 84
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\vjslib.dll - 27976
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\vjslibcw.dll - 204
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\vjswfc.dll - 41401
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\vjswfccw.dll - 3191
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\vjswfchtml.dll - 24767
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\VJSWfcBrowserStubLib.dll - 6
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\envdte.dll - 3812
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\office.dll - 3143
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.VisualBasic.Compatibility.dll - 3798
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.VisualBasic.Compatibility.Data.dll - 1224
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.Vsa.Vb.CodeDOMProcessor.dll - 26
C:/WINXP/Microsoft.NET/Framework/v1.1.4322\Microsoft.Vsa.dll - 194
Total - 285756


2.0.40301
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Accessibility.dll - 78
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\AspNetMMCExt.dll - 10940
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\cscompmgd.dll - 52
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\CustomMarshalers.dll - 238
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\IEExecRemote.dll - 14
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\IEHost.dll - 62
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\IIEHost.dll - 12
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\ISymWrapper.dll - 180
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.VisualBasic.Vsa.dll - 132
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.VisualC.Dll - 94
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.Vsa.Vb.CodeDOMProcessor.dll - 30
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\MSBuildEngine.dll - 872
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\MSBuildFramework.dll - 218
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\MSBuildTasks.dll - 4022
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\MSBuildUtilities.dll - 138
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\mscorcfg.dll - 19709
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\mscorlib.dll - 27787
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\sysglobl.dll - 149
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Configuration.Install.dll - 448
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Data.dll - 12895
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Data.ObjectSpaces.dll - 2949
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Data.OracleClient.dll - 2057
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Data.SqlXml.dll - 4882
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Deployment.dll - 6107
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Design.dll - 91152
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.DirectoryServices.dll - 2963
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.DirectoryServices.Protocols.dll - 1763
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.dll - 20202
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Drawing.Design.dll - 2554
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Drawing.dll - 4689
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.EnterpriseServices.dll - 2402
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Management.dll - 2329
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Messaging.dll - 1864
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Runtime.Remoting.dll - 1982
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Runtime.Serialization.Formatters.Soap.dll - 293
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Security.dll - 2721
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.ServiceProcess.dll - 1040
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Transactions.dll - 1534
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Web.Mobile.dll - 20197
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Web.RegularExpressions.dll - 798
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Web.Services.dll - 3538
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Windows.Forms.dll - 72404
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.JScript.dll - 5315
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.VisualBasic.dll - 3764
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.Vsa.dll - 200
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft_VsaVb.dll - 52
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\System.Web.dll - 44156
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjscor.dll - 120
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\VJSharpCodeProvider.DLL - 83
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjslib.dll - 29189
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjslibcw.dll - 204
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjswfc.dll - 41433
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjswfccw.dll - 3191
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjswfchtml.dll - 24777
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\VJSWfcBrowserStubLib.dll - 6
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\MSBuildVJSharpTasks.dll - 373
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjssupuilib.dll - 34540
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\vjsvwaux.dll - 551
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\MSBuildConversion.dll - 169
C:/WINXP/Microsoft.NET/Framework/v2.0.40301\Microsoft.VisualStudio.OfficeTools.Build.Tasks.dll - 97
Total - 516710


Так что даже 3 порядка не будет сильным преувеличением.
... << RSDN@Home 1.1.4 beta 2 >>
AVK Blog
Re[6]: Применим ли Си++ в серьезном коде?
От: Maxim S. Shatskih Россия  
Дата: 12.06.04 14:24
Оценка: 1 (1) +1 -3 :)
VD>Указание ref обязательно. Оно прекрасно выражает смысл.

Вот это очень хорошая идея.

>Все тоже самое можно и в С с С++, но только на уровне соглашений кодирования.


Сначала придумали глупость под названием references, глупость потому, что это неполноценный дубликат указателей. А неполноценный потому, что [] не работают с ними.

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

Единственное место, где реально нужна reference — это перекрытые операторы, дающие lvalue. operator[], например.

VD>Агащасблин. А про то, что указатель может быть NULL или черти чем ты не забыл? Ссылки

>как раз это устраняют. Так что тут пролема не в наличии фичи, а в плохом синтаксисе.

А какая разница? Утверждение "ссылки из Си++ — это плохо" — верно и в том, и в другом случае.

VD>Тут даже коментировать нечего. Бред да и только. Простраства имен самое разумное

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

Аргументы есть какие-то для такого вывода? В ядре Windows — где только из самого ядра торчит 1100 функций, а еще есть куча подсистем вне ядра типа NDIS — как-то такой проблемы не возникает.

VD>string a = "мыла";

VD>string b = "Маша " + a + " раму." + "Вот " + "такие пироги.";

Единственный случай, где overloading разумен. А, да, комплексные числа еще.

MSS>>Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже

>никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть
>венгерскую нотацию используй
VD>Мля. А если strcat() залудить вызов отправляющий мыло админу о том, что строка
>сконкатинирована? Тоже ведь никто незаметит.

Разница ощущается? Одно дело — библиотечная функция, имя которой все знают. Другое дело, когда в выражении выполняется какая-то работа, и выполняется так, что по синтаксису этого не заметно.

VD>Если приведение семантически грамотно, то никаких проблем не возникает.


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

Из тех же соображений, из каких уменьшают число приборов в кабине истребителя.

VD>Сам то понял что сказал? Причем тут полиморфизм и RTTI?


Люблю я таких людей. Приходится азы объяснять.

Стоит задача. Код, работающий единообразным образом с разными объектами. Обычно есть два паттерна решения этой задачи:
а) полиморфный — сказать "сделай", а инстанс сам разберется, как он это будет делать.
б) явно спросить "а какого типа вот этот инстанс?" (эта возможность и называется RTTI) и потом сделать или switch, или цепочку ifов, для каждого типа свой код.

То, что путь б) плох — очевидно. Хотя бы потому, что появление нового типа объектов его тут же ломает.

RTTI противоречит полиморфизму. Это второй путь решения тех же задач, и путь почти всегда плохой.

То, что в языке не было RTTI, заставляло пионеров (про пионеров отдельная тема — на этом же форуме видел — начинают изучение сокетов... с MFC, потому что это типа круто и объектно. В итоге сокеты у них не работают и шибко умных писать полиморфно. И это было правильно.

Крайне редко действительно нужна RTTI. Например, при вводе-выводе объектов. Скажем, в COM интерфейс IPersist (который и есть RTTI) — только за этим и задуман, как ясно из имени. Придуман как база для наследования IPersistFile, IPersistStream и прочих. В ТурбоВижне в 90ые годы — то же самое примерно было. RTTI, придуманный для ввода-вывода объектов.

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

VD>Что значит "поощрять не-полиморфные стили программирования"?


См. выше.

>дотнете рефлекшон прекрасно вписывается в ОО-концепции,


RTTI вписывается в ОО концепции? Может, это пиарная фигня, которую несут ради маркетинговых соображения, а такие, как ты, верят, потому как не знают, что такое полиморфизм?

VD>Ключевые слова здесь "как часть языка". У него есть идея фикс по которой все что

>можно нужно сделать независимой библиотекой.

Правильно совершенно. Чем меньше автосгенеренного компилятором кода — тем лучше. Он принципиально закрыт и не изменяем. С библиотечными фичами не так — не нравится, сделай свою, делов-то.

VD>Можно ссылки на то откуда ты взял "во-первых и во-вторых"?


Страуструп/Эллис Annotated C++ Reference Manual 90го года. Длииинный текст курсивом, почему в языке нет RTTI.

MSS>>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо —

>что бывает редко — чем плох DECLARE_DYNAMIC из MFC?
VD>Самому то не смешно?

Нет. Макрос лучше, чем вшитый в компилятор код. Потому как это не черный ящик.

VD>Ну, "откастомайзи" ради хохмы чтобы получить информацию сравнимую с дотнетной.


А зачем она нужна?

При действительно ОО проектировании просто не нужна эта информация, разве что для debug traces Си++, помимо всего прочего, еще и не совсем ОО.

VD>Пока, что ты назвал одну фичу которую нужно дорабатывать.


Я назвал фичу, которая принципиально не нужна.

VD>Мля. dynamic_cast — единственное небезопасное приведение типов в С++. Я балдею с этой

>агитации за каменный век.

А я балдею с людей, которых не тянет блевать просто от синтаксиса dynamic_cast<имя>(...).

Чем хуже C-style cast в виде (тип)имя? Тем, что меньше визуального шума?

Преимущества этих Си++ наворотов возникают только при использовании множественного наследования и RTTI. И то, и другое — маразм. Вон Джава прекрасно обходится без множественного наследования — в extends можно перечислить только один класс.

VD>Дурь — это конечно большая проблема. Только не программистов, а человечества в общем.

>Адни из них как раз борба с ОО без всяких оснований.

Да борьба-то тут скорее с маразмами конкретного языка, чем с ОО. Чем полиморфизм-то плох?

VD>Низнаю что за задача "чтение SMART-данных".


Техническая безграмотность — это плохо.

>Но открывть файлы в конструкторе, а закрывать в деструкторе совершенно нормально.


Бред. Обработать ошибку нечем, кроме перегруженного до жути механизма exceptions.

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

MSS>>Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих

>маньяков. Даже такая шиза, как юниксные condvar.
VD>И какое это имеет отношение к ОО и языку? Или маньяков нет только у CRT?

Отношение очень простое. Меньше фич — меньше руки чешутся их поюзать, где надо и где не надо.

VD>Ага. Например маньяком С.


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

Писать класс как обертку вокруг Win32 event... во это я понимаю! титаны мысли такое делают!

VD>С каких это пор простой код было сложно писать?


С тех пор, когда стали пропагандировать, что классика устарела, ее на помойку, и все надо делать только на новомодных вещах.

>Вот просто решать сложные задачи — это действительно талант нужен.


Да. Си++ приводит к тому, что в даже простейшие задачи пихают кучу ненужных там наворотов. Лишнего в языке много.

>ОО-языки способствуют упрощению.


Да правда что ли? Теперь, кроме того, чтобы думать, как код работает, еще приходится думать — а как поле объявить — protected или private?

Претензии к ОО в основном идут к наследованию, которое действительно делает из простых задач сложные. Уж лучше дублирование кода, чем отстойно спроектированное дерево наследования. А спроектировать его правильно — простите, но мало кто может. Тут нужен действительно талант, а не средне-рыночные навыки умника за 1200 долларей.

Традиционно мог Борланд, например. Мог Гослинг. СиШарп делал тот же архитектор, что и борландовские ОО тулы. Потому Микрософт его и зазвал на работу.

А умнику дай такую задачу — при объеме эдак в 10 классов на реальном проекте (когда поступают реальные требования рынка, и их надо выполнять) у него все поползет.

Как расползаются деревья наследования — надо рассказывать? Страуструп был совершенно прав — хаки и патчи, сделанные по требованиям рынка (заказчика или своего руководства и маркетинга) — все постепенно ползут к корню дерева, объем кода в корне увеличивается, а в потомках — уменьшается. До тех пор, пока наследование не начинает выглядеть маразмом.

Претензии же к конкретно Си++, в отличие от ОО вообще — как правило к overloading и к RTTI, которая потянула за собой эти бредовые typecasts. К тому, что, строго говоря, к ОО не имеет отношения.

>придуманное тобой слово. И придумано оно исключительно чтобы повоспевать С. На С писать

>непонятный и плохочитаемый код ни чуть не сложнее чем на С++.

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

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

>эмулировать ОО-подход на С.

Таблицы указателей на функции? Ничего ужасного уж особо в этом нет. В юниксе файловые системы на них основаны. И ничего. ОС пережила уже 30 лет, и до сих пор считается хорошей.

VD>Ага. И нопэд куда лучше чем разные там студии.


Конечно. Сколько нужно сделать дебильных тычков мышью, чтобы развернуть дерево в ClassView?

Или взять список пропертей из VB или Дельфи. Задача — посадить в форму 2 контрола, у которых одинаковые списки пропертей, и оба одинаково отличаются от дефолтного.

Сколько надо мышью пощелкать для этого? А на каждый щелчок надо еще прицелится, еще иногда надо список проскроллировать, да еще надо весь этот список (позиций 20) в кратковременной памяти удержать.

В VB спасает то, что можно взять FRM файл, открыть текстовым редактором и руками через copy/paste отредактировать. В Дельфи — не знаю.

Единственная ценность Студии — хороший текстовый редактор и визарды. Остальное все от лукавого.

"Программирование без написания кода" путем заполнения форм и проперти-шитов — отстой. Отстойность становится очевидной, как только нужно два или три похожих объекта сделать — придется два или три раза заполнять этот шит одинаковым образом. Задача обезьянья, и легко сделать просто глазную ошибку. А для начинающих да. Типа круто. Типа пологая learning curve.

VD>А можно узнать название компилятора который ты испльзовал в 93-ем?


Borland C++ 3.1 + OWL.

VD>Из С++ действительно можно было бы викинуть кучу бреда. Но пришлось бы добавить и

>кучу всего очень нужного.

А что мешает библиотеки понаписать, которые нужны?

>Тогда бы он возможно и для ГУИ подошел. А в современном виде использовать его для ГУИ —

>это мозахизм.

Что не мазохизм? ПаэурБилдер? VB?

>приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот

>же Борланд 3.1.
VD>Да уж зрелее не бывает.

Хороший инструмент был. Пригодный для разработки достаточно серьезного софта.

Хотя, Вижуал Си, конечно, всем был лучше практически но он позже появился.

VD>То-то Девпартнерс напрягается.


То-то они так широко известны то-то у них сайт http://www.devpartners.com такой хороший... видать, успешная компания

VD>Да и написанием драйверов и ОС занимаются еденицы.


Скажем точнее — занимаются лучшие.

А "мейнстрим" твой — тут вопросы про сокеты задает. Причем с сокетами у чувака плохо получается (хотя что может быть проще Berkeley API? даже printf сложнее) — а вот Си++ он уже "типа выучил" и завернул Win32 эвент в Си++ный класс типа объектно оно

А вот о том, что от эвента нечего наследовать, что примитивы синхронизации уже полиморфны и уже инкапсулированы — человек забыл.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[6]: Применим ли Си++ в серьезном коде?
От: Maxim S. Shatskih Россия  
Дата: 12.06.04 14:26
Оценка:
>the development language debate from Assembly versus C to C versus C++", а в DDK уже
>сравнительно давно встречаются примеры кода, написанного на С++ (см.
>?src\wdm\audio\msvad\savedata.*).

Только PortCls и то, что с ним завязано. И — заметим — какое маленькое подмножество Си++ там использовано.

Кстати, можно вспомнить, что говорил Питер Вискарола насчет Си++ в ядре Кажется, OSR достаточно уважаемая команда.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[5]: Применим ли Си++ в серьезном коде?
От: Maxim S. Shatskih Россия  
Дата: 12.06.04 14:30
Оценка:
B>Вы неверно истолковали мой ответ. Ненавистник, он же новичок в С++, тут только один —
>это автор всего этого безобразия, Maxim.

Ага, новичок. С 93го года на этом языке работаю.

Более того. Для UI я им и по сей день пользуюсь, естественно.

B> Э, какой горячий джигит ,).

B> Кроме x89 архитектуры процессоров есть ещё десятки других платформ, иногда очень
>экзотических. И для этих платформ нет С++ компилятора, а есть только С.

Учите матчасть. gcc портирован на такую экзотику, что вряд ли бывала в России. И для экзотических платформ в наше время — портируют gcc, а не пишут свой компилятор.

>То есть это вопрос переносимости, который очень актуален для некоторых промышенных

>отраслей.

Бред. См. выше.

B> А лет через 10-20 и С++ тоже могут на свалку викинуть, как когда то перфокарты.


То-то UNIX 30 лет живет без существенных изменений Есть такое понятие — классика.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[6]: Применим ли Си++ в серьезном коде?
От: Maxim S. Shatskih Россия  
Дата: 12.06.04 14:33
Оценка: -1
О>Ну да, это я погорячился, прочитав предыдущие сообщения. Компилятор С++ вообще сложная
>вещь, не все ОС могут себе позволить.

Да-да-да. gcc не везде портирован

>проходит так: сначала текст программы на ОНИКСе преобразуется


Из каких соображений придумывали ОНИКС? Есть ли там какая-то идея, вокруг которой язык придумывали? Или он придуман ради удовлетворения тщеславия кого-то шибко умного?

О>Не, не будет такого лет через 10-20 Легче создать программу, которая делает

>работу за программиста (хотя это ещё вопрос), и, я думаю, это время не за горами.

10-15 лет назад говорили то же самое. Воз и ныне там.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[9]: Применим ли Си++ в серьезном коде?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.06.04 14:33
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А что такое "жлабэйсик"?


Жлабэйсик жла-бэйсик и есть. Ну, можно еще визуал-басяк.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Применим ли Си++ в серьезном коде?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.06.04 14:33
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Longhorn?


Ты про Каиру читал? Лет хх назад про нее такое заливали. Мол перва ОО-ОС.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Применим ли Си++ в серьезном коде?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.06.04 14:33
Оценка:
Здравствуйте, vstrogov, Вы писали:

VD>>Только вот тут язык роли не играет. У МС есть компиляторы С++ для всех поддерживаемых (в том числе и раньше) платформ.


V>Использование C как максимально распространенного и стандартизированного (на всех теоретически возможных платформах) было заложено в требования проекта NT.


Не забывай, что это было почти 15 лет назад. Тогда у МС вообще небыло своего С++ компилятора, а С++ был еще в зародыше.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Применим ли Си++ в серьезном коде?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.06.04 14:33
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>к примеру, "ленивые вычисления" были бы весьма полезны


Это импиративный язык. Как напишеш так и будет. Вот если бы в язык были введены возможности функционального языка, то тогда они были бы очень полазны.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.