Re: A summary of the #include liability

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 09/08/04 

Date: Wed, 08 Sep 2004 04:30:23 -0400

Ioannis Vranos wrote:

> Steven T. Hatton wrote:
>
>> If you merely intended to show that the .NET and CLI are doing what I
>> want within the limits of the environment, then, yes, it looks like that
>> is the
>> case. This is encouraging in so much as it shows it can be done. Why it
>> has not already been done for C++ in general is beyond my ability to
>> comprehend.
>
>
> In C++/CLI, (as far as I know) the #using directive includes a dll
> (which is essentially a precompiled run-time library).
>
> The runtime library itself must be either in the same folder with the
> application, the most common, or to a special CLI implementation global
> scope place.

To some extent, that is an implementation detail. Yes, the difference is
significant in the sense that one happens under far different circumstances
than the other. But, in principle I don't believe that distinction means
the same notation could not be used at compile time.

> The #include mechanism is for compile time inclusion. The one does not
> replace the other.

Perhaps I am making some unfounded assumptions. For one, can I assume that
if I write my own dll code and make that available at compile time, the dll
will be compiled and then used by the compiler to compile the source that
imported it? If so, then it seems the #include is not necessary in that
case.

> Where exactly is the #using mechanism better than #include?

If it applied to all code, and not just CLI runtime it would solve the
problems I enumerated in my first post in this thread. An example of how
this might be accomplished is provided by the mechanism in bjam for listing
sources required to build a target. You can list a library and have bjam
determine if the library needs to be built by evaluating a rule that names
the sources required to build the library. If the library is not
available, it is compiled at that time. The same mechanism could be
adapted to work in conjunction with using declarations in C++ source. 

-- 
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.

Relevant Pages

  • Re: writing drivers using C++
    ... No, both can be done at compile time, though the implementation ... as soon as you got a strict ABI. ... And at least on a programming language level something like an ...
    (comp.os.linux.development.system)
  • Re: creaping coupling......
    ... In C++ it would be trivial to break that source code dependency, ... When you compile a .java module, ... In Java and C# it's asserted at compile time. ...
    (comp.object)
  • Re: VB Compiler Warnings & other woes ...
    ... you will get this warning in vs 2005. ... > have a direct legacy language path of evolution to consider. ... >> compile time errors rather than runtime. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: The various levels of /CLI
    ... program doesn't compile as in '/CLI safe', ... CLI / Safe means that the resulting program is pure managed (only ... IL instructions, and no native CPU instructions), which is the same as CLI ... and VB) produce verifiable code by default or even exclusively. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: No exceptions?
    ... time that was removed before runtime; there's no way to generate a compile time exception for the unexceptionable, but there are not many ways of avoiding a runtime exception if the compile time y had defined attributes. ... Thus, as soon as one compiles a statement that references any such resource, one would get a compile-time error. ... I think many products go to elaborate lengths and introduce arbitrary concepts to handle such cases, at least some of them try to prevent catalogue updates in a transaction (Jim Gray described a logical '2-phase' protocol for intension locks many years ago and I've seen it implemented and I've seen the complications that seem never to end due to the intricacy, for example a reversal of Jonathan's converse problem, a sequential transaction that references y and then deletes y's definition - what should happen if the reference is then referred to again? ...
    (comp.databases.theory)