Здравствуйте, Tonal-, Вы писали:
T>А это уже входит в противоречие с предкомпилированныим библиотеками. T>Даже если отвлечся от того, что объектники могут получатся из исходников на других языках.
Ну можно, например, писать в объектиники и в общую бащзу, какие-нибудь контрольные суммы. И как-то включать/выключать весь этот механизм на объектники из прагм.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали: T>>Вполне. Pure C или аля-COM и с песней. E>А если я таки хочу С++ интерфейс + исключения, напрмиер?
Тады надо обломаться.
Ну или пачить gcc благо исходники открыты. Только пачить много довольно придётся, особенно в обработке исключений (gcc единственный распостранённый компилер под винду который не поддерживает SEH).
Я делал dll-ки на мингве, которые дёргались из багландёвых приложений.
Интерфейс был — типа облегчённый COM (без подсчёта ссылок и обращения к COM-API) — вполне нормально работает.
Но исключения конечно гасятся на границе, да и в параметрах только ссылки, указатели да инты с чарами.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Здравствуйте, Аноним, Вы писали:
А>>>Не хватает: А>>>1. Делегатов на уровне языка; RO>>В C++09 будут. А>Отлично!
А>>>2. Полной информации о типах в runtime опционально; RO>>Рефлексия?
А>Да.
А>>>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот; RO>>Это противоречило бы принципу «плати только за то, что используешь».
А>В смысле?
А>>>4. Сборщик мусора в принципе не нужен, от него больше проблем чем пользы; RO>>Я считаю, что сборка мусора правильно сделана в C++/CLI с помощью другого типа указателей и ссылок.
А>Нееет, без полной интеграции в язык неудобно. Нужно что бы из unmanaged кода было сделать managed без всякого переписывания старого кода.
По-моему вы очень много хотите. Я думаю, если бы была возможность это реализовать без значительных проблем и !!!Обратной совместимости, это бы было сделано.
Сборщик мусора сам не люблю, но очень удобно создавать объект в функции и не возвращать его по значению.
По поводу библиотек считаю самым весомым аргументом. Для Java стандартная библиотека будет мягко говоря пофункциональнее. А с boost я намучался присоединяя ее.
С++ требует горааааздо больше концентрации чем типобезопасные языки C++/CLI, C#, Java и другие.
Но программировать на C++ нравится, потому что это незабываемое чувство контроля...
M>Александр!
M>Вы не согласны что мне это мешает?
M>Или я допустил какие нить технические ляпы в своем псевдокоде?
Нет, Миша, технический ляп есть в посыле "К сожалению для совместимости все равно оставят возможность писать шаблонные конструкции на типах без формальных требований к типам."
Эту возможность оставляют далеко не только для совместимости.
Многие техники (особенно метопрограммирования) невозможно было бы применять, не будь возможности использовать unconstrained шаблоны.
Пара примеров:
* Is there anything useful that we can express with <class T> that we can’t express with <C T> where C is some concept? Yes, a completely unconstrained type, such as the type T pointed to by T*. Even a void* can’t point to a function.
* Can we eliminate <class T>? In the abstract, maybe. In reality, no. Many template meta-programming techniques seem to fundamentally depend on unconstrained types parameters (see appendix D). Also, there will always be pre-concept C++ code around.
Пример "практического" применения:
Modern C++ Design (Alexandrescu), chapter 1.8, Optional Functionality Through Incomplete Instantiation:
...
Creator prescribes a class template of one type T that exposes a member function Create. Create should
return a pointer to a new object of type T. Optionally, the implementation can define two additional
member functions — T* GetPrototype() and SetPrototype(T*) — having the semantics of getting
and setting a prototype object used for creation. In this case, WidgetManager exposes [to client — Alxndr] the
SwitchPrototype (T* pNewPrototype) member function, which deletes the current prototype and
sets it to the incoming argument.
...
Т.е. политика/стратегия может иметь в интерфейсе совершенно "левые" функции, которыми клиент может (или не может) пользоаться при определенных параметрах шаблона.
Вполне оргичнео было бы разрешить использование unconstrained типов не по дефолту , а наоборот. Это тоже самое что разрешить по дефолту interpret_cast любых типов (int)std::string.
Миша,
M>Вполне оргичнео было бы разрешить использование unconstrained типов не по дефолту , а наоборот.
Не совсем понятно, что ты понимаешь под "разрешить использовать не по дефолту".
Нужно — пишешь template <MySuperPuperConcept Model>, не нужно — пишешь template <class IDoNotNeedConceptHere>. И никакого дефолта
M>за ссылку спасибо.
Здравствуйте, Gluk_Kazan, Вы писали:
GN>>Препроцессоры некоторых ассемблеров могут очень много. Например, реализовать поддержку синтаксиса C, обеспечить строгую типизацию. Только придётся написать довольно много кода — это не смешно, а долго и чревато ошибками.
G_K>Единственный известный мне понт в метапрограммировании — уменьшение ручной работы (и тем самым уменьшение количества ошибок)
Уменьшение ручной работы — понт от любого прораммирования. А в чём понт этого высказывания? Я вообще про то, что можно написать мега-крутую библиотеку макросов на ассемблере, а потом её пользователи будут экономить время... Но на С++ такое делать проще, поскольку это следующая ступень в эволюции (машкод+монитор, ассемблер, макроассемблер, компилятор ассемблера, С) и часть этой мега-библиотеки захардкожено в компилятор, так что экономит время и разработчик.
G_K>Приведите пожалуйста (серьезный) источник, в котором C упоминается в качестве ассемблера
Про паскаль задело, да? Это было к тому, что можно смотреть на язык с противоположной стороны...
Можно бы привести определение "языка ассемблера", а потом выудить из ISO9899 что-нибуть про абстрактную машину, но слегка на демагогию будет похож вывод "ассемблер==транслятор"
а вот K&R отражает суть:
Си имеет дело с теми же объектами, что и большинство компьютеров, а именно с символами, числами и адресами. Они могут обрабатываться арифметическими и логическими операциями, реализованными на реальной машине
G_K>К сожалению я не занимаюсь сферическими хеллоуворлдами
helloworld самый обычный, из любой книжки. Остальной софт структурирован сложнее — может использоваться несколько библиотек, одна поверх другой и т.д, но деление на клиента и библиотеку можно произвести всегда.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
машкод+монитор, ассемблер, макроассемблер, компилятор ассемблера, С
А до компилятора ассемблера был интерпретатор ?
GN>Про паскаль задело, да? Это было к тому, что можно смотреть на язык с противоположной стороны...
Гмм. не уловил, что меня должно было задеть про Паскаль ???
И где у языка противоположная сторона ?
Я правда хочу разобраться Открой мне глаза, может я всегда смотрел на языки не с той стороны ???
GN>а вот K&R отражает суть: GN>
Си имеет дело с теми же объектами, что и большинство компьютеров, а именно с символами, числами и адресами. Они могут обрабатываться арифметическими и логическими операциями, реализованными на реальной машине
Дело конечно, но про ассемблеры то ничего не сказано (особенно кроссплатформенные)
Если есть проблемы с источниками, буду рад услышать ТВОЕ определение ассемблера
А то вдруг мы тут копья ломаем о разном, и ты под ассемблером понимаешь что-то свое, глубоко личное ?
Кстати, определение компилятора ассемблера тоже не помешает
GN>helloworld самый обычный, из любой книжки. Остальной софт структурирован сложнее — может использоваться несколько библиотек, одна поверх другой и т.д, но деление на клиента и библиотеку можно произвести всегда.
Думаю, что ты будешь удивлен сколько библиотек (одна поверх другой) может использовать самый обычный helloworld
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, remark, Вы писали:
R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>>Что Вам мешает в С++?
R>>...
R>На днях один мой знакомый побывал на самом крупном столичном книжном рынке. Там очаровательная блондинка потрясла его известием: "С++ больше нет, теперь вместо него С#"
А мужики-то не знают!!! Пора сворачивать форум, С++ кончился
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
В общем-то язык нужно принимать таким, какой он есть...
Но...
На мой взгляд, С++ мало подходит для коллективной разработки в силу слишком большой свободы...
То, что хорошо для гуру, очень плохо для обычного среднего работника-программиста.
С++ позволят писать в самых различных стилях и парадигмах... Нужно жесткое управление проектом с точки зрения стиля написания, и жестокое самоограничение и самодисциплина самих программистов, чтобы не потерять управление проектом и не утонуть в разнообразии...
Второе — это тянущийся хвост обратной совместимости с С. Это заставляет оставлять в С++ плохо подходящие в ООП конструкции... И опять же дает слишком много свободы программистам.
С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
Либо уж тогда следовать стандарту С и надстраивать с++ при каждом изменении стандарта С.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
Тогда получится совсем другой язык, например тот же D.
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>А до компилятора ассемблера был интерпретатор ?
Почти что был, я же выше перечислял monitor — строчный редактор, вводим по одной команде, пошаговое выполнение... Когда ассемблеры стали 2х проходными и научились вычислять метки, думаю, был серьёзный прорыв Assembly compiler понимает уже и высокоуровневые конструкции (см .IF в MASM, или HLA)
G_K>И где у языка противоположная сторона ? G_K>Я правда хочу разобраться Открой мне глаза, может я всегда смотрел на языки не с той стороны ???
Сторона зависит от предыдущих языков, или их количества. Если это высокоуровневые языки, то C++ будет выглядеть ассемблером (см. подфорум философия). Если низкоуровневые — мощным макроассемблером. А если паскаль — то будут раздражать всякие скобочки
. Совместимость с С — это собствено причина, по которой С++ — промышленный язык... Спор о синтаксисе == о блондинках и брюнетках.
G_K>Дело конечно, но про ассемблеры то ничего не сказано (особенно кроссплатформенные)
Зато сказано про модель памяти, которая соответствует реальному железу.
G_K>Если есть проблемы с источниками, буду рад услышать ТВОЕ определение ассемблера
Определение есть в Википедии:
Ассемблер (от англ. assembler — рабочий-сборщик) — компьютерная программа, компилятор исходного текста программы написанной на языке ассемблера, в программу на машинном коде.
Язык ассемблера — тип языка программирования низкого уровня, представляющий собой формат записи машинных команд, удобный для восприятия человеком.
Формально, язык определяется производителем процессора в даташитах. Но, например, для самой распространённой платформы — x86 — определения попросту нет, что позволило Randall Hyde назвать ассемблером HLA, а мне — С Традиционные мнемоники ничем не лучше того же '=', если не считаться с простотой парсера.
G_K>Думаю, что ты будешь удивлен сколько библиотек (одна поверх другой) может использовать самый обычный helloworld
Тот, что в книжках — одну — C++ Standard Library
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, sergey_shandar, Вы писали:
_>1. Это RTTI (Run Time Type Information). В таком языке как C++ лучще бы смотрелся CTTI (Compile Time Type Information). Т.е. нужно больше информации о типе в compile time, что это за тип, какие у него функции/свойства, как называется, номер (UUID какой нибудь) и т.п. А какой то специфичный RTTI я и сам из этого сделаю.
А как насчёт PTTI (Preprocessing Time Type Information)?
RTTI — скучно. CTTI — интереснее, надмножество RTTI + плюс можем генерировать специализированные алгоритмы и структуры данных. PTTI — ещё интереснее, надмножество CTTI + можем генерировать исходный код.
Здравствуйте, remark, Вы писали:
R>А как насчёт PTTI (Preprocessing Time Type Information)? R>RTTI — скучно. CTTI — интереснее, надмножество RTTI + плюс можем генерировать специализированные алгоритмы и структуры данных. PTTI — ещё интереснее, надмножество CTTI + можем генерировать исходный код.
См макры немерла.
Удобные анализ, трансформация и генерация кода на нескольких стадиях компиляции от почти потока токенов до полностью типизированного дерева.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Лет 8 назад я составил бы список из Х кривостей и недостатков.
Лет 5 назад я составил бы список из Х * Х кривостей и недостатков.
А сегодня согласен с вводом автора этого вопроса — горбатого могила исправит.
Нельзя улучшить С++ дот требуемого уровня не уничтожив при этом обратную совместимость.
Меж тем есть масса более совершенных языков: OCaml, LISP, Scala, C#, Nemerle, Haskell, D... Конечно не все они пригодны для решения задач стоящих перед программистом, но тем не менее из них всегда можно выбрать подходящий.
Так что дело не в том, что чего-то нет. Дело в том, что есть машина по оболваниванию людей и люди которые не хотя или не способны выучить второй язык.
* Язык сложный? Дык в нем море неопределенностей из-за того, что на плохотипизированый С попытались присабачить классы.
* Макросы кривые? Хотите такие же как в Лиспе или Немерле? Дык сами эти языки заточены под обработку списков и алгебраических типов средствами которых код представляется наиболее удобным борзом. Кроме того, без полноценной поддержки функций как значений обрабатывать код будет очень сложно. Так что чтобы были хорошие макросы нужно и язык иметь другой.
* Хотите лямбды? А их очень сложно сделать полноценными без GC.
* Хотите полноценный GC с дефрагментацией? А как же его сделаешь если основа языка это указатели, и даже массивов то полноценных нет? Опять наследие С...
* Хотите рефактринг? Смотрите первый пункт...
* Хотите СТТI? А что вы с ним будете делать если нет полноценных макросов? Опять головоломный и глючный мета-код на шаблонах?
В общем, это замкнутый круг — горбатого могила исправит.
Ну, а теперь самое крамольное. Писать программы (эффективные и даже сложные) можно практически на любом ЯП высокого уровня (не на ассемблере). Современный С++ мало чем отличается от С++ середины 90-ых прошлого века в этом контексте. Если уж вам нужны серьезные отличия, то список куда более отличных языков приведен выше. А если вам пофигу на чем писать, и пофигу ваша производительность, то вам хватит и VC 6 или Zortech. Да, что там Zortech — С хватит. Разница между ними и современным С++ с точки зрения продуктивности программиста все равно не сравнима с разницей между С++ и любым из перечисленных мною выше языков.
Почему же монстры индустрии до сих пор пишут код на С++?
Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор.
Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
Хорошие инструменты нужны отнюдь не мегамонстрам вроде МС. Они нужны мелким стартапам и маленьким но очень интеллектуальным командам. Инструмент сам по себе действительно является фетишем. Он всего лишь может увеличить производительность труда толковых людей. Но хороший инструмент в хороших руках — это убийственный аргумент. Ни как не могу забыть ощущение от BFG 10000 в моих руках когда я бежал по относительно просторному уровню...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
LVV>>С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
FR>Тогда получится совсем другой язык, например тот же D.
Но он тоже будет недотягивать потому что его будут уже сравнивать с другими языками.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, remark, Вы писали:
... VD>Почему же монстры индустрии до сих пор пишут код на С++?
не-не-не. А как же будущее "наше все" — C#? Вы ж, наверное, видели C# 3 с его гипермощным LINQ и прочими мегафичами
VD>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
...зря что ль они на Андерса Хейлсберга раскошелились?
VD>И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор. VD>Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
...и вообще в Висте — уже .NET предустановлен, и WPF для unmanaged кода недоступна.
Здравствуйте, StevenIvanov, Вы писали:
VD>>Почему же монстры индустрии до сих пор пишут код на С++?
SI>не-не-не. А как же будущее "наше все" — C#? Вы ж, наверное, видели C# 3 с его гипермощным LINQ и прочими мегафичами
А какя тут связь?
C# 3.0 используют те кто хочет быстро создавать довольно надежные приложения обработки данных.
А МС использует С++ просто от жиру.
VD>>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
SI>...зря что ль они на Андерса Хейлсберга раскошелились?
Дык, а на чем его команда тот самый C#-компилятор пишет? В прочем, времена похоже меняются и даже МС вроде как собирается переписать компилятор Шарпа на менеджед-языке.
VD>>И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор. VD>>Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
SI>...и вообще в Висте — уже .NET предустановлен, и WPF для unmanaged кода недоступна.
Ага. И сделано на этом дотнете аж одна закладка во вьюере событий.
Но даже МС потихоничку переползает. Вот уже большая часть студии написана на менеджед-языках. Вроде как компилятор все же перепишут. В разном прикладном ПО дотнет появляется. Так что даже мегамонстры понимают, что выбрасывать бабки на ветер глупо. Хотя для МС это все не критично. Бабла там столько, что они и на ассемблере Виндовс написали бы (писали же ДОС и большую часть Винды?).
Заметь при этом о каких-то радикальных изменениях в С++ они даже не заикаются. И это при том, что как раз они то для своего дотнета очень даже нехило С++ доработали. Там тебе и GC, и делегаты, и безопасный режим, и дженерики (не в ущерб шаблонам) и много чего. Вот только использовать его один хрен неудобно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, StevenIvanov, Вы писали:
VD>>>...
не, дело очевидно не только в деньгах. Сопровождение makes sense
Представь стоимость переписывания всего объема кода, который надо было бы еще и перетестировать (да еще и параллельно добавив-выкинув пару сотен фич).
Недавно вычитал в умной книжке по си шарпу, что что стоимость написания с нуля крупного современного программного продукта (а windows, msoffice, photoshop там какой нибудь — ну просто мегакрупные) сравнима со стоимостью постройки небоскреба.
Да и еще. Мне кажется, что в этой ветке многие не читали (или уже забыли) Брукса:
Я считаю, что сложность создания программного обеспечения заключается в задании технических требований, проектировании и проверке этой концептуальной конструкции, а не в затратах, связанных с ее представлением и проверкой точности представления. Конечно, мы делаем синтаксические ошибки, но в большинстве систем они несущественны в сравнении с концептуальными ошибками.
