Всем привет!
Недавно при переезде на VC2005 переписал свою матлибу, и у меня перестали линковатся все свободные функции (методы классов линковались нормально). Я перенёс свободные функции как статические в класс-утилиту, теперь в Debug всё линкуется без проблем, а в Release всё равно ругается на MathUtils::Cross, и MathUtils::Dot, хотя методы других классов линкуются нормально.
Не знаю что и предположить уже

http://www.gamedev.ru/download/?id=6098

Здравствуйте, Phoenics, Вы писали:

P>http://www.gamedev.ru/download/?id=6098

Забыл пояснить, что по ссылке расположен архив с библиотекой.

Так же было бы интеерсно услышать Ваше мнение по поводу того что можно улучшить в стиле.

Здравствуйте, Phoenics, Вы писали:

P>Всем привет!
P>Недавно при переезде на VC2005 переписал свою матлибу, и у меня перестали линковатся все свободные функции (методы классов линковались нормально). Я перенёс свободные функции как статические в класс-утилиту, теперь в Debug всё линкуется без проблем, а в Release всё равно ругается на MathUtils::Cross, и MathUtils::Dot, хотя методы других классов линкуются нормально.
P>Не знаю что и предположить уже

P>http://www.gamedev.ru/download/?id=6098

Скачал. Избавился от Source Control. При компиляции

Error 3 fatal error C1083: Cannot open include file: 'phMathLib.h': No such file or directory d:\phMath\phMath\phMath.lib\phVectors.cpp 15

Перенес 'phMathLib.h' в каталог, где все cpp, после чего все нормально компилируется и собирается и в Debug и в Release

1>------ Rebuild All started: Project: phMath.lib, Configuration: Release Win32 ------
1>Deleting intermediate and output files for project 'phMath.lib', configuration 'Release|Win32'
1>Compiling...
1>cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler
1>phLines.cpp
1>phVectors.cpp
1>phQuat.cpp
1>phPoints.cpp
1>phPlanes.cpp
1>phMatrix.cpp
1>phMath_functions.cpp
1>Generating Code...
1>Creating library...
1>Build log was saved at "file://d:\phMath\phMath\phMath.lib\OBJ\BuildLog.htm"
1>phMath.lib — 0 error(s), 1 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Здравствуйте, Pavel Dvorkin, Вы писали:

Собиратся-то оно и у меня осбрается. А вот если попробовать сделать exe-шник и подключить эту либу то пойдут ошибки линковки в VC2005. Например если сделать так:

#include "phMathLib.h"

int main(int argc, char* argv[])
{
 VECTOR3D a(1.0f, 1.0f, 1.0f);
 VECTOR3D b = a + VECTOR3D(2.0f, 3.0f, 4.0f);
 VECTOR3D c = MathUtils::Cross(a,b);
 return 0;
}

то в VC2005 будет что-то в этом духе:
main.obj : error LNK2019: unresolved external symbol "public: static class VECTOR3D_TYPE const __cdecl MathUtils::Cross(class VECTOR3D_TYPE const &,class VECTOR3D_TYPE const &)" (?Cross@MathUtils@@SA?BVVECTOR3D_TYPE@@ABV2@0@Z) referenced in function _WinMain@16

А вот на операцию сложения векторов, например, он не ругается...

P>Собиратся-то оно и у меня осбрается. А вот если попробовать сделать exe-шник и подключить эту либу то пойдут ошибки линковки в VC2005. Например если сделать так:

В 2003 студии ошибок линковки кстати ненаблюдается.

2Phoenics: "Так же было бы интеерсно услышать Ваше мнение по поводу того что можно улучшить в стиле."

Подход у тебя неверный, мне кажется, а не в стилях дело.

А>Подход у тебя неверный, мне кажется, а не в стилях дело.

А можно поподробнее?

Проблему с линковкой решил, она была в настройках компиляции.
Всем спасибо за участие.

2Phoenics: Советую тебе все-таки подумать еще раз, о том что у тебя написано. Особенно для классов матриц.

2Phoenics:

Можно.
У тебя на каждый размер матрицы создается отдельный тип(класс, MATRIX4X4_TYPE, MATRIX3X3_TYPE...итд) . На практике размер матрицы может быть любым, те ты для всех возможных размеров будешь определять новый тип (MATRIX100X100_TYPE итп)?..те это моразм и противоречит хорошему принципу — "краткость сестра таланта".(и имхо вообще грамотному программирования) Вместе с этим в каждом новом классе ты опять перегружаешь одни и те же операторы тока с учетом новых размеров, те куча лишнего кода.
Второе: operator* для матрицы представляет имхо нечто ужасное — прямой подсчет элементов матрицы. Те если размер матрицы 100x100 функция перемножения
будет занимать 100 строк (и так для каждого типа, свой оператор!). Даже тяжело будет понять, как матрицы-то перемножаются, если такой "рулон" кода перед глазами возникает. Те надо писать короче (все-таки для этого придуманы циклы и другие конструкции).
Те назвать твой код библиотекой я бы не решился и вряд ли бы ей стал пользоваться.
Вот, навскидку, как это можно изменить:

class MATRIX
{
public:
MATRIX(int nrow, int ncol); //выделяет память нужно размера = sizeof(double)*nrow*ncol
MATRIX(double* p, int nr, int nc);
MATRIX(const MATRIX& mx); //констр копий, он вызыватся будет автоматически при возврате из перегруж операторов итп.
MATRIX operator*(const MATRIX& mx);
protected:
void close();
void alloc(int nbytes);
protected:
double* data;
int nrow, ncol; //число строк, столбцов
};

1. MATRIX(double* p, int nr, int nc) — инициализируем матрицу. p — массив данных, хранящий строки матрицы друг за другом, nr-число строк, число столбцов. В конструкторе вызываешь метод alloc, который выделяет для data обем памяти необходимый для матрицы. Копируешь из p в data данные.
Инициализируешь nrow и ncol. Все — один классс работает грубо говоря, с любым размером матрицы.
2. close() — метод освобождающий память, на которую указывает data. Деструктор по сути.
3. ну, и пример оператора — operator*

MATRIX MATRIX::operator*(const MATRIX& mx)
{
if(ncol != mx.nrow) return MATRIX();

Matrix dst(nrow,mx.ncol);

double* pdst = dst.buf;
double* pmx = mx.buf;
double* pbuf = buf;

int r,c,i;
for(r=0; r<nrow; r++)
{
pbuf = buf + r*ncol;
for(c=0; c<mx.ncol; c++)
{
for(i=0; i<mx.nrow; i++) *pdst += pbuf[i] * pmx[i*mx.ncol];
pmx++;
pdst++;
}
pmx = mx.buf;
}
return dst;
}

Где-то так. Можно наварачивать дальше — сделать ввиде шаблона для разных типов итп.

2Phoenics: Я еще не использую такую кучу комментариев — ребит в глазах, но это дело каждого, конечно. О стилях можно спорить до посинения. Но ясно(краткий понятный код, хорошо подобранное имя) написаная функция без комментария, часто лучше непонятной, но с комментарием.

Здравствуйте, Аноним, Вы писали:

Всё дело в том что данная библиотека написана для игрового движка и работы в 3D графикой. Соотвественно матрицы размером 4х4 и 3х3 являются наиболее часто употребляемыми, а операции их перемножения (если не считать операции с векторами) наиболее часто используемыми. Сотвесттвенно операции для пеермножения этих матриц написаны таким образом что бы максимально отвечать требованиям производительности (в прошлой версии библиотеки данные операции были реализованы через циклы и показали неудовлетворительную производительность ). Матрицы же других размеров в работе с 3д графикой не встречаются (матрица размера 1х2 реализована для решения системы линуравнений).