On Sun, Apr 02, 2006 at 01:14:09PM +0200, Georg Baum wrote:
> Am Samstag, 1. April 2006 21:17 schrieb Enrico Forestieri:
> > On Sat, Apr 01, 2006 at 05:55:07PM +0200, Georg Baum wrote:
> > > Almost. No boolean please (that would circumvent the whole idea of
> > > internal/external path). Simply hardcode the decision in internal_path
> > > and external_path. Later we can then think about paths visible to the
> > > user and replace some calls of external_path() by a new function
> > > display_path().
> >
> > Georg, cygwin runs on windows and it understands both posix and
> > win-style paths. So, what is external and what is internal?
> > In the win32 version C:/xxx is the internal representation, in
> > the *nix version /c/xxx is the internal representation.
> > Why one of the two cannot be chosen as internal representation
> > in cygwin (which bridges both worlds) ?
>
> I already wrote that either could be used as internal representation. My
> point is that this decision should be made at compile time, and it should
> not be configurable at runtime which representation is chosen.
I didn't mean it as a runtime switch. Anyway, this controversy
is now resolved by the observation that boost dosn't deal with
mixed styles, so posix is to be used as the internal
representation style.
> > Sincerely I cannot understand your point. If you fear that this
> > fact can bring a major burden to a programmer, well, now I have
> > spent quite some time on the subject and can tell you that it is
> > exactly the contrary, i.e., a major burden can occur if you adopt
> > a different representation for external and internal ;-)
>
> We are forced to do that on non-cygwin windows. So we have no choice but
> use external_path() and internal_path() carefully. With this prerequisite
> I see no additional burden to programmers if external_path() uses
> something different than internal_path() on cygwin.
Well, I am facing a problem related to it now. Please, help this
C++ newbie to solve the following problem.
I had already the need to add an enum argument to internal_path.
Its natural declaration was in "support/os.h" in the
lyx::support::os namespace:
enum path_target {
DEFAULT,
LATEX
}
std::string internal_path(std::string const & p,
path_target target = DEFAULT);
Now I have the need to add the same argument to ChangeExtension()
which is declared in support/filetools.h. This is because
ChangeExtension() is called either when the path is intended to
go in a .tex file or not. So I need to change the call to
ChangeExtension() in lyx::support::latex_path by adding the enum
argument with value LATEX.
How can I get a correct declaration of ChangeExtension()?
It should be:
std::string const
ChangeExtension(std::string const & oldname, std::string const & extension
path_target target = DEFAULT);
In C I would simply "#include <support/os.h>" within
"support/filetools.h", but I don't think this is the correct C++
solution.
Would
extern enum path_target {
DEFAULT,
LATEX
}
in "support/filetools.h" work?
I'll try it, but as compiling LyX with debugging information
takes forever in the final link stage on windows, I rather
would like to not have it done by trial and error ;-)
--
Enrico
