136 / 49 / 5
Регистрация: 10.01.2017
Сообщений: 1,894
|
||||||||||||||||
1 | ||||||||||||||||
byte - неоднозначный символ (С++17)11.03.2021, 13:26. Показов 9203. Ответов 15
Метки нет (Все метки)
Здравствуйте,
Возникла такая проблема, компилирую код, как С++17(нужен std::filesystem), и тут возникает проблема:
К примеру в файле rpcndr.h ошибка возникает вот в этой строчке:
Я так грубо понял, что в С++17 добавилось, ключевое или резервное слово "byte"(но это не точно) и оно конфликтует с таким же именем где то в Windows.h. На MSDNе написано:
0
|
11.03.2021, 13:26 | |
Ответы с готовыми решениями:
15
Ошибка C2872 count: неоднозначный символ Error C2872: Keyboard: неоднозначный символ "error C2872: неоднозначный символ" при переменной count Ошибки компиляции: "Неоднозначный символ". |
Модератор
13706 / 10909 / 6473
Регистрация: 18.12.2011
Сообщений: 29,125
|
||||||
11.03.2021, 13:37 | 2 | |||||
Сообщение было отмечено Optimus11 как решение
Решение
А если убрать
Возможно, у Вас неправильно подключен пакет sdk: Попробуйте тут поменять версию.
1
|
136 / 49 / 5
Регистрация: 10.01.2017
Сообщений: 1,894
|
|
11.03.2021, 13:49 [ТС] | 3 |
Изменение SDK не помогает.
Теоретически убирание using namespace std не должно помочь: -Я замучаюсь каждой переменной std:: приписывать -У меня в проекте нет слово byte, которому я бы мог приписать std:: -если в свойствах проекта поставить C++14 - ошибка исчезает. Может быть такое, что это еще может быть из за подключенной zlib библиотеки ? Ну да же, если так, как это победить не понятно.
0
|
фрилансер
5846 / 5375 / 1103
Регистрация: 11.10.2019
Сообщений: 14,365
|
|
11.03.2021, 13:55 | 4 |
Сообщение было отмечено Optimus11 как решение
Решение
я до сих пор не замучался )
Добавлено через 1 минуту а вот с этим геморрой и головная боль обеспечены Добавлено через 44 секунды так оно есть в упомянутых выше файлах
1
|
136 / 49 / 5
Регистрация: 10.01.2017
Сообщений: 1,894
|
|
11.03.2021, 14:30 [ТС] | 5 |
В общем, не знаю в итоге какой там byte c каким пересекается, но поставил #include "Windows.h" над всеми инклудами, ошибка ушла.
Но теперь, я боюсь, что вся это история может потом привести к каковому нибудь неправильному поведению работы кода.
0
|
Just Do It!
|
||||||
11.03.2021, 14:42 | 6 | |||||
походу крестоизобретатели зря старались:
а ведь можно спрятать весь <windows.h> в своём пространстве имён, которое не будет пересекаться, а значит и мешать любым другим библиотекам, в том числе и стандартным:
2
|
136 / 49 / 5
Регистрация: 10.01.2017
Сообщений: 1,894
|
|
11.03.2021, 14:56 [ТС] | 7 |
В общем да, проблема в этом!
Видимо, нужно прекращать использовать этот using. Но так неудобно будет.
0
|
фрилансер
5846 / 5375 / 1103
Регистрация: 11.10.2019
Сообщений: 14,365
|
|
11.03.2021, 15:07 | 8 |
запросто )
только дефайны всё равно будут торчать, а их там дофига а если в таком дефайне будет упоминание чего-то апишного, то ещё и не соберётся, так как внутри макроса не будет win:: уверяю, что даже не заметишь разницы в использовании
0
|
Just Do It!
|
|
11.03.2021, 15:24 | 9 |
ага, никогда не было и снова опять:
осталось научиться не смешивать сишный код с крестокодом, или научиться смешивать их правильно. обозначенная вами проблема напоминает мне использование в одной функции одновременно и std::string и strlen(..), такое нередко можно увидеть в этом разделе форума. всё это можно элементарно разрулить.
0
|
фрилансер
5846 / 5375 / 1103
Регистрация: 11.10.2019
Сообщений: 14,365
|
|
11.03.2021, 15:45 | 10 |
XLAT, но лучше не допускать. Я так щитаю
1
|
Just Do It!
|
|
11.03.2021, 16:55 | 11 |
да не вопрос.
в данном случае возможно будет достаточно, просто добавить в свой "цикл разработки" термин "апи-зависимый модуль" ... Добавлено через 8 секунд да не вопрос. в данном случае возможно будет достаточно, просто добавить в свой "цикл разработки" термин "апи-зависимый модуль" ...
0
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
11.03.2021, 18:06 | 12 |
жессть. любители глобального #using namespace std должны страдать.грамотные люди никогда не подключают ос-специфичные заголовки глобально. Windows.h должен подключаться только по необходимости, и только в спп.
2
|
136 / 49 / 5
Регистрация: 10.01.2017
Сообщений: 1,894
|
|||||||||||
11.03.2021, 22:45 [ТС] | 13 | ||||||||||
Подскажите, есть ли какие нибудь реальные минусы, если использовать define`ы таким образом?
0
|
фрилансер
5846 / 5375 / 1103
Регистрация: 11.10.2019
Сообщений: 14,365
|
||||||
11.03.2021, 22:46 | 14 | |||||
Optimus11,
достаточно такого, остальное - лучше не лениться
1
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
11.03.2021, 22:53 | 15 |
так вообще нельзя делать, потому что это противоречит правилам языка.
нельзя переопределять ключевые слова, или стандартные идентификаторы. в противном случае поведение не определено.
1
|
DrOffset
|
12.03.2021, 00:40
byte - неоднозначный символ (С++17)
#16
|
Не по теме: Уже где-то я это говорил, но что за странная тяга самым страшным и спорным решениям? Вам реально настолько пофиг как у вас все работает, лишь бы было, да? :) В таких ситуациях обычно желается, чтобы врачи виновника лечили так же, как он пишет код - самыми страшными и спорными методами, какие только он сможет придумать. А оправдывать это все тем, что сразу-то пациент не умрет от этого. Но я вместо этого побольше ответственности за то, что вы делаете, пожелаю.
0
|
12.03.2021, 00:40 | |
12.03.2021, 00:40 | |
Помогаю со студенческими работами здесь
16
Нельзя преобразовать тип function(a: byte;b: byte): byte к integer (Списки) 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 - invalid start byte Перевести строку, содержащую данные массива байт (byte[]) в byte[] Invalid byte 1 of 1-byte UTF-8 sequence - ошибка (Intellij idea) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |