Почему C++ требует «управляемых» модификаций языка?

Question

Почему компилятор не может написать это управляет что должно быть удалось в коде C++ (т.е.чтобы сделать его «совместимым с CLR»)?

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

У меня есть свои мысли о некоторых аспектах и ​​о том, что может быть трудно решить, но хорошее и убедительное объяснение будет очень признательно!

Answer 1

Мне пришлось бы не согласиться с ответами на данный момент.

Основная проблема, которую нужно понять, заключается в том, что компилятор C++ создает код, подходящий для очень простой среды.Даже современный ЦП не знает о виртуальных функциях, черт возьми, даже функции — это с натяжкой.Например, процессор действительно не заботится о том, что код обработки исключений для раскручивания стека находится вне какой-либо функции.Процессор занимается последовательностями инструкций, переходами и возвратами.Функции, конечно, не имеют имен, если речь идет о процессоре.

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

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

Основная проблема заключается в том, что программа на C++ выглядит совершенно неузнаваемой из среды хостинга.JVM не глупая, она знает о функциях, но ожидает, что они будут членами класса.Он не ожидает, что они будут иметь < и > от их имени.Вы можете обойти это, но в конечном итоге вы получите искажение имен.И в отличие от сегодняшнего искажения имен, такое изменение имен предназначено не для компоновщиков C, а для интеллектуальных сред.Таким образом, его механизм отражения может убедиться, что существует класс c__plus__plus с функцией-членом __namespace_std__for_each__arguments_int_pointer_int_pointer_function_address, и это все еще хороший пример.Я не хочу знать, что произойдет, если у тебя есть std::map строк для обращения итераторов.

В целом, наоборот, все гораздо проще.Практически все абстракции других языков можно убрать с помощью C++.Вывоз мусора?Сегодня это уже разрешено в C++, так что вы можете поддержать это даже для void*.

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

Answer 2

Существующий правильный код, т.е.код, написанный в соответствии со стандартом C++, не должен непреднамеренно менять свое поведение.

Answer 3

Ну, C++/CLI в основном предназначен для связующего звена между управляемым и неуправляемым кодом.Таким образом, вам необходимо иметь возможность смешивать управляемые и неуправляемые концепции.Вам необходимо иметь возможность размещать управляемые и неуправляемые объекты в одном и том же коде, чтобы не было возможности обойти отдельные ключевые слова.

Answer 4

Почему вы не можете скомпилировать собственный код C++, предназначенный для CLR?

Да, вы правильно догадались, компромиссов будет слишком много, и это сделает его бесполезным.Я хотел бы назвать только три примера...

1.) Шаблоны:C++ поддерживает их, а CLR — нет (обобщенные шаблоны разные).Таким образом, вы не могли использовать STL, boost и т. д.в вашем коде.

2.) Множественное наследование:поддерживается в C++, а не в CLI.Вы даже не могли использовать стандартный класс iostream и его производные (например, stringstream, fstream), которые наследуются как от istream, так и от ostream.

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

3.) Сбор мусора:Большинство приложений C++ управляют своей памятью вручную (с помощью интеллектуальных указателей и т. д.), CLR имеет автоматическое управление памятью.Таким образом, стиль C++ «новый» и «удалить» будет несовместим с «gcnew», что сделает существующий код C++ бесполезным для этого нового компилятора.

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

Answer 5

Прежде всего, различие между «простым C++» и «управляемым C++» было намеренным, поскольку одной из целей MC++ было обеспечение моста между существующим кодом C++ и CLR.

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

Answer 6

Я думаю, это связано с тем, что добавление функций управляемого кода в C++ сделало бы C++ медленнее, а компилятор - более сложным.Настолько, что C++ потеряет то, для чего он изначально был разработан.Одна из приятных особенностей C++ заключается в том, что с ним приятно работать, он достаточно низкоуровневый и в то же время в некоторой степени переносимый.И, вероятно, именно это планирует Комитет по стандартизации C++.В любом случае, я не думаю, что C++ когда-либо может быть полностью «управляемым», потому что это будет означать, что программам, написанным на C++, для выполнения потребуется виртуальная машина.Если это так, почему бы просто не использовать C++/CLI?

Answer 7

Qt-фреймворк делает почти это.Т.е.у него есть интеллектуальные указатели, которые автоматически обнуляются, когда объект, на который они указывают, уничтожается.И все же это родной C++ после анализа moc (компилятор метаобъектов).

Answer 8

Да, я полагаю, что C++ может стать управляемым.Но тогда .NET должен быть переписан для C++ и не с уклоном в сторону BASIC.Имея множество языков под одной крышей.Некоторые функции должны быть удалены.Был выбор между VB.NET и C++.NET, и был выбран VB.NET.Забавно, что я слышал, что C# более популярен, чем VB.NET (хотя я не использую ни того, ни другого!).

Answer 9

.NET CLR требует, чтобы никакая ссылка на управляемый объект не могла существовать где-либо, о чем не знает среда выполнения, за исключением случаев, когда объект закреплен;Хорошая производительность требует, чтобы объектов закреплялось как можно меньше.Поскольку .NET CLR не может понимать все структуры данных, которые можно использовать в C++, крайне важно, чтобы в таких структурах никогда не сохранялись ссылки на управляемые объекты.Можно было бы заставить «обычный» код C++ взаимодействовать с кодом .NET без каких-либо изменений в языке C++, но единственный способ, которым код C++ мог бы сохранить какую-либо «ссылку» на любые объекты .NET, — это иметь некоторый код на стороне .NET назначает каждому объекту какой-либо дескриптор и сохраняет статическую таблицу объектов, связанных с дескрипторами.Код C++, который хотел манипулировать объектами, затем должен был бы попросить оболочку .NET выполнить некоторую операцию над объектом, идентифицируемым дескриптором.Добавление нового синтаксиса позволяет компилятору определять типы объектов, о которых необходимо знать платформе .NET, и применять к ним необходимые ограничения.

Answer 10

Первое, что нужно учитывать, это все, что делает c++ «быстро» исчезнет.Полная система сбора мусора на C++ практически невозможна.потому что c++ вы можете иметь указатель практически в любом месте кода.Информация о типе выполнения становится дорогостоящей, если не будет непосредственно встроена в систему Langauge.вы можете воспользоваться преимуществами истинной производительности.шаблон исчезнет.настоящие указатели исчезнут.прямой доступ к памяти пропал.

список вещей, которые должны быть соблюдены

1. no direct pointers(pointers will get replace with complex refernces)
2. templates (generics pay for preformance)
3. simple c-style arrays (will get wrapped with array structures)
4. programmer no longer has control of whether data is on the stack or
the heap.
5. garbage collection will be enforced(this will cause the most changes to the syntax)
6. runtime type data will get added extensively to the code.
(larger code size)
7.  inlining will become more difficult for the compiler
(no more inline key word)
8. no more inline assembly.
9. the new langauge by now will become incompatible c code.(unless you go through hoops) 

Answer 11

Согласен с 5hammer!Если я оставил Java и другие управляемые языки, то не зря:это значит иметь ПОЛНЫЙ контроль над компьютером, иметь доступ к памяти, управлять памятью самостоятельно, контролировать, как компьютер будет запускать мой код, интегрироваться с библиотеками C (такими как Lua).Если я потеряю эту гибкость, я просто оставлю C++ и вернусь к C, а если C тоже станет управляемым, я перейду на ассемблер.

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

Основной целью C++ всегда была производительность.Это один из лучших языков для больших игр.А без этого языкового исполнения не было бы многих игр!