Здравствуйте, Kluev, Вы писали:

K>Не добавлять новое, а исправлять баги. Не хотят исправлять, пусть честно объявляют вложенные классы deprecated, чтобы программисты не попадались на грабли.

ИМХО, невозможность сделать предварительное объявление вложенного класса за пределами обрамляющего — еще не повод объявлять вложенные классы deprecated. Кстати, с обычными невложенными классами совершенно та же ситуация — предварительное объявление можно сделать только в том пространстве имен, к которому относится класс. Так что все стройно. Разница сводится лишь к тому, что пространство имен можно отрывать и закрывать произвольное количество раз, а с классом так поступать нельзя. Но, насколько я вижу, таких фантази ни у кого и не возникало до сих пор.

Здравствуйте, YuriV, Вы писали:

YV>А она и не является таковой. Здесь вопрос чисто академический — почему не дать такую возможность, если она выглядит логично и не несёт серьёзных трудностей в реализации?

Да со спецификациями доступа грязновато все же получается. Кроме того, если разрешить предварительные объявления вложенных классов за пределами обрамляющих, тогда придется разрешить и предварительные объявления классов за пределами их пространств имен — по точно таким же академическим соображениям. А посколько острой потребности в этих фичах пока не возникало, их отодвигают на задний план, как не особо приоритетные. Но это сугубо мое понимание картины.

Здравствуйте, Kluev, Вы писали:

хъ

K>Вот один из примеров. Допустим нужно перебрать все элементы кроме первого и последнего:

for (int i = 1; i < v.signed_size() - 1; i++)
{
    v[i];
}

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

Серьезно? Т.е. на знаковых, v[1] на пустом массиве работает благодара особой магии?

В алгоритме, в котором нужно "перебрать все элементы кроме первого и последнего" всегда будет отдельная ветка логики для пустого массива (скорее даже size() < 3), иначе он будет ломаться пусть не на этом конкретном цикле, а где-то еще. А это "всегда будет корректно работать" — тупое заметание мусора под коврик.

Здравствуйте, Patalog, Вы писали:

P>Серьезно? Т.е. на знаковых, v[1] на пустом массиве работает благодара особой магии?

для знаковых внутрь не зайдет...

Здравствуйте, Kluev, Вы писали:

K>Вот один из примеров. Допустим нужно перебрать все элементы кроме первого и последнего:
K>

K>    for (int i = 1; i < v.signed_size() - 1; i++)
K>    {
K>        v[i];
K>    }

K>    for (size_t i = 1; i < v.unsigned_size() - 1; i++)
K>    {
K>        v[i];
K>    }
K>

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

И мертвые совы вдоль дорог лежат...

А вот так будет работать как со знаковыми, так и с беззнаковыми:

    for (size_t i = 1; i + 1 < v.unsigned_size(); ++i)
    {
        v[i];
    }

Готов выслушать гневные обвинения в свой адрес

P.S. А если прибить подковы к колесам крузака, крузак никуда не поедет. Вывод — крузак говно.

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kluev, Вы писали:


R>А вот так будет работать как со знаковыми, так и с беззнаковыми:

R>

R>    for (size_t i = 1; i + 1 < v.unsigned_size(); ++i)
R>    {
R>        v[i];
R>    }
R>

R>Готов выслушать гневные обвинения в свой адрес

Дополнительные мысленные усилия потраченные совершенно впустую, как при написании, так и при чтении этого кода. Эдакая акробатика в инвалидной коляске.

Здравствуйте, Kluev, Вы писали:

K>Дополнительные мысленные усилия потраченные совершенно впустую, как при написании, так и при чтении этого кода. Эдакая акробатика в инвалидной коляске.

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

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kluev, Вы писали:

K>>Не добавлять новое, а исправлять баги. Не хотят исправлять, пусть честно объявляют вложенные классы deprecated, чтобы программисты не попадались на грабли.

R>ИМХО, невозможность сделать предварительное объявление вложенного класса за пределами обрамляющего — еще не повод объявлять вложенные классы deprecated. Кстати, с обычными невложенными классами совершенно та же ситуация — предварительное объявление можно сделать только в том пространстве имен, к которому относится класс. Так что все стройно. Разница сводится лишь к тому, что пространство имен можно отрывать и закрывать произвольное количество раз, а с классом так поступать нельзя. Но, насколько я вижу, таких фантази ни у кого и не возникало до сих пор.

Чего здесь стройного? Уродство на уродстве и уродством погоняет. Унаследовали из С связку костылей в виде препроцессора и опережающего описания и десятки лет не могут довести до ума. В том же паскале от препроцессора отказались еще в 1978 году. А с++ как обычно. Задержка в развитии на более чем 40 лет.

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kluev, Вы писали:

K>>Дополнительные мысленные усилия потраченные совершенно впустую, как при написании, так и при чтении этого кода. Эдакая акробатика в инвалидной коляске.

R>Какого-то такого ответа я и ожидал. Перенос слагаемого из одной части в другую — это сверхакробатика, конечно. Впрочем, как и любая другая попытка исправить ошибку в коде, которая так тебе дорога.

У нормальных людей от перемены мест слагаемых сумма не меняется.

Здравствуйте, Kluev, Вы писали:

K>У нормальных людей от перемены мест слагаемых сумма не меняется.

Что-то как-то не в кассу высказывание. В моем варианте тоже не меняется. Не веришь? Смотри:

    for (size_t i = 1; 1 + i < v.unsigned_size(); ++i)
    {
        v[i];
    }

Здравствуйте, Kluev, Вы писали:

K>Чего здесь стройного? Уродство на уродстве и уродством погоняет. Унаследовали из С связку костылей в виде препроцессора и опережающего описания и десятки лет не могут довести до ума. В том же паскале от препроцессора отказались еще в 1978 году. А с++ как обычно. Задержка в развитии на более чем 40 лет.

Здравствуйте, night beast, Вы писали:

[]

NB>для знаковых внутрь не зайдет…

Ага, точно, спасибо.
Но, блин, это камень в огород плоскоземельниковзнакоразмерников — люди серьезно считают что это лучше для чтения и понимания?

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Kluev, Вы писали:

K>>У нормальных людей от перемены мест слагаемых сумма не меняется.

R>Что-то как-то не в кассу высказывание. В моем варианте тоже не меняется. Не веришь? Смотри:

R>

R>    for (size_t i = 1; 1 + i < v.unsigned_size(); ++i)
R>    {
R>        v[i];
R>    }
R>

R>

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

Здравствуйте, Patalog, Вы писали:

P>Здравствуйте, night beast, Вы писали:

P>[]

NB>>для знаковых внутрь не зайдет…

P>Ага, точно, спасибо.
P>Но, блин, это камень в огород плоскоземельниковзнакоразмерников — люди серьезно считают что это лучше для чтения и понимания?

Если вам не понятен этот код позвольте я первый кину в вас камень

Здравствуйте, PM, Вы писали:

PM>Так в чем загвоздка, подберите упавшее знамя, и вперёд, в комитет, дорабатывать эту важную вещь! Может быть даже РГ21 вам поможет в проталкивании...

А зачем? Мне это не нужно. У Kluev пригорает пусть он и двигает.

PM>А у вас есть такой стратегический план? Было бы любопытно ознакомиться с этим документом.

Концепты, Лямбды, Рефлексия, Модули — в полноценном виде и ещё вчера. Например в С++11/14/17. Сложилось только с лямбда, да и то, внутреннее представление лямбд было известно ещё до С++11 и можно было бы реализовать auto и template лямбды ещё в С++11. И всё это не для того чтобы было, а потому что всё это кардинально изменило бы подход к разработке на С++.

Здравствуйте, night beast, Вы писали:

S>>>* пространства имен не решают ни одной проблемы, а взамен можно использовать префиксы;

K>>Именно так господа. В с++ пространства имен не более чем синтаксический сахар без которого прекрасно можно жить и многие так и делают.

NB>как у вас там, в мире префиксов, adl поживает?

Рискну предположить, что он там не нужен, т. к. он нужен только для неймспейсов. Нет неймспейсов — нет проблем с лукапом параметров. Типы-то самодостаточные получаются.

Здравствуйте, boomer, Вы писали:

B>Рискну предположить, что он там не нужен, т. к. он нужен только для неймспейсов. Нет неймспейсов — нет проблем с лукапом параметров. Типы-то самодостаточные получаются.

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

Здравствуйте, night beast, Вы писали:

B>>Рискну предположить, что он там не нужен, т. к. он нужен только для неймспейсов. Нет неймспейсов — нет проблем с лукапом параметров. Типы-то самодостаточные получаются.

NB>это не так. только неймспейсами adl не ограничивается.
NB>оно нужен для обобщенного программирования.

Я не защищаю отсутствие неймспейсов. Они действительно удобны и полезны во многих случаях.
Но все же. Представим, что неймспейсов нет, и используются префиксы. В каком случае подадобится ADL для шаблонов?

Здравствуйте, boomer, Вы писали:

B>Я не защищаю отсутствие неймспейсов. Они действительно удобны и полезны во многих случаях.
B>Но все же. Представим, что неймспейсов нет, и используются префиксы. В каком случае подадобится ADL для шаблонов?

template<typename T>
void foo(T x, T y)
{
  using std::swap;
  swap(x, y);
}

Здравствуйте, night beast, Вы писали:

B>>Я не защищаю отсутствие неймспейсов. Они действительно удобны и полезны во многих случаях.
B>>Но все же. Представим, что неймспейсов нет, и используются префиксы. В каком случае подадобится ADL для шаблонов?

NB>

NB>template<typename T>
NB>void foo(T x, T y)
NB>{
NB>  using std::swap;
NB>  swap(x, y);
NB>}
NB>

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

Какой-такой using std::swap?