Hi!

I may answer part of my own question, but there remain unclear bits!

>>>>> On Mon, 17 May 1993 06:35:44 GMT, girod@dshp01.trs.ntc.nokia.com (Marc Girod) said:
In article <GIROD.93May17083544@dshp01.trs.ntc.nokia.com> girod@dshp01.trs.ntc.nokia.com (Marc Girod) writes:

MG> My compiler (HP /usr/bin/CC: HP C++ B2402/B2404  A.03.00) additionally
MG> wants the path to the directories of the template header files to be
MG> passed to the linker with the -I option.

MG> I wonder what is the site of interpretation of these pathes...

At the link stage, the CC front-end generates, on a template
instantiation basis, a file including the template header, the
template definition, and the file containing the declaration for the
class used as parameterizing type, if any. It then adds a typedef
declaration to formally instantiate the template. These files are
generated in a special directory, ptrepository, and then compiled (by
the linker!), so as to be linked.

I guess I grasp how it works so far. But for instance, nothing
prevents me from declaring my parameterizing type within say, my main
source file. How does then the linker get rid of the extra main
function in the compiled generated file?

The whole trick sounds actually quite perverse...

So my earlier question remains:

MG> Is this approach common among compilers (I know g++ has nothing
MG> similar)?

As far as I understand it, g++ wants the template definition to be in
the same file as the declaration, so that the templates are somehow
statically instantiated within the different compilation units...

Corrections, comments, additional information, experiences with other
compilers, insights about the forecoming standards?

Best Regards!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+

Hi!

I may answer part of my own question, but there remain unclear bits!

>>>>> On Mon, 17 May 1993 06:35:44 GMT, girod@dshp01.trs.ntc.nokia.com (Marc Girod) said:
In article <GIROD.93May17083544@dshp01.trs.ntc.nokia.com> girod@dshp01.trs.ntc.nokia.com (Marc Girod) writes:

MG> My compiler (HP /usr/bin/CC: HP C++ B2402/B2404  A.03.00) additionally
MG> wants the path to the directories of the template header files to be
MG> passed to the linker with the -I option.

MG> I wonder what is the site of interpretation of these pathes...

At the link stage, the CC front-end generates, on a template
instantiation basis, a file including the template header, the
template definition, and the file containing the declaration for the
class used as parameterizing type, if any. It then adds a typedef
declaration to formally instantiate the template. These files are
generated in a special directory, ptrepository, and then compiled (by
the linker!), so as to be linked.

I guess I grasp how it works so far. But for instance, nothing
prevents me from declaring my parameterizing type within say, my main
source file. How does then the linker get rid of the extra main
function in the compiled generated file?

The whole trick sounds actually quite perverse...

So my earlier question remains:

MG> Is this approach common among compilers (I know g++ has nothing
MG> similar)?

As far as I understand it, g++ wants the template definition to be in
the same file as the declaration, so that the templates are somehow
statically instantiated within the different compilation units...

Corrections, comments, additional information, experiences with other
compilers, insights about the forecoming standards?

Best Regards!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+

In article <GIROD.93May21093110@dshp01.trs.ntc.nokia.com>, girod@dshp01.trs.ntc.nokia.com writes:

> [discussion of ptrepository/*]
> MG> Is this approach common among compilers (I know g++ has nothing
> MG> similar)?

The Solaris 2.1 CC (CC 3.0.1) and the SGI 5.0 CC (CC 3.1) both work
this way as well.  (I have no idea whether these two CC version
numbers are to be taken as members of the same series.)  Since both of
these are based on the AT&T C++ package (cfront et al), I infer that
this is the way AT&T does it, so in turn it's probably very common.
(Not being a compiler type, I speak of the SGI compiler only as a nosy
user.)

> The whole trick sounds actually quite perverse...

Amen, bother!  But it does seem to get the job done.


Jack Repenning        M/S 1-875      jackr@wpd.sgi.com
Silicon Graphics, Inc.        x3-3027      Off:(415) 390-3027
Visual Magic Division       Fax:(415) 390-6056

In article <DAVIDM.93May8162606@prometheus.consilium.com>, davidm@consilium.com (David S. Masterson) writes:
> The standard should say what LCL and GBL are relative to (and very carefully,
> I might add).  If LCL and GBL are relative to the file doing the #include,
> then we don't need to have two types of #includes (how many people are going
> to include "foo.h" and <foo.h> in the same source file?).

It is quite common for me to have a directory with, amongst other files,
 bar.c
 foo.h
where bar.c contains #include "foo.h"
and foo.h contains #include <foo.h>
Typically, <foo.h> is a standard header file, and "foo.h" is a wrapper
that compensates for vendor botches.  If there were only one kind of
#include, it would be much harder to do this.

In article <DAVIDM.93May8162606@prometheus.consilium.com> davidm@consilium.com (David S. Masterson) writes:
|The interesting point is that, in the case where foo.h is in the GBL area,
|many vendors would say that, if it includes beta.h, the compiler will search
|only the GBL set because that's where foo.h is stored.  Whether its angle
|brackets or quotes around foo.h or beta.h doesn't make any difference.

Boy, do they really do that?  -- I'd read such an approach as being
an implementation error.  The standards don't talk about any such
dependencies of the search on the location of the files being searched
from.  Of course, I guess the implementors would argue the standards don't
prohibit such an approach either.

|The standard should say what LCL and GBL are relative to (and very carefully,
|I might add).

Agreed.  The language needs to be made much clearer.

In article <1993May10.170520.26835@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
|>
|> Boy, do they really do that?  -- I'd read such an approach as being
|> an implementation error.  The standards don't talk about any such
|> dependencies of the search on the location of the files being searched
|> from.  Of course, I guess the implementors would argue the standards don't
|> prohibit such an approach either.
|>

Yes, "they do" and they were doing it long before there was a
C standard.  The "Reiser cpp", which was for many years the
standard preprocessor on UNIX looks for a file named with double
quotes in the directory of the file where the #include appears
and then checks the directories named with -I options.

There are good reasons why this is wrong, but compiler
vendors (such as Lucid) and those who serve on standards
committee's (such as myself) don't make gratuitous changes in this
kind of thing.


   -- Jerry Schwarz

In article <1993May7.083302.12915@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
:       #include has to be the worst portability nightmare invented.

I'll have to disagree, having had to deal with far worse
nightmares.

: It would be better, perhaps, to have
:
:       include foo;

This, minus the semicolon, works in ANSI C. #define foo to be a
string. Provide it on the command line or equivalent.

: #include pathname "/file.h"

#define stringize(x) #x
#define path_plus_file(file) stringize(path##file)
#include path_plus_file(file)

Or something along those lines.

---
Bill                            { rutgers | decwrl | telesci }!twwells!bill
bill@twwells.com

In article <DAVIDM.93Apr29220413@prometheus.consilium.com>
davidm@consilium.com (David S. Masterson) writes:

|> I've recently run into an interesting revelation with how #include works.
|> According to the documentation for the C preprocessor on a couple of systems,
|> quoted include files are searched for in the following way:

|> 1. Look for the file in the directory containing the file with the #include.
|> 2. Look for the file in directories listed with -I on cc line.
|> 3. Look for the file in the standard list of directories.

|> The first one presents an interesting chicken and egg problem for my
|> development environment.  Assuming a master source directory with files having
|> the following dependencies:

|> alpha.c: alpha.h
|> alpha.h: beta.h
|> beta.h:  gamma.h

|> Then assume that I copy alpha.c and gamma.h locally to make some changes.
|> When I compile alpha.c, #1 says that the gamma.h that beta.h includes will be
|> the one in the master source directory.  Is this normal?

Yes.  All C and C++ compilers I have seen do it this way, and I
believe that the ISO standard for C specifies this behavior.  (I'm not
sure, as ISO in fact specifies very little in regards to where the
compiler looks for include files.)

|>  In my example, this
|> may not look like much of a problem, but multiply the number of files by 3
|> orders of magnitude and you begin to see the problem.

|> Is there a standard approach to doing development that avoids this problem
|> (that obviously we overrode in our VMS development with logicals)?

I've never had any problems with this.

My software (even the little things I write for myself) is divided
into components.  Each component has its own directory.  There are
three categories of include files:

1. Those from another subsystem (including system files).  These are
included using <file.h>, and are always included from a master include
directory.  There is never a local copy in the component directory, so
there is no problem here.

2. The public interface to my component.  This is normally just one
file, but could conceivably be more.  There are normally two copies of
this file, a presumably stable one in the master include directory,
one a working copy in the component directory.

This is also included using <file.h> (not "file.h").  When compiling
working (test) versions of the component, I specify -I. at the start
of the compiler command line, so the compiler will pull in the local
copy.  When releasing a component, I will copy the local version down
to the master include directory.

Other components will never see the local copy, only the "released"
version.

3. Some local include files.  These are all in the component
directory.  They are included using "file.h", and not <file.h>.

There is an absolute rule that no public interface file can ever
include a local include, since these files are only in the component
directory, and not accessible to other components.  In practice, I
have never found this to be a restriction.

This can be easily automated by using a recursive makefile (at least
under Unix, and with Zortech C++ under MS-DOS).  For example (Unix,
but it should be clear what is going on if you only know MS-DOS):

 LIB=./libX.a  #  X.lib under MS-DOS
 COPT=-g -I.  #  -g adds debug info

 CFLAGS=$(COPT) -Iglobal_incl_dir ...
 # ...
 install :
  make all COPT=-O LIB=global_lib_dir/libX.a
    #  -O optimizes

Under MS-DOS, I usually have install build the libraries for *all*
memory models, adding another make variable, MODEL.  Because of
weaknesses in the library manager, I also keep all of the objects
outside of the library, in a directory specified with OBJDIR.  (It's
hard to imagine a library manager worse than what Unix offers, but
Microsoft succeeded, and Zortech copied it.)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

I've recently run into an interesting revelation with how #include works.
According to the documentation for the C preprocessor on a couple of systems,
quoted include files are searched for in the following way:

1. Look for the file in the directory containing the file with the #include.
2. Look for the file in directories listed with -I on cc line.
3. Look for the file in the standard list of directories.

The first one presents an interesting chicken and egg problem for my
development environment.  Assuming a master source directory with files having
the following dependencies:

alpha.c: alpha.h
alpha.h: beta.h
beta.h:  gamma.h

Then assume that I copy alpha.c and gamma.h locally to make some changes.
When I compile alpha.c, #1 says that the gamma.h that beta.h includes will be
the one in the master source directory.  Is this normal?  In my example, this
may not look like much of a problem, but multiply the number of files by 3
orders of magnitude and you begin to see the problem.

Is there a standard approach to doing development that avoids this problem
(that obviously we overrode in our VMS development with logicals)?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
davidm@consilium.com    Mtn. View, CA  94043
====================================================================
"Bill Gates says no matter how much more power we can supply, he'll develop
 some really exciting software that will bring the machine to its knees."
-- Intel VP David House, In _EE_Times_, 16 October 1989

davidm@consilium.com (David S. Masterson) writes:

>I've recently run into an interesting revelation with how #include works.
>According to the documentation for the C preprocessor on a couple of systems,
>quoted include files are searched for in the following way:

>1. Look for the file in the directory containing the file with the #include.
>2. Look for the file in directories listed with -I on cc line.
>3. Look for the file in the standard list of directories.

My cpp man page says this for the -Idirectory option:

    Insert directory into  the  search  path  for  #include
    files  with names not beginning with `/'.  directory is
    inserted ahead of  the  standard  list  of  ``include''
    directories.   Thus, #include files with names enclosed
    in double-quotes (") are  searched  for  first  in  the
    directory  of  the file with the #include line, then in
    directories named with  - I  options,  and  lastly,  in
    directories from the standard list.  For #include files
    with names enclosed in angle-brackets (<>), the  direc-
    tory  of  the  file  with  the  #include  line  is  not
    searched.  See Details below for exact details of  this
    search order.

I looked for "Details below" and all I found was a reference back to
the -Idirectory option. :-(

Anyway, the steps you describe are used when the (") delimiter is used,
not when the (<>) delimiters are used.

>The first one presents an interesting chicken and egg problem for my
>development environment.  Assuming a master source directory with files having
>the following dependencies:

>alpha.c: alpha.h
>alpha.h: beta.h
>beta.h:  gamma.h

>Then assume that I copy alpha.c and gamma.h locally to make some changes.
>When I compile alpha.c, #1 says that the gamma.h that beta.h includes will be
>the one in the master source directory.  Is this normal?  In my example, this
>may not look like much of a problem, but multiply the number of files by 3
>orders of magnitude and you begin to see the problem.

Ugh.  I don't like this behavior.  I tried it and you are right.  This
doesn't seem to match my notion of how it has worked in the past.  Seems
to me that adding -Idir meant that dir would be searched first regardless
of which delimiters were used.  This would let me say "-I." to have my
local directory ALWAYS searched before the normal search commenced.  Think
I'll post in comp.std.c!

>Is there a standard approach to doing development that avoids this problem
>(that obviously we overrode in our VMS development with logicals)?

To work around your problem, all I can think of is to use the (<>) delimiters
and compile your source with options "-I. -Imaster".  I tried this too and
it seemed to pick up my local version of gamma.h.

But, as far as I'm concerned, this is not standard at all.  The (") delimiter
is a flag to my eyes which indicates a more private include file.  That
appears to be going away.  :-(

Can anyone else solve David's problem and leave the quotes in?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000      ** USE kjhopps@mmm.com FOR E-MAIL REPLIES **

In article <DAVIDM.93Apr29220413@prometheus.consilium.com> davidm@consilium.com (David S. Masterson) writes:
>I've recently run into an interesting revelation with how #include works.
>According to the documentation for the C preprocessor on a couple of systems,
>quoted include files are searched for in the following way:
>
>1. Look for the file in the directory containing the file with the #include.
>2. Look for the file in directories listed with -I on cc line.
>3. Look for the file in the standard list of directories.
>
>The first one presents an interesting chicken and egg problem for my
>development environment.  Assuming a master source directory with files having
>the following dependencies:
>
>alpha.c: alpha.h
>alpha.h: beta.h
>beta.h:  gamma.h
>
>Then assume that I copy alpha.c and gamma.h locally to make some changes.
>When I compile alpha.c, #1 says that the gamma.h that beta.h includes will be
>the one in the master source directory.  Is this normal?  In my example, this
>may not look like much of a problem, but multiply the number of files by 3
>orders of magnitude and you begin to see the problem.
>
>Is there a standard approach to doing development that avoids this problem
>(that obviously we overrode in our VMS development with logicals)?


It is my guess that each path is searched completely once for all files.
Any file that it finds is brought in and then it goes on to the next path.

By the time beta.h is brought in, the preprocessor is already in the "beta.h"
path.  It then needs gamma.h by the dependency.  Since gamma.h is here
there is no need to search another (previous) path.

If the preprocessor searched each path separately for each include file, the
problem would be nil.  However, I don't think that is the case (it would be
more overhead)

Of course, this is all speculation.  It would require a look a source code
for the compiler to confirm or deny this theory.

--
-----------------------------------------------------
| Kevin L. Cureton      | It's my fingers on the    |
| curetonk@cs.rice.edu  | keys, so don't blame any- |
| Rice University CRPC  | one else for what I say.  |

>>>>> On 4 May 93 21:02:20 GMT, curetonk@helena.cs.rice.edu (Kevin Cureton)
>>>>> said:

> In article <DAVIDM.93Apr29220413@prometheus.consilium.com>
> davidm@consilium.com (David S. Masterson) writes:

>>According to the documentation for the C preprocessor on a couple of systems,
>>quoted include files are searched for in the following way:

>>1. Look for the file in the directory containing the file with the #include.
>>2. Look for the file in directories listed with -I on cc line.
>>3. Look for the file in the standard list of directories.

>>The first one presents an interesting chicken and egg problem for my
>>development environment.  Assuming a master source directory with files
>>having the following dependencies:

>>alpha.c: alpha.h
>>alpha.h: beta.h
>>beta.h:  gamma.h

>>Then assume that I copy alpha.c and gamma.h locally to make some changes.
>>When I compile alpha.c, #1 says that the gamma.h that beta.h includes will
>>be the one in the master source directory.  Is this normal?  In my example,
>>this may not look like much of a problem, but multiply the number of files
>>by 3 orders of magnitude and you begin to see the problem.

> It is my guess that each path is searched completely once for all files.
> Any file that it finds is brought in and then it goes on to the next path.

No, the order of search for any quoted include file is as listed in 1-3 above.
If CPP doesn't find a file under #1, it goes on to 2 & 3.

> If the preprocessor searched each path separately for each include file, the
> problem would be nil.

No, the problem would still be there.  The problem is not searching each path,
but the order in which it searches those paths.  If it uses the wrong order,
it may find the wrong file.

> Of course, this is all speculation.  It would require a look a source code
> for the compiler to confirm or deny this theory.

Its relatively easy to set up external test cases that prove the theory (like
I did above).

Good try...  ;-)

--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
davidm@consilium.com    Mtn. View, CA  94043
====================================================================
"Justice has nothing to do with what goes on in a courtroom, Justice is what
 comes out of a courtroom."
-- Clarence Darrow

In article <DAVIDM.93Apr29220413@prometheus.consilium.com> davidm@consilium.com (David S. Masterson) writes:
>I've recently run into an interesting revelation with how #include works.
>According to the documentation for the C preprocessor on a couple of systems,

All the standards say is that two sets of locations will be searched.
Lets label these two sets 'GBL' and 'LCL'.

#include <foo.h>

searches the GBL set.

#include "foo.h"

searches the LCL set followed by the GBL set.  Thats all the standards say.
Everything else is implementation defined, so you have to ask your compiler
vendor what is going on.  Unfortunately, this is an area that compiler
vendors frequently do a very poor job of documenting.  It would seem
helpful if standards could at least list common command line options,
while not mandating such, when vendors are in general agreement.

In article <1993May06.165157.16939@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <DAVIDM.93Apr29220413@prometheus.consilium.com> davidm@consilium.com (David S. Masterson) writes:
>>I've recently run into an interesting revelation with how #include works.
>>According to the documentation for the C preprocessor on a couple of systems,
>
>All the standards say is that two sets of locations will be searched.
>Lets label these two sets 'GBL' and 'LCL'.
>
>#include <foo.h>
>
>searches the GBL set.
>
>#include "foo.h"
>
>searches the LCL set followed by the GBL set.  Thats all the standards say.
>Everything else is implementation defined, so you have to ask your compiler
>vendor what is going on.  Unfortunately, this is an area that compiler
>vendors frequently do a very poor job of documenting.  It would seem
>helpful if standards could at least list common command line options,
>while not mandating such, when vendors are in general agreement.
>

 #include has to be the worst portability nightmare invented.
It would be better, perhaps, to have

 include foo;

where foo is a module name. No path, no implementation
dependent file names. Portable code. Perhaps precompiled
headers.

 Of course, you would still have to bind the module name
to a file, but you can do that with a separate specification
in *one* place that binds the local environment to the module
names (in some implementation defined way).

 I've tried to so this using something like

#include pathname "/file.h"

but I cant get the pre-processor to join up the two strings :-(
That leaves a *literal* interpretation of my module idea:

#include "environ.h"
#include modulename1
#include modulename2

where environ.h looks like:

#define modulename1 "filename1"
#define modulename2 "filename2"
...



--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <C6It3w.6Gq@rice.edu> curetonk@helena.cs.rice.edu (Kevin Cureton) writes:
>In article <DAVIDM.93Apr29220413@prometheus.consilium.com> davidm@consilium.com (David S. Masterson) writes:
>>I've recently run into an interesting revelation with how #include works.
>>According to the documentation for the C preprocessor on a couple of systems,
>>quoted include files are searched for in the following way:
>>
>>1. Look for the file in the directory containing the file with the #include.
>>2. Look for the file in directories listed with -I on cc line.
>>3. Look for the file in the standard list of directories.
>>
>>The first one presents an interesting chicken and egg problem for my
>>development environment.  Assuming a master source directory with files having
>>the following dependencies:
>>
>>alpha.c: alpha.h
>>alpha.h: beta.h
>>beta.h:  gamma.h
>>
>>Then assume that I copy alpha.c and gamma.h locally to make some changes.
>>When I compile alpha.c, #1 says that the gamma.h that beta.h includes will be
>>the one in the master source directory.  Is this normal?  In my example, this
>>may not look like much of a problem, but multiply the number of files by 3
>>orders of magnitude and you begin to see the problem.
>>
>>Is there a standard approach to doing development that avoids this problem
>>(that obviously we overrode in our VMS development with logicals)?
>
>
>It is my guess that each path is searched completely once for all files.
>Any file that it finds is brought in and then it goes on to the next path.
>

What happens on some (but not all) unix systems is:

If alpha.h, beta.h and gamma.h  are in  .../dev/include
and you copy gamma.h or beta.h to "." to change it, the compiler
will pick up *all three* files from  .../dev/include and will *not*
pick up any of the files from ".".

Other systems will pick up alpha.h from .../dev/include and the rest
from ".".

One way around this problem is to do:

   foreach x (.../dev/include/*.h)
      ln -s $x .
   end

and then remove the softlink and copy the files for those you wish to change.
You might want to put them in ../include instead of in .

Stuart
--
== Stuart MacMartin   sjm@bnr.ca   Bell-Northern Research, Ottawa, CANADA
==                                 Standard disclaimers apply

>>>>> On 6 May 93 16:51:57 GMT, jimad@microsoft.com (Jim Adcock) said:

> In article <DAVIDM.93Apr29220413@prometheus.consilium.com>
> davidm@consilium.com (David S. Masterson) writes:

>>I've recently run into an interesting revelation with how #include works.
>>According to the documentation for the C preprocessor on a couple of
>>systems,

> All the standards say is that two sets of locations will be searched.
> Lets label these two sets 'GBL' and 'LCL'.

> #include <foo.h>

> searches the GBL set.

> #include "foo.h"

> searches the LCL set followed by the GBL set.

The interesting point is that, in the case where foo.h is in the GBL area,
many vendors would say that, if it includes beta.h, the compiler will search
only the GBL set because that's where foo.h is stored.  Whether its angle
brackets or quotes around foo.h or beta.h doesn't make any difference.

> Thats all the standards say.

The standard should say what LCL and GBL are relative to (and very carefully,
I might add).  If LCL and GBL are relative to the file doing the #include,
then we don't need to have two types of #includes (how many people are going
to include "foo.h" and <foo.h> in the same source file?).  If its relative to
the first file the compiler started with, then the two types make sense (does
any developer *not* have system include files use only angle brackets?).

--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
davidm@consilium.com    Mtn. View, CA  94043
====================================================================
"If a machine can be made so that an idiot can use it,
 then only an idiot will use it."
-- Tadao Ichikawa