Потоки C++ по сравнению с потоками .NET?

Question

Есть ли причина, по которой стандартная библиотека все еще использует потоки, которые она делает? Похоже, что потоки .net намного проще в использовании и реализации. Я могу понять, что они сохраняют их из-за соображений совместимости, но почему они не добавили новую реализацию потока больше как .net?

Каковы некоторые плюсы и минусы потоков C++ по сравнению с потоками .NET? Я не могу придумать какие-либо профи для потоков C++:.

Как н.у.к. заявил
«Он говорит о концепции не реализация MS. Заменитель например .NET для Java и вопрос будет означать почти то же самое (как его концепции потоков является аналогично. NET, но в отличие от C++) «

Answer 1

Я не знаю о .Net, но, поскольку вы говорите, что вопрос будет одинаковым для потоков Java, наиболее очевидными для C++-потоков являются то, что они имеют все форматирование, встроенное в СТД :: ИОС. Вы можете вполне обоснованно утверждать, что это ортогонально для бизнеса шунтирующих байтов, и поэтому это должно быть отдельной проблемой. Затем снова C++ отделяет два (см. Streambuf), это просто то, что происходит с call поток - это то, что также делает форматирование, тогда как Java называет простую вещь потоком, а затем программист украшает ее со сканерами или читателями, или еще что-то.

Как обычно, Java предоставляет простой интерфейс, C++ обеспечивает «настраиваемый и чрезвычайно мощный» интерфейс, который является довольно странным. Простота использования - это не единственная проблема стандартного комитета C++.

А почему комитет не предоставил больше Java-подобный альтернативный API, так как Microsoft сделал в .NET, я подозреваю:

• Комитет предпочитает, чтобы третьи стороны, сделать что-то адаптер Работа.
• Комитету нравятся многие аспекты текущего API, например, универсальная перегрузка operator<< и operator>>. Я не уверен, является ли это частью того, что вам не нравится в потоках C++, но это, безусловно, часть того, что делают люди, которые любят их, как и о них.

Во всяком случае, на самом деле не было значительного обновления стандарта C++, так как он был впервые опубликован, поэтому, даже если комитет хотел изменить (что он не AFAIK), он до сих пор будет только в форме проекта, для выпуска, возможно, в этом году, может быть, в следующем году.

Answer 2

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

Это, как хорошо, о потоках .NET? Я парень C++ с ограниченным доступом к .NET. Я согласен с тем, что потоки C++ могут быть неуклюжими в пятнах, но они обычно выполняют свою работу без особых проблем. Что относительно потоков .NET оправдывает значительные изменения в C++?

Answer 3

Хотя оба они придерживаются базовой абстракции, C++ и .NET интерпретируют «поток» в разных смыслах. Имея это в виду, на самом деле нечестно сравнивать NET Stream с C++ *stream, поскольку они предназначены для разных целей: один предназначен для перемещения байтов в хранилище и из него, а другой предназначен для представления данных.Обе структуры действительно имеют аналоги в другой, однако:

• .NET: Stream: *Reader
• C++: streambuf: iostream

Что касается стороны C++, проверить эту цитату из GNU C++ Iostream docs, который говорит это лучше, чем я могу:

istream и ostream классы ar e предназначен для обработки конверсий между объектами в вашей программе и их текстовым представлением.

В отличие от этого базовый класс streambuf предназначен для передачи необработанных байтов между вашей программой и источниками ввода или выходными приемниками.

Я думаю, вы найдете, когда вы сделаете соответствующее сравнение, что все имеет смысл. (Списки участников для Stream против streambuf очень схожи, как TextReader и istream.)

Answer 4

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

Использование потоков C++ в течение многих лет, я больше не использую его в каких-либо новых проектах. Google Coding Guidelines соглашается со мной. В нем говорится: «Использовать потоки только для ведения журнала».