Хорошая идея/плохая идея: я должен переопределить большинство С++?

Ответ 1

Итак, почему бы мне не реализовать меньше общая, но удобная в использовании версия?

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

Честно говоря, ваш выбор прост:

Изучите С++ или не используйте его. Да, С++ обычно используется для графики, но Java также имеет библиотеки OpenGL. Таким образом, С#, Python и практически любой другой язык. Или C. Вам не нужно использовать С++.

Но если вы его используете, изучите его и используйте правильно.

Если вы хотите неизменные строки, создайте свою строку как const.

И независимо от его базовой реализации, STL замечательно прост в использовании.

Ошибки компилятора С++ можно прочитать, но это требует немного практики. Но что более важно, они не являются эксклюзивными для STL-кода. Вы встретите их независимо от того, что вы делаете, и какие библиотеки вы используете. Так что привыкнешь к ним. И если вы все равно привыкаете к ним, вы также можете использовать STL.

Кроме того, несколько других недостатков:

• Никто не поймет ваш код. Если вы зададите вопрос о SO о std::vector или двунаправленных итераторах, все, кто разумно знаком с С++, могут ответить. Если вы спросите abut My:: CustomLinkedList, никто не сможет вам помочь. Что является неудачным, потому что прокат собственных тоже означает, что будет больше ошибок, чтобы обратиться за помощью.
• Вы пытаетесь вылечить симптом, а не причину. Проблема в том, что вы не понимаете С++. STL - всего лишь симптом этого. Избегание STL не волшебным образом улучшит ваш код на С++.
• Ошибки компилятора. Да, они противно читать, но они там. Много работы в STL привели к тому, что в большинстве случаев неправильное использование будет приводить к ошибкам компилятора. В С++ очень легко сделать код, который компилируется, но не работает. Или, похоже, работает. Или работает на моем компьютере, но не таинственно в другом месте. Ваш собственный связанный список почти наверняка перенесет больше ошибок во время выполнения, где они будут показываться не обнаруженными, и будет намного сложнее отслеживать.
• И снова это будет ошибкой. Доверьтесь мне. Я видел чертовски хороших программистов на C++, пишет связанный список на С++, только чтобы обнаружить ошибку после ошибки, в неясных случаях границы. И С++ - это все пограничные случаи. Соответствует ли связанный список безопасностью исключений? Будет ли это гарантировать, что все в согласованном состоянии, если создание нового node (и тем самым вызов конструктора типа объекта) вызывает исключение? Что это не будет утечка памяти, что все соответствующие деструкторы будут вызваны? Будет ли это безопасным по типу? Будет ли это так же результативно? Есть много головных болей, с которыми приходится иметь дело при написании классов контейнеров на С++.
• Вам не хватает одной из самых мощных и гибких библиотек, существующих на любом языке. STL может многое сделать, что было бы болью даже при использовании Java-библиотеки с раздутыми библиотеками. С++ уже достаточно сложно, не нужно выбрасывать несколько преимуществ, которые он предлагает.

Мне не нужны распределители, итераторы и т.д.

Отчисления могут быть безопасно проигнорированы. Вам в значительной степени даже не нужно знать, что они существуют. Итераторы блестящие, хотя, и выяснение их спасет вас от многих головных болей. Существует всего три концепции, которые необходимо понимать для эффективного использования STL:

• Контейнеры: вы уже знаете об этом. векторы, связанные списки, карты, наборы, очереди и т.д.
• Итераторы: абстракции, которые позволяют перемещаться по контейнеру (или подмножествам контейнера или любой другой последовательности значений в памяти, на диске в виде потоков или вычисляться "на лету" ).
• Алгоритмы: Общие алгоритмы, которые работают с любой парой итераторов. У вас есть сортировка, for_each, поиск, копирование и многие другие.

Да, STL мал по сравнению с библиотекой Java, но он сочетает в себе удивительное количество энергии, когда вы объединяете вышеуказанные 3 понятия. Там немного кривая обучения, потому что это необычная библиотека. Но если вы собираетесь потратить больше двух или двух дней на С++, это стоит изучить правильно.

И нет, я не следую вашему формату ответов, потому что я думал, что дать вам подробный ответ будет более полезным.;)

Edit:

Было бы заманчиво сказать, что преимущество вашей собственной игры состоит в том, что вы узнаете больше о языке, и, может быть, даже о том, почему STL является одной из его экономии. Но я действительно не убежден в этом. правда. Это может сработать, но оно может иметь неприятные последствия.

Как я уже говорил, легко написать код на С++, который, похоже, работает. И когда он перестает работать, легко изменить некоторые вещи, такие как порядок объявления переменных, или вставить немного дополнений в класс, чтобы заставить его, похоже, снова работать. Что бы вы узнали из этого? Это научит вас писать лучше С++? Может быть. Но, скорее всего, это просто научит вас, что "С++ сосет". Будет ли он научить вас, как использовать STL? Точно нет. Более полезным подходом может быть использование потрясающей способности StackOverflow в правильном изучении STL.:)

Ответ 2

Недостаток: никто, но вы его будете использовать.

Преимущество:. В процессе его реализации вы узнаете, почему стандартная библиотека - это хорошо.

Ответ 3

Преимущества: есть свой собственный корм. Вы получаете именно то, что делаете.

Недостатки: есть свое собственное питание. Многочисленные люди, более умные, чем 99% из нас, потратили годы на создание STL.

Ответ 4

Я предложил вам узнать, почему:

используя STL, выплевывает непонятный и искаженный компилятор Ошибки

первый

Ответ 5

Я думаю, вы должны это сделать.

Я уверен, что я получу это для flambayed, но вы знаете, что каждый программист на С++ здесь пил слишком много STL coolaid.

STL - отличная библиотека, но из первых рук я знаю, что если вы откажетесь самостоятельно, вы можете:

1) Сделайте это быстрее, чем STL для ваших конкретных случаев использования. 2) Вы напишете библиотеку только с необходимыми интерфейсами. 3) Вы сможете расширить все стандартные материалы. (Я не могу сказать, насколько я хотел, std::string имел метод split())...

Все правы, когда говорят, что это будет большая работа. Это правда.

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

Ответ 6

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

Преимущество: вы, вероятно, многому научитесь!

Ответ 7

Есть что-то, что вы можете сделать в сообщениях об ошибках скрытого компилятора STL. STLFilt поможет упростить их. Из STLFilt Website:

STLFilt упрощает и/или переформатирует долговечная ошибка С++ и предупреждение сообщений с акцентом на связанных с STL диагностики (и для MSVC 6 он полностью устраняет предупреждения C4786 и их детрит). Результат дает много даже самая загадочная диагностика понятным.

Посмотрите здесь и, если вы используете VisualC, также здесь.

Ответ 8

Недостаток: IMHO, перепрофилирование проверенных и проверенных библиотек - это рабита, которая почти гарантирована, чтобы быть больше проблем, чем это стоит.

Ответ 9

Немного моего опыта: Не так давно я реализовал свой собственный векторный класс, потому что мне нужен был хороший контроль над ним.

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

Я также хотел итерации через него, не используя operator [], но приращение указателя, подобного a, с C, поэтому я не вычисляю адрес T [i] на каждой итерации... Я добавил два метода: один вернуть указатель на выделенную память, а другой - вернуть указатель в конец. Чтобы перебрать массив из целого числа, мне пришлось написать что-то вроде этого:

for(int * p = array.pData(); p != array.pEnd(); ++p){
  cout<<*p<<endl; 
}

Затем, когда я начинаю использовать векторы векторов, я выясняю, что, когда это было возможно, можно было бы выделить большой блок памяти вместо вызова много раз. В это время я добавляю распределитель в класс шаблона.

Только тогда я замечаю, что написал совершенно бесполезный клон std::vector < > .

По крайней мере теперь я знаю, почему я использую STL...

Ответ 10

Другой Недостаток:

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

Ответ 11

Неудобство:

Вы вводите зависимость от своей собственной новой библиотеки. Даже если это достаточно, и ваша реализация работает нормально, у вас все еще есть зависимость. И это может сильно укусить вас при обслуживании кода. Все остальные (включая вас, через год или даже месяц) не будут знакомы с вашим уникальным строковым поведением, специальными итераторами и т.д. Большие усилия понадобятся только для того, чтобы адаптироваться к новой среде, прежде чем вы сможете когда-либо начинать рефакторинг/расширение чего-либо. Если вы используете что-то вроде STL, все это уже будут знать, это хорошо понято и задокументировано, и никто не должен будет переучивать вашу обычную среду выброса.

Ответ 12

Возможно, вас заинтересует EASTL, переписанный STL Electronic Arts задокументировал некоторое время назад. Их проектные решения в основном были обусловлены конкретными потребностями/потребностями в многоплатформенном программировании видеоигр. Резюме в связанной статье суммирует его хорошо.

Ответ 13

Недостаток: Вы - университетский курс, вероятно, излагаете это по какой-то причине. Тот факт, что вы достаточно раздражены им (сарказм, не предназначенный), может указывать на то, что вы не получаете парадигму и будете очень полезны, когда у вас есть сдвиг парадигмы.

Ответ 14

Преимущество

Если вы посмотрите в MFC, вы обнаружите, что ваше предложение уже используется в продуктивном коде - и это было так долго. Ни один из классов сбора MFC не использует STL.

Ответ 15

Почему бы вам не взглянуть на существующие библиотеки С++. Когда С++ был не совсем зрелым, люди часто писали свои собственные библиотеки. Посмотрите на Symbian (довольно ужасно), Qt и WxWidgets (если память мне помогает) имеют базовые коллекции и прочее, и, вероятно, есть много других.

Мое мнение состоит в том, что сложность STL обусловлена ​​сложностью языка С++, и мало что можно сделать для улучшения STL (кроме использования более разумного соглашения об именах). Я рекомендую просто переключиться на какой-то другой язык, если вы можете, или просто справиться с ним.

Ответ 16

Недостаток: переопределение всей этой скважины (то есть на высоком уровне качества), безусловно, займет несколько отличных разработчиков за несколько лет.

Ответ 17

В качестве примера, использование STL выплевывается ряды непонятных и искалеченных ошибки компилятора

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

Вы можете создавать контейнеры без шаблонов и хранить все как указатели void или некоторый базовый класс, например. Но вы потеряете проверки типа времени компиляции, а С++ сосет как динамический язык. Не так безопасно это делать, как это было бы, например, в Objective-C, Python или Java. Одна из причин заключается в том, что С++ не имеет корневого класса для всех классов для всей интроспекции для всех объектов и некоторой базовой обработки ошибок во время выполнения. Вместо этого ваше приложение, скорее всего, сработает и сгорит, если вы ошибаетесь в отношении типа, и вам не будут даны какие-либо сведения о том, что пошло не так.

Ответ 18

Каковы опасности, возможные недостатки и возможные преимущества для "переноса моего собственного" для большинства существующих функций на С++?

Можете ли вы позволить себе и, возможно, оправдать количество усилий/времени/денег, потраченных на восстановление изобретателя?

Повторное использование boost или similiar.

Довольно странно, что вы не можете использовать Boost. IIRC, куски вклада поступают от людей, связанных с работой в университетах (думаю, Джакко Джарви). Недостаток использования Boost слишком много, чтобы перечислить здесь.

Не "изобретать колесо"

Недостаток: Пока вы многому научитесь, вы также возвращаетесь к себе, когда думаете о том, каковы ваши реальные цели проекта.

Преимущество: Обслуживание для людей, которые наследуют это, легче.

Ответ 19

STL очень сложный, потому что он должен быть для библиотеки общего назначения.

Причины, по которым STL выглядит так:

• На основе интерпретаторов стандартным алгоритмам требуется только одна реализация для разных типов контейнеров.
• Предназначен для правильного поведения перед Исключениями.
• Предназначен для обеспечения безопасности потоков в многопоточных приложениях.

Во многих приложениях, однако, у вас действительно достаточно со следующим:

• Строковый класс
• таблица хешей для поиска O (1)
• вектор/массив с сортировкой/и двоичным поиском отсортированных коллекций

Если вы знаете, что:

• В ваших классах не возникают исключения при построении или назначении.
• Ваш код является однопоточным.
• Вы не будете использовать более сложные алгоритмы STL.

Тогда вы, вероятно, можете написать свой собственный более быстрый код, который использует меньше памяти и производит более простые ошибки компиляции/времени выполнения.

Некоторые примеры для ускорения/упрощения без STL:

• Строка Copy-on-Write со ссылкой на буфер подсчитанных строк. (Не делайте этого в многопоточной среде, так как вам нужно заблокировать доступ к счетчику ссылок.)
• Используйте хорошую хеш-таблицу вместо std:: set и std:: map.
• Итераторы стиля Java, которые могут передаваться как один объект
• Тип итератора, который не должен знать тип контейнера (для лучшего компиляции времени развязки кода)
• Строковый класс с более полезными функциями
• Конфигурируемые проверки границ в ваших векторных контейнерах. (Так что не [] или .at, но тот же метод с флагом компиляции или времени выполнения для перехода из режима "безопасный" в "быстрый" ).
• Контейнеры, предназначенные для работы с указателями на объекты, которые будут удалять их содержимое.

Ответ 20

Похоже, вы обновили вопрос, так что теперь есть два вопроса:

• Что мне делать, если я думаю, что std:: library слишком сложна для моих нужд?

Создайте свои собственные классы, которые внутренне используют соответствующие функции std:: library, чтобы выполнить "тяжелый подъем" для вас. Таким образом, у вас будет меньше ошибок, и вы все равно придумаете свой собственный интерфейс кодирования.

2. Что делать, если я хочу узнать, как работают структуры данных?

Создайте свой собственный набор классов структуры данных с нуля. Затем попытайтесь понять, почему стандартные лучше.