Шаблон функции для вывода с помощью итератора

Здравствуйте! В лабораторной работе написан код шаблона функции для вывода с помощью итератора

При попытке компиляции строчка выдает ошибки:
1) Ошибка C2760 синтаксическая ошибка: непредвиденный токен "идентификатор"; требуется ";"
2) Ошибка C7510 "iterator": при использовании зависимого имени тип необходимо указать префикс "имя типа"

По советам из интернета, прообовал изменять строку на при этом появляются ошибки линковки.

Подскажите, в чем ошибка и как ее исправить?

0

Сообщение от Royal_X здесь так принято еще не отменяли

ну в целом это имеет некоторый смысл. "работает(хоть как-то) - не трогай" и прочие истории. когда понимания нет, остаётся только что-то подобное.

но даже в рамках подобного логика странная. ведь уже есть auto x = 0, * y = (int*){}, где типы также разные.

0

Сообщение от mashmed135 ведь уже есть auto x = 0, * y = (int*){}, где типы также разные.

Во-первых, в С++ нет никакого (int*){}. Нет такого синтаксиса.

Во-вторых, что именно имеется в виду под соответствием типов между деклараторами я подробно объяснял выше:

Сразу понятна очевидная железобетонная причина не допускать смешения типов в множественных auto-объявлениях: объявление должно вести себя точно так же, как вели себя объявления в С++ с начала веков. Вся идея auto в С++ построена на едином подходе - это не более чем placeholder для конкретного типа. Во всем остальном этот placeholder ведет себя так же, как ведет себя конкретный тип.

Речь идет о спецификаторе типа всей декларации, т.е. о decl-specifier-seq. Всякие * относятся исключительно к индивидуальным деклараторам, и на тип всей декларации никак не влияют.

0

Сообщение от TheCalligrapher Во-первых, в С++ нет никакого (int*){}. Нет такого синтаксиса.

есть. просто ты ничего не знаешь о с++.

да и с чего вдруг кто-то монополизирует понятие "с++"? я бы ещё понял, если бы подобное исходило от того же гцц, либо, в крайнем случае, шланга - поскольку гцц это топовая реализация ц/цпп, а шланг альтернативная реализация уже его. но когда местные эксперты начинают определять что чем является, да ещё и без каких-либо оснований - это типичное сектанство.

Сообщение от TheCalligrapher Сразу понятна очевидная железобетонная причина не допускать смешения типов в множественных auto-объявлениях: объявление должно вести себя точно так же, как вели себя объявления в С++ с начала веков

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

Сообщение от TheCalligrapher Вся идея auto в С++ построена на едином подходе - это не более чем placeholder для конкретного типа. Во всем остальном этот placeholder ведет себя так же, как ведет себя конкретный тип.

неверно. никаким "для конкретного типа" авто не является. я не знаю, как можно приходить к подобным выводам, ведь даже в стандарте есть auto... и auto [...], где типы также разные.

если свести цитатку к адекватной форме, довод за один тип - консистентность с объявлениями без вывода типов. вот мы пишем int x, и далее базовый тип у нас везде фиксирован, единственное что можно сделать - накинуть деклараторов. штука в том, что эта схема не может работать иначе - там уже написан тип и от этого никуда не уйти. но форма с авто не имеет подобных ограничений, тип там явно не проставляется.

далее возникает вопрос: с чего вдруг ограничения для одного случая должны продуцировать запреты для другого? особенно в ситуации, когда отсутствие этих запретов обладает преимуществами? а ни с чего. никто и нигде не ориентируется на самый примитивный уровень и не ограничивает на этом основании уровень менее примитивного(ну кроме сектантов, конечно).

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

0

Сообщение от mashmed135 есть. просто ты ничего не знаешь о с++.

Давно у нас не было таких жыыыырных троллей Или это кто-то из старых знакомых под новым именем?

После этого "есть" дальше можно не читать. Спасибо, что в начало вынес.

1

TheCalligrapher, так это очень давний пациент, в очередной раз из бани вернулся. Он не надолго приходит

1

Сообщение от TheCalligrapher Давно у нас не было таких жыыыырных троллей

читаем правильно: "мне нечего ответить и я решил съехать с темы на какую-то левую муру(типа троллей). ведь если я попытаюсь ответить что-то конкретное, то похороню себя как эксперта". в очередной раз, удивительное рядом.

но в целом, молодец, место своё уже знаешь. осталось только в моё отсутствие не строить из себя кого-то выше рядового.

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

Сообщение от Алексей1153 TheCalligrapher, так это очень давний пациент, в очередной раз из бани вернулся. Он не надолго приходит

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

0

GCC компилирует без ошибки и такой код:

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

if auto deduction can't be performed during the parsing, because the initializers have dependent types, it is premature to diagnose inconsistent deduction, the deduction might be inconsistent, but might be consistent as well. But this also reveals that without extra infrastructure, we don't and can't diagnose invalid cases After parsing we loose the information which variables have been declared together and what auto deduction has been performed. So perhaps we'd need some extra tree that would hold a vector of variables (for those not deduced during parsing) and auto_result (for those deduced during parsing) and during instantiation check for the inconsistencies again.

Я так понимаю, баг очень глубокий и сложный в исправлении. Причем, разрабы полностью осведомлены в его существовании.

0

ну т.е. разработчикам компиляторов на самом деле проще сделать интерпретацию
auto a,b,c
как
auto a; auto b; auto c;
Что, вообще говоря (по моему скромному мнению) даже в чем-то логично при чтении программы (но только в чем-то, зависит от "применяемой логики", ибо логику можно подвести и для той, и для другой интерпретации, если честно).

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

Как вариант, gcc ждут когда стандарт в этом месте перепишут.
Тоже вполне себе подход: менять ТЗ, а не код

0

Сообщение от KSergey9 Получается разработчики стандарта подумали той логикой, которая сложнее в реализации компилятора.

Откуда такой вывод?

Разработки стандарта изначально вообще собирались запретить множественные деклараторы в объявлении с placeholder, то есть собирались именно идти по более простому пути. Возможность указывать множественные деклараторы в таком объявлении - результат последующих предложений, в частности https://open-std.org/jtc1/sc22... /n1737.pdf

Собственно, в большинстве случаев тема не стоит и выеденного яйца, ибо "почти всегда" можно просто разобрать одно объявление на несколько. Трудности возникают только в таких контекстах, как, например, for. Но эти трудности на само деле не имеют отношение к auto вообще. Это извечная проблема for. Даже безо всякого auto иногда хочется иметь возможность объявить несколько переменных раных типов в заголовке for. Если эта проблема будет решена, то это решение распространится и на auto.

0

Сообщение от TheCalligrapher Разработки стандарта изначально вообще собирались запретить множественные деклараторы в объявлении с placeholder,

Но сделали ведь не так, судя по ране процитированным в этой теме фрагментам стандарта
Шаблон функции для вывода с помощью итератора (это же стандарт процитирован? или просто предложения? я не вникал в источник)

Я же говорю о том как сделали, а не о том, что обсуждалось.

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

Сообщение от TheCalligrapher Откуда такой вывод?

Из процитированного ответа разработчиков
https://www.cyberforum.ru/post17376746.html

0

Сообщение от KSergey9 Из процитированного ответа разработчиков https://www.cyberforum.ru/post17376746.html

Но это ответ разработчиков GCC, а не разработчиков стандарта.

0

Сообщение от TheCalligrapher Но это ответ разработчиков GCC, а не разработчиков стандарта.

Так.
Но стандарт диктует иное поведение, верно?

Может вы перечитаете то что я написал? может я как-то невнятно изложил?
Шаблон функции для вывода с помощью итератора
Я не понимаю с чем вы спорите. Складывается впечатление, что спорите ради спора. При этом пишете всё то, что я написал изначально. Не в смысле что я умный, а в смысле я никак не могу понять о чем вы со мной спорите.

0

Сообщение от KSergey9 Может вы перечитаете то что я написал? может я как-то невнятно изложил?

Вот наш диалог, по шагам (выделение жирным моё):

Вы #28: Получается разработчики стандарта подумали той логикой, которая сложнее в реализации компилятора.
Я #29: Откуда такой вывод? Разработчики стандарта изначально... (и т.д.)
Вы #30: Из процитированного ответа разработчиков (и внезапно ссылка на ответ разработчиков компилятора)
Я #31: ¯\_(ツ)_/¯ (в недоумении: при чем здесь разработчики компилятора, если изначально мы оба вели речь о разработчиках стандарта?)

Сообщение от KSergey9 Я не понимаю с чем вы спорите.

Я пока не вижу здесь никакого спора из-за некоторой... эээ... бессвязности переписки, пример которой я привел выше.

0

Сообщение от TheCalligrapher бессвязности переписки, пример которой я привел выше.

Мне она не видится бессвязной с моей стороны, что, вероятно, логично.

Я для простоты оставлю "Вы" и "Я" так, как было в вашем тексте, хорошо? просто чтобы еще раз не запутаться нам с вами.
И допишу курсовом свои уточнения.

Вы #28: Получается разработчики стандарта подумали той логикой, которая сложнее в реализации компилятора. Я #29: Откуда такой вывод? Разработчики стандарта изначально... (и т.д.)

Я не понимаю какая разница о чем разработчики стандарта думали изначально. Возможно они даже перебирали множество вариантов.
Однако остановились в итоге на том, что сложнее при разработке компилятора. Так ведь? Ровно об этом я и писал.
Вероятно здесь я не очень удачно употребил фразу "подумали той логикой". Однако под ней я подразумевал финальное решение, вошедшее стандарт, а не весь процесс обдумывания этой фичи языка вообще.

Вы #30: Из процитированного ответа разработчиков (и внезапно ссылка на ответ разработчиков компилятора)

Здесь под "разработчиками" я имел ввиду разработчиков именно компилятора, а не писателей стандарта; тут видимо терминологическая опять путаница и смешение произошло из-за неидеально точных формулировок с моей стороны.

Я #31: ¯\_(ツ)_/¯ (в недоумении: при чем здесь разработчики компилятора, если изначально мы оба вели речь о разработчиках стандарта?

Очень надеюсь, что теперь все недоумения и недопонимания разрешились.

0