Почему C++ требует, чтобы изменения в языке были «управляемыми»?

Question

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

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

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

Answer 1

Я бы не согласился с ответами до сих пор.

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

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

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

Основная проблема заключается в том, что программа C++ выглядит довольно неузнаваемой из среды размещения. JVM не глупый, он знает о функциях, но он ожидает, что они будут членами класса. Он не ожидает, что у них будут < и > от их имени. Вы можете обойти это, но то, что вы в конечном итоге, в основном, называется mangling. И, в отличие от названий, которые сегодня используются, этот тип манипуляции не предназначен для 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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

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

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 Framework, и применять к ним необходимые ограничения.

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++ всегда была исполнением. Это один из лучших языков для больших игр. И без этих языковых выступлений много игр не существовало бы!