Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > C/C++ программирование > Общие вопросы C/C++
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 06.07.2012, 12:55   #1
pufystyj
Форумчанин
 
Аватар для pufystyj
 
Регистрация: 10.11.2010
Сообщений: 585
По умолчанию Странная ошибка

В этом коде
Код:
//====ObjModel.h===
//...
static void declaration();

static bool read(FILE *f, char* string);

static bool qualyty();
//...
В строке
Код:
static bool read(FILE *f, char* string);
пишет ошибку:
Цитата:
E:\RandomEngine\ObjModel.h|128|erro r: expected ')' before '*' token|
А вот код ObjModel.c
Код:
//===ObjModel.c===

//...


    TextureVertex = (objTVertex *) malloc(sizeof(objTVertex) * q_Vertex);

    Normal = (objNormal *) malloc(sizeof(objNormal) * q_Vertex);
}

static bool read(FILE *f, char *string)
{
    int i;

    for(i = 0;; i++)
    {
        if((string[i] = getc(f)) == EOF)
        {
            return false;
        }
        else if(string[i] == '\n')
            break;
    }

    string[i] = '\0';

    return true;
}

static bool LoadMTL()
{
    FILE *f = fopen(mtllib, "r");

    if(!f)  return false;

    char* string = (char *) malloc(sizeof(char *) * 256);

    NumberMTL = -1;

//...
Что странно, если я в ObjModel.h удаляю
Код:
static bool read(FILE *f, char* string);
ошибка пропадает, если в *.h- файле удаляю и ставлю это в начале *.c - файла ошибки нет, а именно в *.h ошибка есть. Что делать? как исправить?
Компилятор у меня MinGW, вроде работает нормально, переставлял, качал с офф сайта вместе с Code Blocks.
Зарание спасибо.
Это ещё не конец и даже не начало конца, это возможно только конец начала.
pufystyj вне форума Ответить с цитированием
Старый 06.07.2012, 15:18   #2
pufystyj
Форумчанин
 
Аватар для pufystyj
 
Регистрация: 10.11.2010
Сообщений: 585
По умолчанию

Народ Ваше станнющая ошибка и она меня задолбывает помогите, как сможете...
Это ещё не конец и даже не начало конца, это возможно только конец начала.
pufystyj вне форума Ответить с цитированием
Старый 06.07.2012, 18:50   #3
Пепел Феникса
Старожил
 
Аватар для Пепел Феникса
 
Регистрация: 28.01.2009
Сообщений: 21,000
По умолчанию

вероятно там две ошибки, во второй компиль пишет что не знает что такое FILE?
stdio подключен?
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел.
Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите.
Пепел Феникса вне форума Ответить с цитированием
Старый 06.07.2012, 23:39   #4
_Bers
Старожил
 
Регистрация: 16.12.2011
Сообщений: 2,329
По умолчанию

static bool read(FILE *f, char* string);

1. Проверить, что известен тип FILE
2. Проверить, что отсутствует коллизия имени переменной string, с типом шаблонного класа std::string

3. Давать имена переменным, аналогичные именам классов/шаблонов - не самая удачная идея. Последствия могут быть печальными. Лично я называю такой стиль "говнокодом".
_Bers вне форума Ответить с цитированием
Старый 07.07.2012, 00:09   #5
netrino
Участник клуба
 
Аватар для netrino
 
Регистрация: 15.07.2008
Сообщений: 1,933
По умолчанию

Странная ошибка, но что ещё страннее, так это объявление static-функций в .h файле. Уберите декларацию static-функций из .h.
2Bers, это же C, а не C++, в нём нет типа/класса string.
netrino вне форума Ответить с цитированием
Старый 07.07.2012, 01:26   #6
_Bers
Старожил
 
Регистрация: 16.12.2011
Сообщений: 2,329
По умолчанию

Цитата:
Сообщение от netrino Посмотреть сообщение
Странная ошибка, но что ещё страннее, так это объявление static-функций в .h файле. Уберите декларацию static-функций из .h.
2Bers, это же C, а не C++, в нём нет типа/класса string.
Потом этот сишный код кто нибудь захочет вставить в с++ проект. И отгребет.


Почему бы сразу не писать код, который можно портировать и бла бла бла?
_Bers вне форума Ответить с цитированием
Старый 07.07.2012, 01:57   #7
netrino
Участник клуба
 
Аватар для netrino
 
Регистрация: 15.07.2008
Сообщений: 1,933
По умолчанию

Имена в разных областях видимости не конфликтуют, так что функция может иметь переменные типа string, когда на уровне файла объявлен тип string. Для остального в C++ есть namespace. Единственно, в чём согласен, так это что лучше не именовать символы в C ключевыми словами из C++ (например this или class).
netrino вне форума Ответить с цитированием
Старый 07.07.2012, 02:47   #8
_Bers
Старожил
 
Регистрация: 16.12.2011
Сообщений: 2,329
По умолчанию

Цитата:
Сообщение от netrino Посмотреть сообщение
Имена в разных областях видимости не конфликтуют, так что функция может иметь переменные типа string, когда на уровне файла объявлен тип string. Для остального в C++ есть namespace. Единственно, в чём согласен, так это что лучше не именовать символы в C ключевыми словами из C++ (например this или class).
1. Это как минимум вводит в заблуждение плюсовиков. Минус к читабельности, минус к сопровождению. Итого: убытки компании на правки глупых ошибок, которых с легкостью можно было бы избежать в принципе.

2. Это может привести к конфликтам имен.
В частности, запись:
Код:
using namespace std;
Распространенное явление, официально разрешена многими нотациями.
А по некоторым нотациям и вовсе - присутствует по дефолту.

Давать имена переменным такие же, как и типы стандартной библиотеки - убийственно для с++ проектов.

Один парень сделал собственный my::string, наивно полагая, что раз он вынес его в собственный спейс, то и проблем не будет. Ага, щас!

Его товарищи по ремеслу затею не особо оценили, когда им пришлось разгребать ошибки из цикла "однако, странные вещи творяццо с кодом"
_Bers вне форума Ответить с цитированием
Старый 07.07.2012, 02:59   #9
netrino
Участник клуба
 
Аватар для netrino
 
Регистрация: 15.07.2008
Сообщений: 1,933
По умолчанию

Плюсовики написали 100500 библиотек со всеми именами, которые можно придумать как для переменных так и для функций, что делать-то? Имена вроде a_c_function_<имя>? Чтобы не вводить никого в заблуждение.

Если более-менее грамотно пользоваться пространствами имён и не вставлять using namespace ***; в .h файлы, то большинства конфликтов можно избежать. В крайнем случае использовать полное имя конфликтующих символов.

Да и кроме того, что страшного, что где-то в каком-то сишном файле (или хэдере) будет имя переменной такое же, как и у типа из стандартной библиотеки C++? Ведь в всё равно, как я говорил выше, никаких конфликтов не будет. Немного осторожней нужно с функциями, но и там особых проблем наблюдаться не должно.
netrino вне форума Ответить с цитированием
Старый 07.07.2012, 03:12   #10
_Bers
Старожил
 
Регистрация: 16.12.2011
Сообщений: 2,329
По умолчанию

Цитата:
Сообщение от netrino Посмотреть сообщение
Плюсовики написали 100500 библиотек со всеми именами, которые можно придумать как для переменных так и для функций, что делать-то? Имена вроде a_c_function_<имя>? Чтобы не вводить никого в заблуждение.
Не использовать имена стандартной библиотеки.
100500 существует "где то там", стандартная библиотека существует здесь и сейчас.

Цитата:
Сообщение от netrino Посмотреть сообщение
Если более-менее грамотно пользоваться пространствами имён и не вставлять using namespace ***; в .h файлы, то большинства конфликтов можно избежать. В крайнем случае использовать полное имя конфликтующих символов.
Да. Можно избежать. Но это - плохая идея. Хорошая идея заключается в том, что бы не приходилось апосля "чего то избегать".

Для этого достаточно придерживаться правила: имена std уникальны.
Плюс к юзабилити стандартной библиотекой.
Минус - целый класс ошибок.

Цитата:
Сообщение от netrino Посмотреть сообщение
Да и кроме того, что страшного, что где-то в каком-то сишном файле (или хэдере) будет имя переменной такое же, как и у типа из стандартной библиотеки C++? Ведь в всё равно, как я говорил выше, никаких конфликтов не будет. Немного осторожней нужно с функциями, но и там особых проблем наблюдаться не должно.
- минус к читабельности
- минус к сопровождению
+ больше осторожности

= убытки компании

Зачем самому себе создавать проблемы на пустом месте? Если их можно избежать не прилагая никаких особых усилий?

Плохая идея: когда читающему код приходится ломать голову: чем на самом деле является string ?

Хорошая идея: читатель кода воспринимает сущность string однозначно. И не тратит время на головомойку.
_Bers вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
странная ошибка xsepox Общие вопросы Delphi 10 14.05.2012 02:03
странная ошибка Психвоплоти Помощь студентам 0 23.02.2011 15:01
Странная ошибка STIFFmaster_LP Помощь студентам 2 06.11.2009 19:11
Странная ошибка.. SnakeMan БД в Delphi 4 12.02.2009 12:43
Странная ошибка Washington БД в Delphi 2 16.03.2007 18:13