21.09.2014, 17:33 | |
Ответы с готовыми решениями:
73
Вывести самые распространенные женские и мужские имена Вывести самые распространенные мужские и женские имена Ошибки после компиляции на Visual Express 2012.Ошибки в теме Распространенные ошибки |
Модератор
8950 / 6716 / 921
Регистрация: 14.02.2011
Сообщений: 23,708
|
||||||||||||||||
07.01.2015, 21:26 | 41 | |||||||||||||||
Некорректное использование логических переменных
часто встречаю такую вешь
if ( tmp == true ) и есть тавтология (тождественно истинное высказывание, инвариантное относительно значений своих компонентов, по - русски повтор)рассмотрим подробнее if срабатывает если в скобках ИСТИНА (true) если ЛОЖЬ (false) то управление передается ветке else теперь смотрим tmp==true tmp имеет значение true результат true, if исполняется tmp==true tmp имеет значение false результат false, исполняется else как видим результат равен tmp поэтому достаточно, и необходимо написать if ( tmp ) вместо if ( tmp == true ) ошибка не так безобидна, как она кажется в WinApi до сих пор используется тип BOOL это макрос int и в разных версиях компилятора TRUE имело значение и 1 и -1 (все биты единицы) а в языке C, C++ принято соглашение все что не 0 это ИСТИНА 0 это ЛОЖЬ теперь представим себе что в переменную типа BOOL tmp записали 1 это по соглашениям языка все равно что tmp=ИСТИНА но TRUE определен как -1 и условие if ( tmp == TRUE ) не сработаеттогда как if ( tmp ) сработает правильнов старых MSDNах писали, не знаю как сейчас, нельзя сравнивать с TRUE только с FALSE (поскольку оно однозначно 0) т.е наша запись должна выглядеть так
1
|
Форумчанин
8216 / 5046 / 1437
Регистрация: 29.11.2010
Сообщений: 13,453
|
||||||
09.01.2015, 00:17 | 42 | |||||
Таки распространенная ошибка? Не видел чтобы множество новичков использовали BOOL из WinAPI. И тем более сравнивали так:
2
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||||
10.01.2015, 01:49 | 43 | |||||
Невалидные ссылки/указатели, при перемещении объектов.
Пример: Реаллок вектора: История болезни: 1. В вектор напихиваются объекты по значению. 2. Из вектора срисовывается ссылка/указатель на какое либо из его значений. 3. В вектор напихивают ещё некоторое количество объектов. 4. В какой то момент резерв памяти иссякает, и вектор реалочится - расширяет буфер, переносит туда свои объекты. В результате объекты меняют адрес. 5. Выданные наружу ссылки/указатели становятся недействительными, но никто никого об этом не предупредил. 6. Обращение по невалидному указателю/ссылки - крэш времени выполнения. Искать причину таких вылетов затруднительно, потому что: 1. Авария обычно происходит далеко от места причины аварии. 2. В целях оптимизации, для вектора любят резервировать память (vector::reserve). В результате в большинстве случаев резерва хватает, и вектор редко реалочится. В результате баги долгое время могут оставаться незамеченными, а когда стреляет - довольно сложно сказать почему (сп пункт 1) Пример: http://rextester.com/AWJSK45012
Потому что помимо вектора, она может встречаться в самых разных ситуациях. Например: создали std::function на метод класса, объект переехал, делегат покрэшел весь процесс. И тп.
5
|
Модератор
13710 / 10910 / 6476
Регистрация: 18.12.2011
Сообщений: 29,133
|
|||||||||||
19.01.2015, 10:19 [ТС] | 44 | ||||||||||
Неправильное обращение к конструктору по умолчанию.
Круглые скобки ставятся для явного указания, что нужен конструктор без параметров. Однако, такая конструкция интерпретируется как объявление (прототип) функции без параметров с именем a, которая возвращает значение типа A. Правильным будет такое объявление:
5
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||||||||||
31.01.2015, 19:04 | 45 | ||||||||||
Не очевидные моменты с вызовом конструктора базового класса
Ошибка на внимательность: При копировании объектов вместо конструктора копии, у базового класса запускается конструктор по умолчанию Рассмотрим код: http://rextester.com/CLL66454
Кликните здесь для просмотра всего текста
Не по теме: value = 10 : size = 0 Некоторые программисты ошибочно считают само собой разумеющимся, что, при наследовании конструктор копии будет порождать вызов конструктора копии базового класса. Оно и понятно: ведь именно такое поведение подсказывает здравый смысл. Однако на самом деле все иначе: программист должен явно указать какой базовый конструктор нужно запустить:
7
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||||||||||||||||||||
01.03.2015, 17:47 | 46 | ||||||||||||||||||||
Ошибки связанные с итераторами (кэширование размера контейнера).
Такие ошибки обычно проявляются собственно по прямому назначению итераторов: в пробегах по циклам. Рассмотрим примеры:
На самом деле - 2й способ, потому что в первом случае на каждом шаге цикла каждый раз заново рассчитывается размер контейнера. Особенно это критично для контейнеров, чей размер долго рассчитывается. Между новичками бытует миф, якобы компилятор самостоятельно умеет оптимизировать расчеты в условии цикла. Ну так вот это - не правда. И ниже я объясню почему. В книгах для новичков существует рекомендация: самостоятельно закэшировать размер в виде константы, что бы потом не высчитывать его каждый раз заново. Ошибка новичка здесь: если он попытается закэшировать размер контейнера, а потом в теле цикла добавит/удалит элемент. В худшем случае это приведет к некорректному поведению программы:
Но он не оптимизирует мутабельную переменную, именно потому, что в теле цикла эти переменные могут быть изменены. В лучшем случае компилятор может оптимизировать и мутабельную переменную, при условии, что в теле цикла ему доступна вся полнота информации, и он может гарантировать, что её оптимизация не нарушит логику работы цикла.
3
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|||||||||||||||||||||
01.03.2015, 17:47 | 47 | ||||||||||||||||||||
Ошибки связанные с итераторами (удаление элементов по итератору в циклах).
Рассмотрим пример:
После удаления элемента, итератор ссылается на несуществующий элемент. Он не знает о том, что он теперь уже - невалидный. Нельзя использовать невалидные итераторы. Однако в цикле для него делается ++it .Первая мысль, которая может придти в голову новичку: после удаления, присвоить итератору новое значение, что бы итератор всегда оставался валидным:
Это связанно с тем, что инструкция: it = mylist.erase( it ); Присваивает итератору ссылку на элемент, идущий сразу же следом после удаляемого. После чего отрабатывает инструкция цикла ++it И получается, что алгоритм перескакивает через элемент. Правильная версия выглядит так:
3
|
8972 / 4318 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||||
01.03.2015, 17:47 | 48 | |||||
Ошибки связанные с итераторами (префикс-постфиксные инкременты при удалении элементов в цикле).
Многие новички следуют за опытными специалистами, подражая их стилю. А в профессиональном коде часто можно встретить использование свойств префикс-постфикс операций:
Это уже особенности инкрементов. И больше относится к ошибкам связанным именно с инкрементами, нежели с итераторами. При постфиксонй форме будет удален текущий элемент, несмотря на то, что сам итератор инкременируется ещё до удаления. А при префиксной - сначала инкрементируется, и только потом будет удален уже следующий элемент, что само по себе уже ошибка в логике. При этом, попытка удалить таким образом последний элемент приведет к удалению элемента за пределами контейнера, что и вызывает крэш. ----------------------------------------------------------------------------- Несмотря на то, что ошибки связанные с итераторами, и ошибки связанные с префикс-постфикс инкрементом - это немножно разные плоскости, тем не менее они чаще всего встречаются рядышком в циклах, при пробеге по контейнеру. И об этом стоит знать, хотя бы потому, что часто спрашивают на собеседованиях. Показывают код, который содержит оби ошибки, и просят его исправить. Часто джуниоры находят только одну ошибку. Резюмируя: 1. Прежде чем кэшировать данные, нужно подумать - не изменятся ли они. 2. Не нужно спорить, что быстрее: ++i или i++ Нужно понимать, что делают обе формы инкремента, и использовать их по назначению.
3
|
Модератор
8950 / 6716 / 921
Регистрация: 14.02.2011
Сообщений: 23,708
|
||||||||||||||||
21.04.2015, 07:53 | 49 | |||||||||||||||
Неявно объявленный конструктор по умолчанию
Вот еще заметил такую вещь (это скорее ошибка терминологии и непонимание работы компилятора ): Компилятор не понимает тип Array в данном случае это не конструктор по умолчанию а конструктор без параметров конструктор по умолчанию это конструктор который вставляет компилятор,который чаще всего ничего не делает как только мы описали хоть один конструктор конструктор по умолчанию пропадает например
а вот здесь
необходимо описать конструктор без параметров возможный выход описание конструктора с параметрами по умолчанию
0
|
22.04.2015, 14:16 | 50 | |||||
Из Стандарта (гл. 12.1)
5
|
:)
4773 / 3267 / 497
Регистрация: 19.02.2013
Сообщений: 9,046
|
|||||||||||
27.05.2015, 13:35 | 51 | ||||||||||
Некоторые замечания по уже размещенным ошибкам.
system() объявлена в <cstdlib>, а не в <iostream> Далеко не факт. Пример:
Иначе возможен и ложный результат. Правильнее было бы сказать "... когда память больше никому не нужна". Хорошо бы заменить на std::abs (всё таки раздел плюсов тут)Снова нужно уточнить тип и не только, иначе истина может оказаться ложью даже для стандартного типа double. To be continued ...
2
|
941 / 869 / 355
Регистрация: 10.10.2012
Сообщений: 2,706
|
|||||||||||
24.06.2015, 20:40 | 52 | ||||||||||
По поводу этого:
Распространенные ошибки
cin.rdbuf()->in_avail() не работает без предварительного ios_base::sync_with_stdio( 0 ) .
1
|
2836 / 1645 / 254
Регистрация: 03.12.2007
Сообщений: 4,222
|
||||||
25.06.2015, 17:06 | 53 | |||||
Должно работать везде и всегда:
0
|
08.08.2015, 20:38 | 54 | |||||
Ошибка преобразования:
Type ** в const Type ** .
0
|
14 / 14 / 6
Регистрация: 11.07.2015
Сообщений: 147
|
||||||
11.03.2016, 11:30 | 55 | |||||
Опечатка в имени метки default в блоке switch.
Пример:
1
|
Модератор
13710 / 10910 / 6476
Регистрация: 18.12.2011
Сообщений: 29,133
|
|
11.03.2016, 12:28 [ТС] | 56 |
anem, Оно откомпилируется с предупреждением:
"Ребята, читайте сообщения о предупреждениях!" не голословное!
1
|
Модератор
8950 / 6716 / 921
Регистрация: 14.02.2011
Сообщений: 23,708
|
|
13.03.2016, 11:15 | 57 |
разумеется
потому что компилятор это считает меткой, с тем же успехом можно было написать bla_bla_bla: но компилятор предупреждает так что прав zss,
0
|
Комп_Оратор)
|
||||||||||||||||||||||||||
19.03.2016, 02:41 | 58 | |||||||||||||||||||||||||
Данное сообщение относится скорее всего к:
Ошибки, связанные с отклонением от стандарта языка Речь пойдет о файле (всеми любимом) windows.h О его воинственном нраве можно много чего в сети разыскать. Я покажу это на примере простой задержки перед возвратом:
Вполне возможно что иногда так можно обойти и другие конфликты связанные с этим файлом.
2
|
Неэпический
|
|||||||||||
19.03.2016, 07:02 | 59 | ||||||||||
IGPIGP, при
При
Можно, конечно, поставить sync_with_stdio(false) ,но это, если не ошибаюсь, тоже не даст никакой гарантии, так что этот способ тоже не особо переносим. Что касается get, то тоже не факт что сработает. Недавно натыкался на то, что get удалял один символ из потока, тогда как '\n' был из двух, так что пришлось делать get два раза, чтобы оно работало. Следовательно, get тоже никакой гарантии не дает. Как по мне, то лучше читать в строку и уже потом парсить. ИМХО, это самое надежное решение.
1
|
Комп_Оратор)
|
|
19.03.2016, 10:48 | 60 |
Я же говорю, для примера написал. Если нет '\n' то должно очистить до конца ведь?
Это древний и вполне звонкий бубен.
0
|
19.03.2016, 10:48 | |
19.03.2016, 10:48 | |
Помогаю со студенческими работами здесь
60
безопасность и распространенные ошибки безопасность и распространенные ошибки Распространенные ошибки SEO и ASP.NET 2.0 Самые распространенные строки Самые распространённые фамилии Распространённые схемы мошейничества с вайбером Самые распространенные мужское и женское имена Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |