LINUX.ORG.RU

История изменений

Исправление den73, (текущая версия) :

В любом случае, я ради смеха даже готов не спорить с идеей «после 10 млн можно подумать о целесообразности использования списка».

Вот и всё, что нам следует знать о ненужности списков.

Забудь слово «список». Список - это в коде, а в задаче «последовательность», «стек», «очередь», «контейнер».

я бы согласился на слово «контейнер», но ты игнорируешь то, что в списке у тебя есть произвольное количество условно-бесплатных курсоров. Я привёл тебе пример про машины, чтобы ты это увидел, но ты вместо этого нагородил костылей, чтобы без этого обойтись. В любом варианте твоего решения про машины массив не даёт одновременно идентичность машины и возможность узнать, какая машина предыдущая, а какая следующая.

Если ты хранишь указатель на машину, то тебе нужно её найти в твоём контейнере, если хочешь узнать, за какой машиной она едет. Это займёт время O(число машин), потому что ты не заставишь машины всегда ехать в одном порядке.

Если ты хранишь координаты машины в виде (номер дека, номер машины в деке), то их нужно перестраивать на каждый чих.

Таким образом, если тебе нужно быстро определять предыдущую машину и ассоциировать с машиной ещё какую-то информацию, у тебя исказится архитектура. Возможно, с помощью горы костылей ты и выкрутишься. В багажник ты погрузишь: знак аварийной остановки, дорожные знаки, бензин, погоду, гаишников и всё остальное. Но так твоя машина никуда не уедет.

20 страниц ты уклоняешься от признания этого факта, хотя не только я тебе пытался его объяснить. С его учётом, список и массив нельзя ставить на одну доску. Поэтому их нельзя назвать одним словом «контейнер», если не оговаривать при этом, что это контейнеры с разными API.

Исправление den73, :

В любом случае, я ради смеха даже готов не спорить с идеей «после 10 млн можно подумать о целесообразности использования списка».

Вот и всё, что нам следует знать о ненужности списков.

Забудь слово «список». Список - это в коде, а в задаче «последовательность», «стек», «очередь», «контейнер».

я бы согласился на слово «контейнер», но ты игнорируешь то, что в списке у тебя есть произвольное количество условно-бесплатных курсоров. Я привёл тебе пример про машины, чтобы ты это увидел, но ты вместо этого нагородил костылей, чтобы без этого обойтись. В любом варианте твоего решения про машины массив не даёт одновременно идентичность машины и возможность узнать, какая машина предыдущая, а какая следующая.

Если ты хранишь указатель на машину, то тебе нужно её найти в твоём контейнере, если хочешь узнать, за какой машиной она едет. Это займёт время O(число машин), потому что ты не заставишь машины всегда ехать в одном порядке.

Если ты хранишь координаты машины в виде (номер дека, номер машины в деке), то их нужно перестраивать на каждый чих.

Таким образом, если тебе нужно быстро определять предыдущую машину и ассоциировать с машиной ещё какую-то информацию, у тебя исказится архитектура. Возможно, с помощью горы костылей ты и выкрутишься. Но ты будешь неконкурентоспособен.

20 страниц ты уклоняешься от признания этого факта, хотя не только я тебе пытался его объяснить. С его учётом, список и массив нельзя ставить на одну доску. Поэтому их нельзя назвать одним словом «контейнер», если не оговаривать при этом, что это контейнеры с разными API.

Исправление den73, :

В любом случае, я ради смеха даже готов не спорить с идеей «после 10 млн можно подумать о целесообразности использования списка».

Вот и всё, что нам следует знать о ненужности списков.

Забудь слово «список». Список - это в коде, а в задаче «последовательность», «стек», «очередь», «контейнер».

я бы согласился на слово «контейнер», но ты игнорируешь то, что в списке у тебя есть произвольное количество условно-бесплатных курсоров. Я привёл тебе пример про машины, чтобы ты это увидел, но ты вместо этого нагородил костылей, чтобы без этого обойтись. В любом варианте твоего решения про машины массив не даёт одновременно идентичность машины и возможность узнать, какая машина предыдущая, а какая следующая.

Если ты хранишь указатель на машину, то тебе нужно её найти в твоём контейнере, если хочешь узнать, за какой машиной она едет. Это займёт время O(число машин), потому что ты не заставишь машины всегда ехать в одном порядке.

Если ты хранишь координаты машины в виде (номер дека, номер машины в деке), то их нужно перестраивать на каждый чих.

20 страниц ты уклоняешься от признания этого факта, хотя не только я тебе пытался его объяснить. С его учётом, список и массив нельзя ставить на одну доску. Поэтому их нельзя назвать одним словом «контейнер», если не оговаривать при этом, что это контейнеры с разными API.

Исправление den73, :

В любом случае, я ради смеха даже готов не спорить с идеей «после 10 млн можно подумать о целесообразности использования списка».

Вот и всё, что нам следует знать о ненужности списков.

Забудь слово «список». Список - это в коде, а в задаче «последовательность», «стек», «очередь», «контейнер».

я бы согласился на слово «контейнер», но ты игнорируешь то, что в списке у тебя есть произвольное количество условно-бесплатных курсоров. Я привёл тебе пример про машины, чтобы ты это увидел, но ты вместо этого нагородил костылей, чтобы без этого обойтись. В любом варианте твоего решения про машины массив не даёт одновременно идентичность машины и возможность узнать, какая машина предыдущая, а какая следующая.

Если ты хранишь указатель на машину, то тебе нужно её найти в твоём контейнере, если хочешь узнать, за какой машиной она едет.

Если ты хранишь координаты машины в виде (номер дека, номер машины в деке), то их нужно перестраивать на каждый чих.

20 страниц ты уклоняешься от признания этого факта, хотя не только я тебе пытался его объяснить. С его учётом, список и массив нельзя ставить на одну доску. Поэтому их нельзя назвать одним словом «контейнер», если не оговаривать при этом, что это контейнеры с разными API.

Исправление den73, :

В любом случае, я ради смеха даже готов не спорить с идеей «после 10 млн можно подумать о целесообразности использования списка».

Вот и всё, что нам следует знать о ненужности списков.

Забудь слово «список». Список - это в коде, а в задаче «последовательность», «стек», «очередь», «контейнер».

я бы согласился на слово «контейнер», но ты игнорируешь то, что в списке у тебя есть произвольное количество условно-бесплатных курсоров. Я привёл тебе пример про машины, чтобы ты это увидел, но ты вместо этого нагородил костылей, чтобы без этого обойтись. В любом варианте твоего решения про машины массив не даёт одновременно идентичность машины и возможность узнать, какая машина предыдущая, а какая следующая.

Если ты хранишь указатель на машину, то тебе нужно её найти в твоём контейнере, если хочешь узнать, за какой машиной она едет.

Если ты хранишь координаты машины в виде (номер дека, номер машины в деке), то их нужно перестраивать на каждый чих.

20 страниц ты уклоняешься от признания этого факта, хотя не только я тебе пытался его объяснить. С его учётом, список и массив нельзя ставить на одну доску.

Исходная версия den73, :

В любом случае, я ради смеха даже готов не спорить с идеей «после 10 млн можно подумать о целесообразности использования списка».

Вот и всё, что нам следует знать о ненужности списков.

Забудь слово «список». Список - это в коде, а в задаче «последовательность», «стек», «очередь», «контейнер».

я бы согласился на слово «контейнер», но ты игнорируешь то, что в списке у тебя есть произвольное количество условно-бесплатных курсоров. Я привёл тебе пример про машины, чтобы ты это увидел, но ты вместо этого нагородил костылей, чтобы без этого обойтись. В любом варианте твоего решения про машины массив не даёт одновременно идентичность машины и возможность узнать, какая машина предыдущая, а какая следующая.

Если ты хранишь указатель на машину, то тебе нужно её найти в твоём контейнере, если хочешь узнать, за какой машиной она едет.

Если ты хранишь координаты машины в виде (номер дека, номер машины в деке), то их нужно перестраивать на каждый чих.

20 страниц ты уклоняешься от признания этого факта. С его учётом, список и массив нельзя ставить на одну доску.