Опытным программистам С++

@Tenarius · Регистрация: 04.12.2016

Author24 — интернет-сервис помощи студентам

Здравствуйте, я начал изучать С++. Есть определенный план обучения. Например: сначала изучить синтаксис, принцип ООП, контейнеры STL, стандарты С++11/C++14. Вопрос звучит так: что можно еще добавить в список для изучения? Я еще не определился в какой сфере хочу использовать язык, что нужно знать вообще не привязанная к определенной области?

@Renji · 28.01.2018, 10:19

Сообщение от Fulcrum_013

Кстати так о птичках весь ранж чекинг нужен только для того чтобы отловить ошибки вычисления индексации в дебаге.

В дебаге можно сделать итераторы хранящие ссылку и на элемент, и на его контейнер. После чего прямо в эти итераторы и пихать проверку на "это итераторы от разных контейнеров". Хотя да, если в релизе оставить эти ранж-чеки, большого вреда не будет. Там работа с динамической памятью куда больше съест.

Сообщение от Fulcrum_013

фигушки оно в stl буде. копирование с вектора в список и из списка в вектор несовместимы и фиг они это разрулят без отой порнографии под названием algorithm пока ООП не освоят.

С чего им вдруг быть несовместимыми? Другой вопрос что они даже splice для map никак не сделают.

C++

struct AdavncedVector:std::vector<int>
{
    template<typename T>
    void insert_back(T&src,std::size_t start,std::size_t finish){
        insert(end(),std::next(src.begin(),start),std::next(src.begin(),finish));
    }
};
 
int main()
{
    AdavncedVector vector;
    std::list<int> list={1,2,3,4,5};
    vector.insert_back(list,1,3);
    for(auto&value:vector)
        std::cout<<value<<std::endl;
    return 0;
}

@Fulcrum_013 · 28.01.2018, 10:31

Сообщение от Renji

С чего им вдруг быть несовместимыми? Другой вопрос что они даже splice для map никак не сделают.

Потеря эффективности причем очень крутая для вектора.Вектор в вектор иногда можно копировать через memmove а то и memcpy а со списком это исключено. При этом пользовать вектор для чего то большего чем массивы фундаментальных типов или простеньких структур ну в общем себе дороже в плане гемора/количества кода а как результат и надежности.

Добавлено через 4 минуты

Сообщение от Renji

После чего прямо в эти итераторы и пихать проверку на "это итераторы от разных контейнеров"

Экскепшин вылетевший в продакшине и сталь все равно польется на голову горе-разраба. Чтобы это исключить пихать итераторы в специальный класс диапазона должен исключительно сам контейнер вместе с ссылкой на себя любимого.

Croessmah · 28.01.2018, 10:34

Renji,

Другой вопрос что они даже splice для map никак не сделают.

http://en.cppreference.com/w/c... ap/extract
http://en.cppreference.com/w/c... /map/merge

@Renji · 28.01.2018, 10:39

Сообщение от Fulcrum_013

Потеря эффективности причем очень крутая для вектора.Вектор в вектор иногда можно копировать через memmove а то и memcpy а со списком это исключено.

Никакой потери эффективности.
1) Для вектор в вектор одна версия insert, для все остальное в вектор - другая.
2) Алгоритм копирования вектор в вектор зависит от значения std::is_trivially_copyable<value_type>::value. Если true - гоняем memcpy.

Сообщение от Croessmah

http://en.cppreference.com/w/cpp/container/map/extract
http://en.cppreference.com/w/c... /map/merge

Хм, в 17 стандарте сделали наконец. Не знал, спасибо.

@Fulcrum_013 · 28.01.2018, 10:52

Сообщение от Renji

Для вектор в вектор одна версия insert, для все остальное в вектор - другая.

Ну и т.д. Возникает вопрос - и на кой тогда нужно было эту порнографию с algorithm городить если все равно придется писать разные версии для каждого случая? Cделали бы методами/операторами все было бы гораздо безопаснее проще и читабельнее и рэнджи и степы реверсы все остальное, в том числе и код самих контейнеров на порядок компактней. НО разрабы STL ООП не осилили.

Сообщение от Renji

Алгоритм копирования вектор в вектор зависит от значения std::is_trivially_copyable<value_type>::value. Если true - гоняем memcpy.

Это пока они в оперативе живут. Когда они могут и в оперативе и в GPU жить там гораздо веселее набор кейсов. STL вектору это правда не грозит. Там аллокаторами не отделаешься.

@Renji · 28.01.2018, 10:58

Сообщение от Fulcrum_013

Ну и т.д. Возникает вопрос - и на кой тогда нужно было эту порнографию с algorithm городить если все равно придется писать разные версии для каждого случая?

Наверно, потому что дядька в Киеве. Какое отношение <algorithm> имеет к вставке в вектора? Там лежит std::lower_bound, который может вообще к сишным массивам применяться.

А писать разные версии insert придется разработчикам вектора. Для пользователя же вектора все это абсолютно прозрачно, из-за особой магии "перегрузка". Чай не Си, где для каждой новой версии функции, нужно новое имя сочинять.

@Fulcrum_013 · 28.01.2018, 11:10

Сообщение от Renji

Какое отношение <algorithm> имеет к вставке в вектора?

Имеет к копированию удалению поиску и т.д. При чем эта штука еще и кривая шо гипоциклоида. Неужели так трудно было сделать чтобы тот же remove_if последний элемент тоже обрабатывал?

Сообщение от Renji

Для пользователя же вектора все это абсолютно прозрачно,

При этом в коде который эту порнографию пользует за оными перегруженными вызовами алгоритма не видно. слишком дофига ненужных имен одного и того же контейнера и слов begin end и фактически арифметики указателей если индексы пользуются. Попробуйте как так для прикола средствами stl к примеру матрицу транспонировать или пройтись по ее главной или побочной диагонали.

@Renji · 28.01.2018, 11:18

Сообщение от Fulcrum_013

Неужели так трудно было сделать чтобы тот же remove_if последний элемент тоже обрабатывал?

У меня обрабатывает.

C++

    int array[]={1,2,3,4};
    int*end=std::remove_if(array,array+4,[](int value){return value&1;});
    for(int*pos=array;pos<end;++pos)
        std::cout<<*pos<<std::endl;

Выдает 2 4.

Сообщение от Fulcrum_013

Попробуйте как так для прикола средствами stl к примеру матрицу транспонировать или пройтись по ее главной или побочной диагонали.

Средства STL не поддерживают двумерных массивов. Эрзац "вектор векторов" в расчет не берем.

@Fulcrum_013 · 28.01.2018, 18:32

Сообщение от Renji

Средства STL не поддерживают двумерных массивов. Эрзац "вектор векторов" в расчет не берем.

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

Сообщение от Renji

У меня обрабатывает.

Это unsafe в квадрате. Во первых потому что индексация заменена фактически арифметикой указателей а в главных потому что за всей этой мышиной возней алгоритм теряется.
Во всех годных для промышленного применения библиотеках это делается вот так:

C++

Container.Remove(Needle); // первое вхождение
Container.RemoveAll(Needle); // все вхождения
Container.Remove([](type value){return // сравнение}); // первое вхождение
Container.RemoveAll([](type value){return // сравнение}); // первое вхождение

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

@Renji · 28.01.2018, 20:41

Сообщение от Fulcrum_013

Container.Remove(Needle)

Вы как собираетесь прикрутить это ".Remove" к сишному массиву, с которым removeIf также работает? А в векторах то да, отдельный метод removeIf адаптированный к особенностям вектора не помешал бы.

@Fulcrum_013 · 28.01.2018, 20:45

Сообщение от Renji

Вы как собираетесь прикрутить это ".Remove" к сишному массиву, с которым removeIf также работает? А в векторах то да, отдельный метод removeIf адаптированный к особенностям вектора не помешал бы.

А я и не собираюсь его к нему прикручивать. А если такой анахронизм и понадобится то к нему прикрутится соответствующий навигатор а не черти что.

Новичок · 28.01.2018, 21:03

Сообщение от Fulcrum_013

Начнем со смартпоинтерров. Что будет со смартпоинтером если объект на который он ссылается сделает delete this?

По такой логике и циклы unsafe. Вот пишу я такой код.

C++

1
2
3

int main() {
   while (1);
}

Кто виноват? Конечно же С++! Ну или компилятор! Да кто угодно, кроме меня!

@Fulcrum_013 · 28.01.2018, 21:10

Сообщение от Новичок

Да кто угодно, кроме меня!

Если смартпоинтеры библиотеки не поддерживают самоудаление или стороннее принудительное удаление объектов то это просто негодная для подавляющего большинства промышленных задач библиотека. Если архитектура библиотека позволяет накосячить (к примеру по опечатке) там где другие библиотеки так накосячить не дадут - то это унсафе библиотека непригодная для промышленного применения. Если пользование библиотеки заставляет писать код затрудняющий восприятие алгоритма - о это опять же унсафе библиотека не годная для промышленного применения. А вообще откройте исходники STL. Малочитабельный говнокод который унсафе по определению.

Новичок · 28.01.2018, 21:11

Сообщение от Fulcrum_013

Croessmah,
Вам не кажется что к примеру вот такой интерфейс будет гораздо читабельнее и безопасней

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

@Renji · 28.01.2018, 21:18

Сообщение от Новичок

В STL конечно нет сильной защиты от дурака, но это сделано для скорости.

Защита от дурака то бог с ней. Но вот конструкции типа vector1.insert(vector1.end(),vector2.begin(),vector2.end()) это действительно форменное издевательство.

Сообщение от Fulcrum_013

Если смартпоинтеры библиотеки не поддерживают самоудаление или стороннее принудительное удаление объектов то это просто негодная для подавляющего большинства промышленных задач библиотека.

Чтоб они это поддерживали, нужно чтобы и самоудаляющийся объект поддерживал смартпоинтеры. А у нас типа универсализм, в смартпоинтер должно пихаться все, а не только потомки гипотетического STLObject.

@Fulcrum_013 · 28.01.2018, 21:19

Сообщение от Новичок

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

Неужели?

C++

1	std::remove_if(a1,s1+4,[](int value){return value&1;}); // запросто - a и s на клавиатуре рядом.

@Renji · 28.01.2018, 21:20

Сообщение от Fulcrum_013

запросто - a и s на клавиатуре рядом.

Вот именно поэтому и надо давать переменным имена более осмысленные чем a1.

@Fulcrum_013 · 28.01.2018, 21:54

Сообщение от Renji

А у нас типа универсализм,

в STL не универсализм а год-обджекты ни пригодные вообще ни к чему.

Сообщение от Renji

в смартпоинтер должно пихаться все, а не только потомки гипотетического STLObject.

если есть make_shared и т.п то никаких проблем чтобы создавать с его помощью потомока аки STLObject так и того что в него пихается вообще нет.
Но это будет реально годобджект.
Проще и надежнее сделать отдельные варианты контейнеров и указатели для хранения именно указателей на смарт-объекты а не пихать shared а тем более weak в вектор и тп

Добавлено через 53 секунды

Сообщение от Renji

Вот именно поэтому и надо давать переменным имена более осмысленные чем a1.

Единичку с двойкой все равно перепутать и не заметиь в каше запросто. Поэтому нужно библиотекам интерфейсы осмысленные делать а не ФП-говноляпством заниматься.

Добавлено через 3 минуты

Сообщение от Новичок

Вас зациклило на одной библиотеке и вы в сторону другой даже смотреть не хотите.

А зачем мне даунгрейдится с моей библиотеки на какой то лисопет криворуких которые базовых принципов ООП и надежности софта не осилили?
Как думаете по какой причине Пентагон послал Степанова подальше с его идеями прикрутить STL к АДА? Я так понимаю по той же причине его и Страуструп послал и как то С++ 15 лет без этого лисапета жили.

Добавлено через 11 минут

Сообщение от Renji

Вот именно поэтому и надо давать переменным имена более осмысленные чем a1.

и тогда моментально возникнет проблема с читабельностю при таком интерфейсе

Добавлено через 11 минут

Сообщение от Croessmah

к примеру от того чтобы забыть вызвать деструктор никто не застрахован...

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

@Undisputed · 28.01.2018, 21:59

От ошибок/опечаток мы люди не застрахованы.
В STL думаю проверки на safe обработку данных не сделаны спецом, что бы не было оверхеда из за проверок.
А там если программисту нужны доп. проверки можно написать обертку на свой лад.
Это более гибкое решение. Если бы например там было много проверок, то с++ угодил бы вам но не угодил бы тем для кого критична даже 1 лишняя инструкция, и таким разработчикам пришлось бы писать свой STL заново.
Что проще, написать простую обертку добавив пару проверок или заново написать свой мап?

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

@Fulcrum_013 · 28.01.2018, 22:06

Сообщение от Undisputed

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

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

Добавлено через 2 минуты

Сообщение от Undisputed

Думаю не нужно рассматривать С++ ка язык который должен всем угодить. Тогда С++ перестанет быть С++'ом

Для ого чтобы С++ остался С++ нужно не забывать что в С++ кроме STL существует еще и С++.
Т.е. прекратить навязывать а тем более называть частью языка кривой лисопет созданный людьми которые не осилили ООП, и заняться стандартизацие средств которые стали насущной необходимостью еже в середине 90-х вместе с апгрейдом мэйнстрим пардигмы с ООП до КОП.

Croessmah Неэпический 18109 / 10696 / 2062 Регистрация: 27.09.2012 Сообщений: 26,933 Записей в блоге: 1
	28.01.2018, 10:34	23
	Renji, Другой вопрос что они даже splice для map никак не сделают. http://en.cppreference.com/w/c... ap/extract http://en.cppreference.com/w/c... /map/merge 1

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 10:52	25
	Сообщение от Renji Для вектор в вектор одна версия insert, для все остальное в вектор - другая. Ну и т.д. Возникает вопрос - и на кой тогда нужно было эту порнографию с algorithm городить если все равно придется писать разные версии для каждого случая? Cделали бы методами/операторами все было бы гораздо безопаснее проще и читабельнее и рэнджи и степы реверсы все остальное, в том числе и код самих контейнеров на порядок компактней. НО разрабы STL ООП не осилили. Сообщение от Renji Алгоритм копирования вектор в вектор зависит от значения std::is_trivially_copyable<value_type>::value. Если true - гоняем memcpy. Это пока они в оперативе живут. Когда они могут и в оперативе и в GPU жить там гораздо веселее набор кейсов. STL вектору это правда не грозит. Там аллокаторами не отделаешься. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	28.01.2018, 10:58	26
	Сообщение от Fulcrum_013 Ну и т.д. Возникает вопрос - и на кой тогда нужно было эту порнографию с algorithm городить если все равно придется писать разные версии для каждого случая? Наверно, потому что дядька в Киеве. Какое отношение <algorithm> имеет к вставке в вектора? Там лежит std::lower_bound, который может вообще к сишным массивам применяться. А писать разные версии insert придется разработчикам вектора. Для пользователя же вектора все это абсолютно прозрачно, из-за особой магии "перегрузка". Чай не Си, где для каждой новой версии функции, нужно новое имя сочинять. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 11:10	27
	Сообщение от Renji Какое отношение <algorithm> имеет к вставке в вектора? Имеет к копированию удалению поиску и т.д. При чем эта штука еще и кривая шо гипоциклоида. Неужели так трудно было сделать чтобы тот же remove_if последний элемент тоже обрабатывал? Сообщение от Renji Для пользователя же вектора все это абсолютно прозрачно, При этом в коде который эту порнографию пользует за оными перегруженными вызовами алгоритма не видно. слишком дофига ненужных имен одного и того же контейнера и слов begin end и фактически арифметики указателей если индексы пользуются. Попробуйте как так для прикола средствами stl к примеру матрицу транспонировать или пройтись по ее главной или побочной диагонали. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	28.01.2018, 20:41	30
	Сообщение от Fulcrum_013 Container.Remove(Needle) Вы как собираетесь прикрутить это ".Remove" к сишному массиву, с которым removeIf также работает? А в векторах то да, отдельный метод removeIf адаптированный к особенностям вектора не помешал бы. 0

@Tenarius 0 / 0 / 0 Регистрация: 04.12.2016 Сообщений: 43
		1
	Опытным программистам С++ 25.01.2018, 16:56. Показов 7778. Ответов 254 Метки нет (Все метки) Здравствуйте, я начал изучать С++. Есть определенный план обучения. Например: сначала изучить синтаксис, принцип ООП, контейнеры STL, стандарты С++11/C++14. Вопрос звучит так: что можно еще добавить в список для изучения? Я еще не определился в какой сфере хочу использовать язык, что нужно знать вообще не привязанная к определенной области? 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 10:31	22
	Сообщение от Renji С чего им вдруг быть несовместимыми? Другой вопрос что они даже splice для map никак не сделают. Потеря эффективности причем очень крутая для вектора.Вектор в вектор иногда можно копировать через memmove а то и memcpy а со списком это исключено. При этом пользовать вектор для чего то большего чем массивы фундаментальных типов или простеньких структур ну в общем себе дороже в плане гемора/количества кода а как результат и надежности. Добавлено через 4 минуты Сообщение от Renji После чего прямо в эти итераторы и пихать проверку на "это итераторы от разных контейнеров" Экскепшин вылетевший в продакшине и сталь все равно польется на голову горе-разраба. Чтобы это исключить пихать итераторы в специальный класс диапазона должен исключительно сам контейнер вместе с ссылкой на себя любимого. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	28.01.2018, 10:39	24
	Сообщение от Fulcrum_013 Потеря эффективности причем очень крутая для вектора.Вектор в вектор иногда можно копировать через memmove а то и memcpy а со списком это исключено. Никакой потери эффективности. 1) Для вектор в вектор одна версия insert, для все остальное в вектор - другая. 2) Алгоритм копирования вектор в вектор зависит от значения std::is_trivially_copyable<value_type>::value. Если true - гоняем memcpy. Сообщение от Croessmah http://en.cppreference.com/w/cpp/container/map/extract http://en.cppreference.com/w/c... /map/merge Хм, в 17 стандарте сделали наконец. Не знал, спасибо. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 20:45	31
	Сообщение от Renji Вы как собираетесь прикрутить это ".Remove" к сишному массиву, с которым removeIf также работает? А в векторах то да, отдельный метод removeIf адаптированный к особенностям вектора не помешал бы. А я и не собираюсь его к нему прикручивать. А если такой анахронизм и понадобится то к нему прикрутится соответствующий навигатор а не черти что. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 21:10	33
	Сообщение от Новичок Да кто угодно, кроме меня! Если смартпоинтеры библиотеки не поддерживают самоудаление или стороннее принудительное удаление объектов то это просто негодная для подавляющего большинства промышленных задач библиотека. Если архитектура библиотека позволяет накосячить (к примеру по опечатке) там где другие библиотеки так накосячить не дадут - то это унсафе библиотека непригодная для промышленного применения. Если пользование библиотеки заставляет писать код затрудняющий восприятие алгоритма - о это опять же унсафе библиотека не годная для промышленного применения. А вообще откройте исходники STL. Малочитабельный говнокод который унсафе по определению. 0

Новичок 1682 / 1095 / 489 Регистрация: 17.07.2012 Сообщений: 5,360
	28.01.2018, 21:11	34
	Сообщение от Fulcrum_013 Croessmah, Вам не кажется что к примеру вот такой интерфейс будет гораздо читабельнее и безопасней Вас зациклило на одной библиотеке и вы в сторону другой даже смотреть не хотите. У меня когда-то была похожая фигня, я не хотел смотреть ни на какие языки программирования кроме Паскаля(ибо его первым изучал). В STL конечно нет сильной защиты от дурака, но это сделано для скорости. Да и вообще нужно очень постараться чтоб например в алгоритм передать итераторы из разных контейнеров. 1

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	28.01.2018, 21:18	35
	Сообщение от Новичок В STL конечно нет сильной защиты от дурака, но это сделано для скорости. Защита от дурака то бог с ней. Но вот конструкции типа vector1.insert(vector1.end(),vector2.begin(),vector2.end()) это действительно форменное издевательство. Сообщение от Fulcrum_013 Если смартпоинтеры библиотеки не поддерживают самоудаление или стороннее принудительное удаление объектов то это просто негодная для подавляющего большинства промышленных задач библиотека. Чтоб они это поддерживали, нужно чтобы и самоудаляющийся объект поддерживал смартпоинтеры. А у нас типа универсализм, в смартпоинтер должно пихаться все, а не только потомки гипотетического STLObject. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	28.01.2018, 21:20	37
	Сообщение от Fulcrum_013 запросто - a и s на клавиатуре рядом. Вот именно поэтому и надо давать переменным имена более осмысленные чем a1. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 21:54	38
	Сообщение от Renji А у нас типа универсализм, в STL не универсализм а год-обджекты ни пригодные вообще ни к чему. Сообщение от Renji в смартпоинтер должно пихаться все, а не только потомки гипотетического STLObject. если есть make_shared и т.п то никаких проблем чтобы создавать с его помощью потомока аки STLObject так и того что в него пихается вообще нет. Но это будет реально годобджект. Проще и надежнее сделать отдельные варианты контейнеров и указатели для хранения именно указателей на смарт-объекты а не пихать shared а тем более weak в вектор и тп Добавлено через 53 секунды Сообщение от Renji Вот именно поэтому и надо давать переменным имена более осмысленные чем a1. Единичку с двойкой все равно перепутать и не заметиь в каше запросто. Поэтому нужно библиотекам интерфейсы осмысленные делать а не ФП-говноляпством заниматься. Добавлено через 3 минуты Сообщение от Новичок Вас зациклило на одной библиотеке и вы в сторону другой даже смотреть не хотите. А зачем мне даунгрейдится с моей библиотеки на какой то лисопет криворуких которые базовых принципов ООП и надежности софта не осилили? Как думаете по какой причине Пентагон послал Степанова подальше с его идеями прикрутить STL к АДА? Я так понимаю по той же причине его и Страуструп послал и как то С++ 15 лет без этого лисапета жили. Добавлено через 11 минут Сообщение от Renji Вот именно поэтому и надо давать переменным имена более осмысленные чем a1. и тогда моментально возникнет проблема с читабельностю при таком интерфейсе Добавлено через 11 минут Сообщение от Croessmah к примеру от того чтобы забыть вызвать деструктор никто не застрахован... Вот для этого в С++ и есть delete который от этого страхует. Не нравится из коробки - ничто не мешает сделать самому. Такой всегда был принцип плюсов. Но как бы он от соблюдения контрактов библиотечных/встроенных средств использующий их код этот принцип не освобождает. Но если искоробочные библотечные средства урезают возможности искоробочных языковых средств- то коммитет языком ошибся. пусть идут яву стандартизировать а не С++ поганить. Лучше бы синтаксическими апгрейдами занялись которые у всех производителей давно есть но у всех по разному - свойствами, RTTI, делегатами и т.д. без чего современная разработка немыслима, а не стандартизацией лаб уровня первого курса. 0

@Undisputed 900 / 477 / 93 Регистрация: 10.06.2014 Сообщений: 2,698
	28.01.2018, 21:59	39
	От ошибок/опечаток мы люди не застрахованы. В STL думаю проверки на safe обработку данных не сделаны спецом, что бы не было оверхеда из за проверок. А там если программисту нужны доп. проверки можно написать обертку на свой лад. Это более гибкое решение. Если бы например там было много проверок, то с++ угодил бы вам но не угодил бы тем для кого критична даже 1 лишняя инструкция, и таким разработчикам пришлось бы писать свой STL заново. Что проще, написать простую обертку добавив пару проверок или заново написать свой мап? в данном случае за вас просто реализовали базовые операции, стараясь как можно меньше самовольничать с целью минимизировать оверхед, а там уже смотрите сами, если надо пишите свои обертки либо вообще обходите стороной STL. Думаю не нужно рассматривать С++ ка язык который должен всем угодить. Тогда С++ перестанет быть С++'ом 1

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	28.01.2018, 22:06	40
	Сообщение от Undisputed Если бы например там было много проверок, то с++ угодил бы вам но не угодил бы тем для кого критична даже 1 лишняя инструкция, и таким разработчикам пришлось бы писать свой STL заново. Что проще, написать простую обертку добавив пару проверок или заново написать свой мап? Дык вопрос что невозможность накосячить обеспечивается более другой архитектурой и интерфйесом исключающим возможности накосячить а не проверками. При этом надежность софта зависит от читабельности кода. Интерфейс STL снижает читабельность соответсвенно ему место в топке Добавлено через 2 минуты Сообщение от Undisputed Думаю не нужно рассматривать С++ ка язык который должен всем угодить. Тогда С++ перестанет быть С++'ом Для ого чтобы С++ остался С++ нужно не забывать что в С++ кроме STL существует еще и С++. Т.е. прекратить навязывать а тем более называть частью языка кривой лисопет созданный людьми которые не осилили ООП, и заняться стандартизацие средств которые стали насущной необходимостью еже в середине 90-х вместе с апгрейдом мэйнстрим пардигмы с ООП до КОП. 0