> Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> is to catch at compilation code that is logically invalid, if you have
> f(ByteCount, LineCount), you cannot call it with a (LineCount, ByteCount)
> signature. In C you would be forced to use f(int, int), and long debugging
> sessions to discover this simple mistake.
Can you explain me why in C you have to represent them as int or long as
not with a structure like you did in c++?.
> It just gives you tool so that you can write your code closed to the domain
> language, did you learn linear algebra writing matrix_add(m1, m2, &m3)
> ? or m3 = m1 + m2 ?
It is only useful in some algebra cases where usually is better
incorporate them into the language instead of this user overloading.
Can you explaing me what is the meaning of '+' when you have for example
two lines? the addition one by one of each element or the concatenation
of them?.
> > I don't need this damaged brain pointers, again if you have this kind
> > of problems you should learn a bit more. Like a friend of mine says,
> > code in C is like sex, you have to know what you are doing.
>
> You probably never worked on complicated enough code bases if you believe every
> program fits entirely in your brain. Putting safe guards in you code asserting
> that what you believe is correct actually is is necessary if you want to keep
> your sanity.
I have worked in complex code bases written in C++, where the use of C++
did that was impossible to keep them in the brain. In all the other
projects C and a correct division between tools make that programs can
keep in my mind. If you have pointers that are allocated in some place
and freed in another place then you code should be written in another way.
A good book for you could be 'The practice of programming'.
> what is silly is rewriting the same function with different arguments again
> and again. Or ending up relying on macros to emulate generics.
Try to don't need such kind of things. For example Go hasn't generic and
you don't need them ever. You like them because your are so used to them
that you don't see the kind of code you are forced to write with them.
> Get your complexity right, inserting in a dynamic array is O(n), the eventual
> need for an allocation is amortized (whereas you always end up doing a malloc
> for your linked lists). Another thing you should look up is modern cpu
No. Because the realloc that you have to do maybe has to move in the
worst case n-1 elements in a new memory arena. So you have n (moving
to the position) * n-1 (memcpy to new position in memory) = n^2. You
can decrease the possibility of reallocation allocating
more memory of needed, but when you have the reallocation you get
the O(n^2). In a list you don't have ever a reallocation.
> architectures and caches, in practice the much better locality of reference
> of arrays makes them *way* better on operation like insert/erase in the middle
> than lists even though complexity theory says otherwise. (Remember, complexities
> are asymptotic, you need huuuuuge number of elements).
If you read what I have said, iy you insert in the HEAD, and always take
the HEAD (FIFO fashion), you don't get any problem of locality, because
you directly access (or remove) the element you need. And now that you
are talking about deletion in dinamyc arrays, can you explain me how do you
delete in the middle of them?. AFAIK there are only two ways:
- moving one position left all the elements, that make that you
have to copy all the elements of the array, that is slow and
and destroy any locality.
- allowing holes in the array, that makes you have a bigger array
due to the holes, and to the field to mark the elements as deleted.
and I don't want to talk about the problems of inserting a new
element (in the holes or at the end?).
If you have a lot of insertions/deletions in the middle dinamyc arrays are
a very bad idea. They are only good if you always insert/remove at the end.
I usually build list inside of static arrays something like:
struct element {
/*
* element fields ...
*/
struct element *list1;
struct element *list2;
/*
* list pointers ...
*/
} list[200];
Can you explain me where is the locality problem here?. If you want to run
over the array you can, and if you want to generate lists using some other
order then you run in the order you want. With a dynamic array you only
can have one order, and if you need some other order you need an additional
structure that is a list, where you only can store the index of the array,
because, oh man reallocation of arrays change the address of the elements!!!!.
List are good for accessing one element in the order you want. Arrays
are good for accessing all the elements always in the same order.
Regards,
--
Roberto E. Vargas Caballero
Received on Tue Sep 16 2014 - 23:20:45 CEST