теперь предположите, что у меня в функции foo не стоит using std::swap;
полезете глобальное пространство зачищать?
B>Если же предположить, что должна вызываться функция, переопределенная для типа T — то точно так же. Просто эта функция будет переопределена вот так:
B>
NB>теперь предположите, что у меня в функции foo не стоит using std::swap; NB>полезете глобальное пространство зачищать?
Так оно и так только глобальное.
B>>Если же предположить, что должна вызываться функция, переопределенная для типа T — то точно так же. Просто эта функция будет переопределена вот так:
B>>
Здравствуйте, boomer, Вы писали:
B>Так оно и так только глобальное.
есть две функции
namespace a { struct test {}; }
void foo(T x, T y)
{
using namespace std::swap;
swap(x, y);
}
foo(a::test{}, a::test{});
namespace b { struct test {}; void swap(T, T); }
void bar (T x, T y)
{
swap(x, y);
}
bar(b::test{}, b::test{});
какие определения функции swap у тебя будут в глобальном пространстве имен, чтобы получить похожее поведение?
B>Потому что это не "наша" функция, а переопределение глобальной.
нету никаких "глобальных" есть функции из разных равноправных библиотек.
B>Тогда так:
B>[ccode] B>void swap(company_project_type& x, company_project_type& y) B>{ B> company_project_swap(x, y); B>} B>[/code]
Здравствуйте, Kluev, Вы писали:
K>Именно так господа. В с++ пространства имен не более чем синтаксический сахар без которого прекрасно можно жить и многие так и делают.
Синтаксический сахар очень полезен для мозга: позволяет не заблудиться в дебрях.
K>For example, std::vector wasn't guaranteed to be contiguous, so passing an array to a C library like DirectX could potentially involve creating a temporary copy of it.
По хорошему, вектор не должен быть единым куском, но вот из-за сишников, которые только линейно думать умеют, таки решили сделать vector неотличимым от буфера. И как раз из-за этого приходилось писать свои велосипеды.
S>>* что размеры и индексы могут быть представлены только знаковыми целыми и никак иначе; K>Именно так! Потенциальные грабли нужно устранять, даже ценой двухкратного сокращения диапазона индексов. С++ же спроектирован в погоне за ветряными мельницами, чтобы каждая написанная строка кода давалась программисту кровью и потом. Чтобы вместо того чтобы просто писать работающий код, программист обдумывал бы каждый оператор, не будет ли там смешанной арифметики, переполнения и т.д и т.п.
Здравствуйте, Kluev, Вы писали:
K>С знаковыми индексами не нужно думать куда что перенести, не нужно думать при чтении кода, не нужно постоянного микроменеджмента при написание простейших вещей.
Это не так. Со знаковыми индексами только и думаешь, как не выйти за пределы, ибо то, что за пределами — вообще не известно (было).
Здравствуйте, T4r4sB, Вы писали:
BFE>>По хорошему, вектор не должен быть единым куском, TB>Если он не будет куском, то граблей будет дохрена
Это какие? А то ведь на одной из предыдущих работ был вектор написанный поверх листа кусков памяти — за счёт этого был самый быстрый продукт на рынке.
BFE>>Переполнение знаковых индексов — это ещё хуже. TB>Часто массивы на 2 лярда создаёшь?
Здравствуйте, B0FEE664, Вы писали:
BFE>Это какие? А то ведь на одной из предыдущих работ был вектор написанный поверх листа кусков памяти — за счёт этого был самый быстрый продукт на рынке.
Часто реаллоцируешь?
Я вот два раза в день, не чаще.
BFE>>>Переполнение знаковых индексов — это ещё хуже. TB>>Часто массивы на 2 лярда создаёшь?
BFE>signed char — не signed?
Чарами индексируешься?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
BFE>>signed char — не signed? TB>Чарами индексируешься?
Если нужно, то — да. А вы как индексы храните? Как 64-х битный указатель?
Здравствуйте, T4r4sB, Вы писали:
BFE>>Если нужно, то — да. TB>Зачем?
Память экономлю.
BFE>>А вы как индексы храните? TB>i32
std::int32_t ?
TB>один раз только не хватило, обошёл
А приложения у вас 32-х битные?
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, boomer, Вы писали:
B>>Так оно и так только глобальное.
NB>есть две функции NB>
NB>namespace a { struct test {}; }
NB>void foo(T x, T y)
NB>{
NB> using namespace std::swap;
NB> swap(x, y);
NB>}
NB>foo(a::test{}, a::test{});
NB>namespace b { struct test {}; void swap(T, T); }
NB>void bar (T x, T y)
NB>{
NB> swap(x, y);
NB>}
NB>bar(b::test{}, b::test{});
NB>
NB>какие определения функции swap у тебя будут в глобальном пространстве имен, чтобы получить похожее поведение?
Ну получили вы подобное поведение. И что у вас на выходе? Лабиринт из костылей. С введением семантики перемещения такие пируэты вокруг функции свап болше не нужны. Но видимо Ватсон без трубки уже не может.
Здравствуйте, B0FEE664, Вы писали:
BFE>По хорошему, вектор не должен быть единым куском, но вот из-за сишников, которые только линейно думать умеют, таки решили сделать vector неотличимым от буфера. И как раз из-за этого приходилось писать свои велосипеды.
Для этого комитету с++ нужно было действовать более конкренто, а не занимать позицию вот вам спецификация, а один там кусок или нет — это детали реализации. Программисту для работы нужен недвусмысленный стандарт без всяких может нет, а может да.
S>>>* что размеры и индексы могут быть представлены только знаковыми целыми и никак иначе; K>>Именно так! Потенциальные грабли нужно устранять, даже ценой двухкратного сокращения диапазона индексов. С++ же спроектирован в погоне за ветряными мельницами, чтобы каждая написанная строка кода давалась программисту кровью и потом. Чтобы вместо того чтобы просто писать работающий код, программист обдумывал бы каждый оператор, не будет ли там смешанной арифметики, переполнения и т.д и т.п.
BFE>Переполнение знаковых индексов — это ещё хуже.
Что значит хуже? В обоих случаях переполнение приведет к ошибочному ходу выполнения программы. Не будете же вы утверждать что при беззнаковом переполнении ошибочное выполнение будет "менее ошибочным".
Но случаев когда переполнение возможно в беззнаковой арифметике однозначно больше.
Здравствуйте, Kluev, Вы писали:
K>Ну получили вы подобное поведение. И что у вас на выходе? Лабиринт из костылей. С введением семантики перемещения такие пируэты вокруг функции свап болше не нужны. Но видимо Ватсон без трубки уже не может.
если кое-кто не в состоянии понять, что это была демонстрация возможностей, то я ничем помочь не могу
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, Kluev, Вы писали:
K>>Ну получили вы подобное поведение. И что у вас на выходе? Лабиринт из костылей. С введением семантики перемещения такие пируэты вокруг функции свап болше не нужны. Но видимо Ватсон без трубки уже не может.
NB>если кое-кто не в состоянии понять, что это была демонстрация возможностей, то я ничем помочь не могу
Демонстрация возможностей чего? Костыле-ориентированного программирования? Спасибо не нужно.
[]
K>Если вам не понятен этот код позвольте я первый кину в вас камень
Практически любой код рано или поздно становиться понятен, вопрос лишь в том, сколько времени над ним медитировать.
И да, основное здесь
В алгоритме, в котором нужно "перебрать все элементы кроме первого и последнего" всегда будет отдельная ветка логики для пустого массива (скорее даже size() < 3), иначе он будет ломаться пусть не на этом конкретном цикле, а где-то еще. А это "всегда будет корректно работать" — тупое заметание мусора под коврик.
Здравствуйте, Patalog, Вы писали:++
P>Здравствуйте, Kluev, Вы писали:
P>[]
K>>Если вам не понятен этот код позвольте я первый кину в вас камень
P>Практически любой код рано или поздно становиться понятен, вопрос лишь в том, сколько времени над ним медитировать.
P>И да, основное здесь P>
P>В алгоритме, в котором нужно "перебрать все элементы кроме первого и последнего" всегда будет отдельная ветка логики для пустого массива (скорее даже size() < 3), иначе он будет ломаться пусть не на этом конкретном цикле, а где-то еще. А это "всегда будет корректно работать" — тупое заметание мусора под коврик.
"Всегда будет" — это громкие, но пустые заявления. Вот к примеру простой жизненный пример: итерация пар соседних элементов в массиве для вычисления длинны полилинии
double len = 0;
for (int i = 0; i < points.size() - 1; i++)
len += distance(point[i], point[i + 1]);
return len;
Один универсальный цикл на все случаи жизни. Никакие дополнительные ветки не нужны. В std::С++ такое естественно работать не будет, std-программист либо наступит на грабли, либо будет вынужден погрузиться в микро-менеджмент и "перебрасывать слагаемые"
for (int i = 1; i < points.size(); i++)
На все это тратятся ненужные временные и умственные ресурсы. Особенно смешно выглядят упражнения некоторых товарищей, которые найдя в языке костыль предназначенный для затыкания дыры, устраивают вокруг него пируэты считая это высшим пилотажем программирования.
