www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: C tips (again)

reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 (untested)
 struct Mystring {
      size_t size, capacity;
      char* pdata() { return cast(char*) (&this + 1); }
      char[] data() { return pdata()[0 .. size]; }
 }



It looks quite more complex than the C code (but Denis Koroskin has found a
simple solution).



but really it's more of a proof that with ingenuity and discipline a bear can
be made to dance.<



Bears can do many things that most humans can't, like telling apart two
homozygote twins from scent alone :-)



I don't see how that stuff could help D any more than a coconut and two straws
could help a radar receiver.<



From reading the document, and from some experience in programming D1, I think
there are some missing things in D:

1) Something like the run-time "throws" of my dlibs, that given a list of one
or more exceptions, and an expression, run-time asserts they the expression
throws one of those exceptions. Othrwise prints the line where the Throws is
(and not another line).
This is very useful for unittests.
At the moment I use:
assert(Throws!(exceptions list...)(exp));
that is bad looking and nonstandard.


2) A compile-time "static throws". That asserts that a compile-time expression
asserts, otherwise prints the line number where the "static throws" is.
This is very useful for unittests of compile-time things, to assert they fail
when they must fail.
Time ago someone here has shown me a trick to do this (using is()).

I'll ask again for such two things in the future, because they are basic, it's
not easy to do .

~~~~~~~~~

More ideas from those ctips:

The following idioms may be useful as an optional built-in idiom in D programs,
to improve debugging:
http://users.bestweb.net/~ctips/tip015.html
http://users.bestweb.net/~ctips/tip022.html
http://users.bestweb.net/~ctips/tip024.html
http://users.bestweb.net/~ctips/tip026.html
http://users.bestweb.net/~ctips/tip027.html
http://users.bestweb.net/~ctips/tip028.html
http://users.bestweb.net/~ctips/tip032.html

Disallowing undefined situations from D is good, like disallowing lines of code
with certain undefined side effects (another possible solution is to do as
Java, and make them defined):
http://users.bestweb.net/~ctips/tip037.html

Collection of allocation statistics can be quite useful:
http://users.bestweb.net/~ctips/tip044.html

Built-in leak detection and tracing, this is primitive (but better than
nothing). Better ideas can be used:
http://users.bestweb.net/~ctips/tip045.html
http://users.bestweb.net/~ctips/tip019.html
http://users.bestweb.net/~ctips/tip020.html
http://users.bestweb.net/~ctips/tip062.html



I have been mightily disappointed (essentially my respect for the author has
crashed into the ground) when I saw that the entire optimization example,
although clearly a lot of time and effort has been put into it, had absolutely
no numbers whatsoever.<



Even if you haven't appreciated a detail, you can ignore all the other good
things of those ctips.

---------------------

Denis Koroskin:


 Mystring s = ...;
 char c = s.data.ptr[42];



Thank you, I can use this one.

Bye,
bearophile
May 02 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 The following idioms may be useful as an optional built-in idiom in D
 programs, to improve debugging: 
 http://users.bestweb.net/~ctips/tip015.html



I clicked on that one at random. I think this is much less of an issue
with D than with C, because C's memory corruption problems are nearly
entirely related to its reliance on pointers and manual memory management.
May 02 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


I clicked on that one at random. I think this is much less of an issue with D
than with C, because C's memory corruption problems are nearly entirely related
to its reliance on pointers and manual memory management.<



This is true, most of D code just doesn't use so much pointers, etc. So those
problems are much less common. On the other hand, I have used D to implement
some data structures, and in such situations I often have to use pointers, etc.

Regarding the "manual memory management", most of the times you can just ignore
the issue, and rely on the GC. But when I want to design an efficient data
structure in D, I must deal with the GC, and this is usually more complex/messy
than implementing the same code in C.

Anyway, you have much more experience than me in C programming. So if you think
those things of ctips aren't much useful in D, then I have to trust you... :-)

Bye,
bearophile
May 02 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:

 bearophile wrote:

 The following idioms may be useful as an optional built-in idiom in D
 programs, to improve debugging: 
 http://users.bestweb.net/~ctips/tip015.html



 I clicked on that one at random. I think this is much less of an issue
 with D than with C, because C's memory corruption problems are nearly
 entirely related to its reliance on pointers and manual memory management.



I think a lot of the memory corruption problems with C can also be 
attributed to it "standardizing" on delimited strings as well.  I find 
this aspect of C more frustrating than any other, as it's fundamentally 
opposed to how I tend to write code (ie. slice-oriented).
May 02 2009