Re: [ePiX-devel] Re: Stable release (Version 1.2.0)

[Maik Beckmann]

Am Mittwoch, 26. September 2007 19:19:07 schrieb Andrew D. Hwang:

> > I'm afraid it isn't valid, consider:
> >
> > void foo(P const& p1, P const& p2)
> > {
> >   P mid = 0.5*(p1 + p2);
> >  // where + has the signature
> >  // P operator+(P lhs, P const& rhs);
> > }
> >
> > This dosn't work, since p1 is const and you can't pass a const object as
> > no-const (the opposite: passing a non-const as const works).
>
> Ah, I didn't know a const cannot be passed by (non-const) value, and
> neither of my compilers (both 3.3 and 4.0) complain with your code. I'll
> change the P and pair operators back to their old implementations.

Oh, I made a mistake.  

 void foo(P const& p1, P const& p2)
{
 P mid = 0.5*(p1 + p2);
 // where + has the signature
 // P operator+(P lhs, P const& rhs);
}

should work, since the first + argument comes by value. I don't know  why the 
compiler complained about that it cannot find a matching opererator+ 
signature.  

What I had in mind when I complained was:

 void foo(P const& p1, P const& p2)
{
 P mid = 0.5*(p1 + p2);
 // where + has the signature
 // P operator+(P& lhs, P const& rhs); 
}

which really doesn't (first + argument is passes by reference ).

Sorry for the noise.  If you don't want to change the current version, I will 
have to bring my problem down to a minimal test case.

> > PS: Can you add a hatching example? It doesn't work for me so far.
>
> Hatching is used only to get solid filling in eepic; it's not really meant
> to be used as a fill style with visibly-separated hatch lines.
>
> Here are some factors I considered regarding hatch filling:
>
> * According to Tufte, hatch styles are difficult to distinguish, and can
>    lead to Moire patterns and eye fatigue if over-used. Solid colors are
>    preferable.
>
> * It's easier to omit features than include them. :)
>
> * Each output feature must be implemented either generically (the same
>    code for all formats, like labels) or format-specifically (solid filled
>    regions), balancing consistency of output against the efficiency of
>    using special output capabilities.
>
>    In the interests of simplicity, I reduced output to a small set of
>    abstract operations: draw a label at specified location, draw a line
>    between arbitrary endpoints, solid-fill a region. As many operations as
>    possible are generic.
>
>    Hatch filling would have added substantial complications (or substantial
>    inefficiencies) to the design. Similar remarks hold for gradient fills.
>
> * Solid colors cannot handle overlapping regions, while hatching can.
>    Transparency should remedy this defect, though, and will presumably
>    become better supported as time passes. I don't have a recent enough
>    Ghostscript to produce transparency, but if I understood the tikz
>    manual, transparency should be supported in tikz.
>
> On the balance, I decided to omit hatch filling (and gradient fills).
>
> Generic hatch filling could be added pretty easily (if inefficiently), but
> if so I'd rather make it an external module than part of the core library.
>
Makes sense. I worked on a 3D version of hatching, but it's tricky to define 
the hatching direction in space.

Maik