Здравствуйте, Shmj, Вы писали:
S>Какой вариант лучше: S>Как вы пишите и почему?
Снова вопросы из серии "куда вы кладете бороду — НА одеяло или ПОД одеяло". Такие вопросы обычно прописаны в корпоративных соглашениях о кодировании и никогда никого не парят.
Я ж тебе советовал уже — почитай че-нить по C++, чтоб флудить на профессиональном уровне. Ну что за детский лепет? Ты бы спосил еще, сколко пробелов у вас в отступах.
Здравствуйте, Shmj, Вы писали:
S>А если не будет второго const, то: void fun1(const char *const *test1) ?
Совершенно верно.
Хз, почему. В сишных учебниках так было, во многих опенсорсных проектах....
Здравствуйте, rg45, Вы писали:
R>Я ж тебе советовал уже — почитай че-нить по C++, чтоб флудить на профессиональном уровне. Ну что за детский лепет? Ты бы спосил еще, сколко пробелов у вас в отступах.
Здравствуйте, Shmj, Вы писали:
S>Какой вариант лучше:
Никакой: никаких голых указателей — в цивилизованной программе это просто неприлично.
S>Как вы пишите и почему?
Для константных строк есть std::string_view
Здравствуйте, B0FEE664, Вы писали:
S>>Какой вариант лучше: BFE>Никакой: никаких голых указателей — в цивилизованной программе это просто неприлично.
Ухтыжка. Указатели как концепция в CS есть, а использовать их нельзя. Зря ее лобастые ботаники придумывали, надо отменять. Может, ты этот свой совет как-то сузишь, а? Что-то там про передачу владения, интерфейсы или еще что?
Здравствуйте, andyp, Вы писали:
S>>>Какой вариант лучше: BFE>>Никакой: никаких голых указателей — в цивилизованной программе это просто неприлично. A>Ухтыжка.
Экспрессивная гипербола применена для выражения полной убеждённости.
A>Указатели как концепция в CS есть, а использовать их нельзя.
Можно, но не прилично.
A>Зря ее лобастые ботаники придумывали, надо отменять.
Про отмену я ничего не писал — не придумывайте. Хорошо, когда язык предоставляет все уровни абстракций и все виды парадигм программирования.
A> Может, ты этот свой совет как-то сузишь, а?
Нет. Зачем? В нормальной программе все указатели обёрнуты в классы, которые предоставляют функциональность специфичную для данного вида указателей.
А уж вот такое:
— исправлено: добавил амперсанд.
A>Что-то там про передачу владения, интерфейсы или еще что?
Какие проблемы с передачей владения, интерфейсами или еще что?
Здравствуйте, B0FEE664, Вы писали:
A>>Указатели как концепция в CS есть, а использовать их нельзя. BFE>Можно, но не прилично.
Алгоритмы типа std::partition плачут в сторонке.
A>> Может, ты этот свой совет как-то сузишь, а? BFE>Нет. Зачем? В нормальной программе все указатели обёрнуты в классы, которые предоставляют функциональность специфичную для данного вида указателей.
Даже тут тебе может потребоваться работать с куском массива. Зачем вместо пары итераторов (ну или любого другого range) контейнер и пара итераторов?
A>>Что-то там про передачу владения, интерфейсы или еще что? BFE>Какие проблемы с передачей владения, интерфейсами или еще что?
Обычно советуют не передавать голые указатели при передаче владения.
Здравствуйте, andyp, Вы писали:
A>>>Указатели как концепция в CS есть, а использовать их нельзя. BFE>>Можно, но не прилично. A>Алгоритмы типа std::partition плачут в сторонке.
Что с ними? Кто их обидел?
A>>> Может, ты этот свой совет как-то сузишь, а? BFE>>Нет. Зачем? В нормальной программе все указатели обёрнуты в классы, которые предоставляют функциональность специфичную для данного вида указателей. A>В ТВОЕЙ программе.
Зачем вам указатели без обертки? Чтобы сложнее было другим читать/править код?
A>Даже тут тебе может потребоваться работать с куском массива. Зачем вместо пары итераторов (ну или любого другого range) контейнер и пара итераторов?
Я не против пары итераторов.
A>Обычно советуют не передавать голые указатели при передаче владения.
Я же вообще советую не передавать голые указатели между С++ кодом.
Здравствуйте, B0FEE664, Вы писали:
A>>Алгоритмы типа std::partition плачут в сторонке. BFE>Что с ними? Кто их обидел?
ну так у них два указателя на входе (итератора, если угодно, но суть-то не меняется) Или если указатель переименовать в итератор, то можно?
A>>>> Может, ты этот свой совет как-то сузишь, а? BFE>>>Нет. Зачем? В нормальной программе все указатели обёрнуты в классы, которые предоставляют функциональность специфичную для данного вида указателей. A>>В ТВОЕЙ программе. BFE>Зачем вам указатели без обертки? Чтобы сложнее было другим читать/править код?
При разработке например std::rotate пошли ж на эти сложности
A>>Даже тут тебе может потребоваться работать с куском массива. Зачем вместо пары итераторов (ну или любого другого range) контейнер и пара итераторов? BFE>Я не против пары итераторов.
А пары указателей, а тройки, а итератор + sentinel?
A>>Обычно советуют не передавать голые указатели при передаче владения. BFE>Я же вообще советую не передавать голые указатели между С++ кодом.
Вопрос в семантике обертки. Если она имеет место быть, то ОК, а если это просто пара, то имхо абсолютно пофиг, все равно что два указателя в функцию пихнуть. Но уж пихать ссылку на контейнер — это часто просто сузить область применения своей же функции.
И это, заметь, разговор все равно свелся к интерфейсам. Поэтому в первом своем посте я и предлагал сузить рекомендации до них.