matrix.c, matrix.h refactored

[GoogleCodeExporter]

Hi.

Below is a patch for matrix.c and matrix.h of SVN ver 20, I cleaned up a
few things. It was tested and ran fine.

Original issue reported on code.google.com by vanhtu1...@gmail.com on 22 Jan 2008 at 8:14

Attachments:

• main_c_ver_20.diff
• matrix_c_ver_20.diff
• matrix_h_ver_20.diff

[GoogleCodeExporter]

Thanks vanhtu. I will review your code tomorrow. Can I mail you my comments?

Thanks for your work!!!

Original comment by pere.ne...@gmail.com on 22 Jan 2008 at 9:20

[GoogleCodeExporter]

Here is the patch for Makefile. It doesn't do anything special, just a bit more
flexible. I'll convert it to autoconf until after the code is stabilized a bit 
:) .

Original comment by vanhtu1...@gmail.com on 22 Jan 2008 at 11:14

Attachments:

• Makefile_ver_20.diff

[GoogleCodeExporter]

I've updated main.c, matrix.c and matrix.h for some memory leaks. Can you 
consider
moving it to C++?.

The refactoring is now completed.

These diffs should be applied to SVN ver 20.

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 3:17

Attachments:

• main_c_ver_20_1.diff
• matrix_c_ver_20_1.diff
• matrix_h_ver_20_1.diff
• TODO

[GoogleCodeExporter]

Hi Vanhtu.

I've applied your patches. What distribution are you using? I'm getting errors. 
Check
the log below.

Certainly, there are things to improve. But I tried in my code to use as much
pointers as possible. I think is cleaner. Example:

  matrix_t *n = MatrixNew(8,8);
  MatrixSetElement(n,...)
  ...
  MatrixFree(n);

With your code, this becomes:

  matrix_t n = MatrixNew(8,8);
  MatrixSetElement(&n,...)
  ...
  MatrixFree(&n);

It's really the same (just that you have to remember to pass the var's ADDRESS).

If there are memory leaks in my code, I would like to know where they are (in
matrix.c). I think that code is allright (I don't mean that I don't accept 
patches or
improvements). For example, code that checks that all the matrices are NxN in
operations like determinant, inverse, multiply... these are reasonable 
additions.

And I would like to keep it in C. I think it's small enough. We don't really 
need
objects here.

Original comment by pere.ne...@gmail.com on 23 Jan 2008 at 3:00

Attachments:

• make.log

[GoogleCodeExporter]

I'm using Ubuntu Gutsy. It said that 'Package xtst was not found in the 
pkg-config
search path.' . What distro are you using?. If you've installed libxtst-dev, it
should put the corresponding CFLAGS and LIBS declarations within pkg-config 
database.

The reason I want to move to C++ is to take full advantage of RAII, so memory 
leak
will not be a problem. Arithmetic function overloading, parameters as 
references and
strict casting would also help making the code cleaner.

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 3:39

[GoogleCodeExporter]

About the thing with pointers. Yeah, I was being silly :) . If it was in C++, I 
could
use std::vector, in which case, it is still not necessary to make Matrix a 
class and
we'd be free of matrixFree() :) as a bonus.

It works, but there is a performance problem:
matrix_t old = matrixNew(8,8);
matrix_t new = old;

Because std::vector objects get copied in that case, we can use std::auto_ptr 
as an
optimization. Using vectors also eliminates the need for matrixCopy and the 
like.
With C++, the source can be reduced as much as half, IMO.

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 3:48

[GoogleCodeExporter]

Sorry for spamming, I'm refactoring main.c but slowly. I want to get your 
opinion.
Coming from the LISP foundation, I do want beautiful and concise code, please 
bear
with me :) .

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 3:51

[GoogleCodeExporter]

valgrind didn't show any memory leak with your code (except with SDL and 
libcwiid
themselves, weird) with SVN ver 20, I must've imagined it.
Still, I'd feel initializing the memory in one place and expecting caller to 
free it
would lead to trouble as the code gets complicated.

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 4:22

[GoogleCodeExporter]

I know what you mean.

I feel comfortable using C, maybe for its minimalism. C do not do any garbage
collection of any kind, nor warns you when you are casting incompatible types. 
I do
not see this as a problem: In my view, C trusts the programmer and permits some
clever and handy tricks.

I know that there are many programmers that feel like you: they learnt with 
objects
(java, c++, etc...) and for them are a natural thing. One (arguable) argument 
against
objects is their perfomance penalty, but I prefer classic modular programming 
when
possible.

I must admit that for medium or large projects, the features of C++ and Java 
come in
handy to organize the code. For small programs like this one, I don't really 
see the
necessity of C++. 

Original comment by pere.ne...@gmail.com on 23 Jan 2008 at 6:44

[GoogleCodeExporter]

I grew up with C and assembly so I'm used to the frustrating experience of 
debugging
a complicated piece of code. We'd better code properly before it really gets 
out of
hand IMO.

I usually code the low-level libraries in C. E.g.: things that deal with SDL
(un)initialization, system routines and low-level widget toolkits like GTK+; in 
this
case: the functions that deal with libcwiid. Then I use them in higher-level
languages like C++.

Using C++ does not mean dealing with classes and stuff: I actually refrain from
having to create a class as much as possible to keep portability, just in case 
it
needs to be ported to C. Examples of other neat features in C++ were listed 
above,
these were a portion of what I'd like to use.

I've cleaned up lots of global vars (ah, the memory) in main.c . I'll submit a 
patch
soon.

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 7:03

[GoogleCodeExporter]

Oh and, performance is not a problem :) premature optimizations is the root of 
all
evil. The code currently runs blazingly fast (if not for the polling stuff, but 
I'm
gonna think of a workaround); in real cases, you need to profile it to find the 
actal
bottleneck.

What _really_ matters is the clarity of the code, so following developers like 
me can
grasp it and continue in no time. At the moment I'm still fighting with those 
global
vars (2 left), who is responsible to modify what and stuff.

Original comment by vanhtu1...@gmail.com on 23 Jan 2008 at 7:14

[GoogleCodeExporter]

Original comment by vanhtu1...@gmail.com on 31 Jan 2008 at 10:58

• Changed state: Verified
• Added labels: Type-Patch
• Removed labels: Type-Defect