Добрый день.

Я новичок в C++, работал с Delphi, на C не писал.

Читаю Либерти - Освой самостоятельно С++ за 21 день.
Решил попробовать для тренировки написать простой класс для работы с dbf.
Буду очень благодарен за замечания к моему коду: ошибки, неверные подходы,
скрытые угрозы, реализация чере ж..., таких косяков думаю здесь много.

Вообще, C++ понравился очень, возможности впечатляют, но иногда некоторые простые вещи
не понятно как делать, например работа с char.

Делалось все в Dev-C++ 4.9.9.2. Исходники присоединены. 
Заранее спасибо за любые комментарии.


Присоединённый файл ( Кол-во скачиваний: 20 )
 dbf.rar 4,33 Kb

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

мне, к примеру, лень качать, запускать Dev-C++ 4.9.9.2....

Поскольку мало что понимаю что хорошо-плохо хочется комментарий по всему коду, там немного, строк 200
компилиться и в TC++

Не разраривается   у меня линь   

Это сообщение отредактировал(а) GrayCardinal - 6.11.2007, 16:44

Вот блин
Положил zip

Присоединённый файл ( Кол-во скачиваний: 5 )
 dbf.zip 4,47 Kb

tatan, 
Так, на вскидку :
1. if не надо закрывать точкой с запятой.
2. Определение класса должно быть в хэйдере.

Лучше сделать "inline" (в каждую строчку, в начало). И тоже последние ";" не нужны.
3. for тоже не надо ";" в конце.
4. Рекомендую { ставить в той же строчке, что и оператор.
5. Все переменные  должны быть в начале функции.
Вроде всё 

unrar есть 


С-стиль, весьма спорно.

Изварт чистейшей воды.
Проще так (на коленке):


Добавлено через 48 секунд
JackYF, 
Ничего спорного. Спросили как надо, я ответил  

Добавлено через 1 минуту и 15 секунд
JackYF, 
Унрар есть, я в курсе.

to GrayCardinal
 Все принято, большое спасибо
Ну кроме про "{", но это кажется к области религиозных войн )

с sprintf - о как, не придумал бы сам-то, согласен у меня изврат, я долго думал как записать строку формата

Далее. Указатели, перед тем как их удалять лучше проверять на NULL. И соответственно, после удаления присваивать NULL - для гарантии что не удалишь два раза один и тот же указатель.

Добавлено через 1 минуту и 3 секунды
tatan, 
Завсегда пожалуйста   

Указатели кстати проверял
Но в предыдущей теме ктото сказал что проверка указателей на валидность почти ошибка в проектировании, все и убрал оставив на потом

tatan, 
Не читал тот флуд, но на нуль всегда проверяю. Так жить проще   

Добавил в список рекомендаций - после удаления указателям присваивать NULL. "Так жить проще" (с) 

А кто сказал, что так надо? 



А я рекомендую так не делать .



Ещё проще .


Добавлено через 48 секунд

Нужно:

archimed7592, 
А передёргивать не надо   

Добавлено через 46 секунд

Ыыыы, где и чего я передёрнул? 0_о
С чем ты не согласен?

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

Проверка на 0 и проверка на валидность - разные вещи... 

Добавлено через 7 минут и 7 секунд

Нафиг нужно было заводить константы в .hpp, когда здесь проверяешь по значению?

Добавлено через 8 минут и 59 секунд
Ааа, и ещё: С++ - не Дельфи... В С++ можно реализовывать разные ф-ции в разных файлах, т.е., можно было бы хотя бы все определения dbfTable::* вынести в отдельный файл, а ещё лучше разбить его потом на несколько файлов(разделив связанные по смыслу ф-ции).

delete для нулевого указателя - вполне корректная операция

И правда... Только вот с каких пор ? Точно помню что сегфолты ловил на таком   

С оч древних - ещё в first edition(2003) было. Не знаю, как в ANSI-96(или какого он там года?).

archimed7592, 
maxim1000, 
А я долго не парился на эту тему 


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

Так недавно ?   

только, в частности, мелкософтский компилер тратит на "удаление" нулевого указателя гдето 11 тактов процессора вместо одной проверки, если напишешь сам




GrayCardinal, ты когда-нить работал с большими переменными? зачем их объявлять в начале, если они по ходу дела могут не понадобиться? только время (процессорное) потратишь... или если переменная в конструкторе делает что-то немелкое по времени (к примеру, ищет сервер)

про "Еще проще" - записал
про const - запомнил
Спасибо

Alek86, 
Если по ходу дела могут не понадобиться - лучше делать их динамическими. А если так, в центре функции, то читабельность стремится к нулю... Суть "объявления" переменных в начале - это просто меняется цифра в одной команде. А если в конструкторе что-то делается "долго", то опять таки лучше    
динамически ...  

Добавлено через 2 минуты и 50 секунд
Alek86, 
О чём спорим ?   

Это сообщение отредактировал(а) GrayCardinal - 6.11.2007, 19:35

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




чувствуется закоренелый сишник. с такими сиплюсплюсникам лучше не спорить - ато опять религ. война посреди темы разгорится 

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


опять левый вопрос

насколько позволительно с точки зрения "общепринятого стиля" инклудить cpp в другие cpp?
или 1 cpp <-> 1 h ?

Вот даже как... 0_о



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

И стражей(boost::mutex, к примеру)? Тоже динамически? А если исключение? Я вообще не помню, когда в последний раз писал delete(это я о том, что если я что-то динамически и выделяю, то есть нечто статическое(вроде shared_ptr), которое обязательно удалит это).

to archimed759:
"я бы добавил explicit к конструктору" - про explicit пока ничего не знаю.Буду читать.

про копировщик и присваивание - записал, не знаю правда как это все сделать

"char* itsTableName; // лучше использовать std::string" - здесь затупил, спасибо

"fstream *itsTableFile; // зачем создавать поток динамически? 0_о" - извращение, уже понял

"if (!itsTableFile) // не нужно ничего проверять - если new не удасться выделить память он бросит исключение" - так было в книжке, 
пока не читал про exception s, наверняка можно писать свои обработчики исключений, но это впереди

"Нафиг нужно было заводить константы в .hpp, когда здесь проверяешь по значению?" - един-е объяснение - затупил

to GrayCardinal:

"А я долго не парился на эту тему smile" - пока эта конструкция с define не очень понятня, думаю разбирусь
Спасибо

Суть сказанного была не про исключения а про то, что new(в той форме в которой ты его написал) никогда не вернёт 0.

понял, и скорее всего в книжке было както так

та я про free как-то и не говорил
а в своём посте специально написал delete

И, тем не менее, free так же ничего не сделает в случае с нулевым указателем.

Это откуда ?

вроде Страуструп так говорил. 
Да и вообще прописная истина...

zkv, 
Вот
 это для меня прописные истины  

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

учитывая что в ссылке обсуждается Си, а мы говорим о С++, аргумент не очень убедителен. 
  

zkv, 
Уел таки 

Мейрс.

archimed7592, 
Может линк есть ? А то как-то неубедительно   

35 правил, оч известная книга.

Добавлено через 38 секунд
Номер главы не скажу, ибо сейчас у меня её под рукой нет.

archimed7592, 
zkv, 
можно подробнее об этом
я ничего такого не читал
единственное для меня объяснение - это кэширование, т. е чем дальше определение переменной от точки использования, тем больше вероятность того, что данные, которые соответствуют переменной, не будут находится в кэше CPU

Это сообщение отредактировал(а) MAKCim - 7.11.2007, 11:44

MAKCim, преждевременная оптимизация - корень всех зол .
Кэш тут не при чём.
Во-первых, сразу видно предназначение переменной, когда читаешь. Во-вторых, сужается её scope. В-третьих, раз уж мы заговорили про оптимизацию - компилятор всё равно выделит место в стеке под все нужные переменные в начале ф-ции, но, ему будет проще оптимизировать, когда он будет знать, что данная переменная фигурирует здесь(в данном scope) и не фигурирует нигде больше.

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

Вот скажи, а ядро Линуха до сих пор на си пишется? Там, типа, ООП не нужно?
Совершенно без иронии, просто интересно. А ссылка с этими истинами, у меня не открывается что-то...

как это соотносится с этим

?
EBP не меняется в пределах функции, так что, имхо, все равно, откуда обращаться к локальной переменной

аналогия с глобальными переменными не уместна, имхо
тогда уж и "разбрасывание" переменных по всему телу функции надо исключать

немного все же причем  

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

пишется на С
ООП - это синтаксический сахар в синтаксисе ЯВУ
в общем случае он усложняет выходной код (соответственно, снижая его производительность), что неприемлемо для разработки ядра
классы вполне заменяются структурами, методы - функциями, наследование - агрегированием, полиморфизм - ничем в виду его ненужности

К примеру, если scope ограничен, он может вообще воспользоваться регистрами.

Потом возьми умные объекты. mutex к примеру. Если ты сделаешь его в начале ф-ции, то всё время работы ф-ции мьютекс будет залочен, если же заключить его в тот scope в котором он реально нужен, то повысится эффективность.

мы говорим о расположении локальных переменных
а лочить можно где угодно

55 
Если точнее: Эффективное использование C++. 55 верных советов улучшить структуру и код ваших программ
Правило 26: Откладывайте определение переменных насколько возможно.

Есть ещё в "Стандарты программирования на C++. 101 правило и рекомендация" (Герб Саттер, Андрей Александреску)
18. Объявляйте переменные как можно локальнее.

первый раз все равно идет чтение в регистр
и неважно, где расположена при этом переменная

55 я начал читать, но когда понял, что это то же самое что и 35 читать стало лень(а в магазине сказали "они дополняют друг друга") .


MAKCim, в принципе ты можешь писать в стиле Си . У меня сейчас не соображает голова чтобы дать тебе весомые аргументы, что писать нужно иначе... Возьми что ли Мейрса с Александреску у кого-нибудь, пролистай указаные правила.

archimed7592, 

спасибо   
на самом деле я просто хочу разобраться

эх, если бы кто-нибудь здесь цитату привел
а то искать лень   

SaDFromSpb, 
ООП ? Да там проблемы какие-то с распределением памяти были... Да и на самом деле - не нужно оно для ядра...

Аргументов 2:
1) производительность - в случае неиспользования переменных не должны зря вызываться конструкторы и деструкторы,
2) читабельность/самодокументируемость кода выше, когда переменная объявлена ближе к месту использования и инициализируется в месте объявления (хорошо видно, когда и для чего нужна переменная).


Это сообщение отредактировал(а) UnrealMan - 7.11.2007, 14:24

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

Жалко, что мы отвлеклись. и если позволите еще важный вопрос, скоре всего из разряда RTFM но не получается у меня.

Вынес описание класса в файл dbft.hpp, реализацию в файл dbft.cpp, создал проект с main() в файле dbfex.cpp.
В файле dbft.cpp сделал #include "dbft.hpp", в файле dbfex.cpp  - тоже.
При компиляции получаю ошибку "In file included from dbfex.cpp" на строке #include "dbft.hpp" в файле dbft.cpp
То есть видимо ругается что 2 раза включен
Как надо правильно сделать?  

что то пока я не заметил ни одного плюса у предварительного объявления переменных

защитить хедер от двойного подключения, 
добавь первой строкой 


либо обрами весь код в хедере таким макросом:


Это сообщение отредактировал(а) zkv - 7.11.2007, 16:08

Пробовал оба варианта
Нет, наверное ругается по другому поводу
ошибки в dbft.hpp дальше описываются - типа fstream does not name a type, и тд
 я правильно сделал включив в файл dbft.hpp  строки ?

#include <cstdlib>
#include <iostream>
#include <fstream>
#include <vector>
#include <string>
#include <sstream> 

Без них собствено те же ошибки
Блин

Добавлено через 11 минут и 15 секунд
Ура, заработало!
инклюдить  надо после using namespace std а то компилер ничего не находит
Всем спасибо

лучше не использовать - плохой тон

из дежавю копировал, поэтому на форматирование не жаловаться 

Использовать EBP в качестве того, для чего он предназначен изначально — расточительство.
Visual Studio 6, к примеру (Release), использует EBP как регистр общего назначения.
Переменные адресуются по ESP (да, это сложнее, на то он и компилятор, чтобы справиться, он и справляется).
Подозреваю, что и другие компиляторы не разбрасываются регистрами.

использование ESP, +1 байт к каждой инструкции
расточительно, однако   (учитывая, что локальных переменных обычно много)
тут надо соблюдать равновесие между оптимизацией по скорости и размеру

Добавлено через 3 минуты и 29 секунд
zkv, 
спасибо за ссылку