Qraizer
Advanced Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Цитата:| Я считаю что С# - язык, который в будущем вытеснит С++ так как является обобщением нескольких языков |
Скорее не так. Microsoft (в очередной раз) предложила международный стандарт (на этот раз) API. Со своей стороны (и в качестве примера) она реализовала его в виде надстройки над WinAPI под названием .NET Application Framework. Если это дело выгорит, то получится типа "очень классно": можно писать код и не думать, под какую платформу. Просто компилишь, и оно работает. Везде. Подобная стандартизация уже прошла на ура с Plug-n-Play-ем, COM-технология тоже кое-кому понравилась. В общем ИМХО намерения именно такие.
Другое дело, что новый API не функциональный, а объектный - вот это самое то, "чего так долго все ждали". Действительно, сколько можно работать в терминах функций, структур, указателей, когда на дворе уже 21-й век, и все вовсю юзают ООП, в частности, лобают классовые обёртки над этим функциональным API. В лице всяких там MFC, VCL, etc. Так пусть API сразу будет объектный.
Далее. Над C++ всегда довлели два незыблемых закона: совместимость на уровне исходных текстов с plain C и т.н. "нулевая стоимость неиспользования". Если кто не знает, поясню. Это означает, что программист не платит за возможности языка, которые не использует. Например, если он заюзал полиморфизм, он платит за это некоторым снижением производительности за счёт замены прямых вызовов (виртуальных) методов на косвенные и как следствие этого - практической невозможностью их встраивать, которые иначе легко бы встраивались, даже без подсказок inline в прототипах. Кроме того, он платит увеличением размера полиморфных классов и чуть ли не втрое увеличением размера указателей на виртуальные методы. Однако, такие возможности стОят того, и программист, используя их, сознательно идёт на эти жертвы. Если программист использует исключения, то он тоже соглашается с тем, что программа будет работать чуть медленнее (правда, исчезающе мало, по крайнем мере на x86) при обычном исполнении и гораздо сильнее при собственно возникшем исключении, однако сохранение инвариантов, обеспечиваемое деструкторами, каковые гарантировано будут вызваны для всех объектов, которые при этом выходят из области видимости - это стОит того, тем более, что без исключений достижение того же эффекта потребовало бы от программиста значительных усилий, и не факт, что получится эффективнее. Можно продолжать, но суть, думаю, ясна: если я не использую динамический полиморфизм (есть ещё статический), то мои классы никогда не будут увеличены никаким vptr и все методы (кроме как вызываемые через указатели) будут вызываться прямо и при возможности встраиваться; если я не использую в своей программе исключения, то даже этой исчезающе малой потери производительности не будет в принципе. И т.п. Это второе правило, во-первых, позволяет и дальше рассматривать C++ как подходящий для решения задач, для которых традиционно использовались plain C и ассемблер - ведь он остаётся качественно прогнозируемым в плане стоимости тех или иных конструктивных решений, воплощаемых в коде, - во-вторых, препятствует стандартизации (но не внесению в каких-нибудь конкретных реализациях в виде расширения) в язык возможностей, которые невозможно или крайне сложно реализовать в соответствии с принципом нулевой стоимости - например того же сборщика мустора, - в-третьих, заставляет немалое количество пунктов стандарта переводить в разряд "зависящих от реализации" или "неопределённого поведения", т.к. разные платформы могут иметь те или иные особенности - например, если имеется аппаратная поддержка проверки диапазонов и (анти)переполнений при арифметических вычислениях, то реализация такой проверки будет дёшева, в противном случае, такая проверка возможна только программная, и следовательно стандартизировать обязательность такой проверки нельзя.
Микрософт же, с одной стороны имеет чёткое представление, какой она видит .NET, и следовательно способна точно сказать, что такие-то и такие-то возможности C++ не помешали бы, но они никогда в нём не появятся, зато другие его возможности для .NET не нужны или легко заменяются на другие, а в таком виде, как они реализованы в C++ они будут неэффективы для .NET. Вот потому-то она и замутила новый язык, который по её мнению лучше всего отражает потребности .NET.
P.S. Что касается политики Микрософт, это всё моё ИМХО, понятное дело, а отнюдь не официальная точка зрения кого бы то ни было. |
