Include Statement

  • Thread starter Thread starter Mike
  • Start date Start date
Mike said:
Fair enough.

First, single sourcing is very important concept. Currently under the
IDE, to ADD "Existing Item" it makes a copy.
Click to expand...

Not necessarily. It's also possible to share files containing source code
(and other file types too) between multiple projects, by adding them as a
reference (in the same dialog you use to add the existing item---just note
that the accept button shows a little drop-down arrow allowing you to create
a reference to the file only). However, this practice is typically
discouraged because it may make maintenance harder if one file belongs to
more than one project.
Forth, personally, I program mostly via the console with my power
programming editor of nearly 30 years - qedit. I have tons of code
snippnets that I generally create and save include like a puzzle. I don't
need this to be .NET dlls in only to use it. I have created some basic
VB.NET classes and right now I needed to add it (the include files) to the
VBC options setup in my F9 compiler action. A simple #include would be
very useful here.
Click to expand...

You could use the '@<file>' command line option together with "vbc" and
maintain the parameters you pass to "vbc" in a separate file. Using MSBUILD
would also be an option.
 
Cor said:
Armin,

What is the sense of this discussion.
Click to expand...

main title: "Convincing Mike"
sub title: "Why #include is useless for 99.99999% of all VB programmers."


Armin
 
Mike said:
I'm not convinced. There is no difference in the usefulness of the
above being this:

#const USE_VERSION = 1

#if USE_VERSION = 1 then
#include "version1.inc"
#elseif USE_VERSION = 2 then
#include "version2.inc"
#else then
#error "USE_VERSION not defined"
#end if
Click to expand...

What does this tell me? I don't see the point.
There are MILLION programmers who do feel this is very useful.
Click to expand...

How can it be useful if it does not even exist? I'm talking about
usefullness in *VB*. There are milliions of VB.net programmes that do
NOT need it. Who is right now? 8-o
To say it has no usefulness, just because you can't see it, is
ludicrous. Again, ASPX files has include concepts too.
Click to expand...

I know nothing about ASPX, so I can't say anything about it. I'm talking
about the VB language.

A include file can be class, but fair enough. But that just a matter of
lack of wide development experience, especially across different
languages and especially in production where such ideas are par for the
course.
Click to expand...

We are talking about reusing existing code, right? Why would you ever
want to have any source code that you do not even compile??? Is it just
hanging around waiting to be #included somewhere in the future?
ALL my source code gets compiled!!! So, now that we have a compiled dll,
why not just use it? I set a reference, and that's it. I have never ever
had any single case that made me long for inserting source code from
another file since the first Framework SDK preview.

That's at least my picture of how code reuse is done nowadays. I don't
write a bunch of consecutive LOC to be inserted anywhere else. I write
classes and components to be reused.

I do not deny there is no single case where #include can be useful
(because I can not speak for *everyone*) However, if 1 out of 10,000
programmers comes across one single situation in his hole VB-life, I
wouldn't even bother thinking about adding this feature if I were MSFT.


Armin
 
I find it hard to understand how any DEVELOPER does not see "general"
value, but that just might mean we have a different mindset in the VB
world - which is ok, but I was something you had to take account when
I work with engineers with VB only Application developers.
Click to expand...

I have used C and C++ for at least 20 years before I started using VB
..NET. Not once have I said to myself, "gee, I wish VB .NET had
#include".

My guess is that either you use #include for something I have never
used it for and if I was aware of that use I would want it in VB, or
you are not aware of the different ways that VB .NET works that makes
my previous need for #include not necessary in VB .NET.
 
Comments interspersed below:


Mike said:
You can *include" me as well. :-)


For the same reason conditional compilation directives were added to
compile a block vs not to compile a block.

For the same reason you have IMPORTS to reference an compiled object.
Click to expand...


Just so it is clear, the imports statement allows you to shortcut a fully
quallified class name, so that you may use Form as opposed to
System.Windows.Forms.Form.

Fair enough.

First, single sourcing is very important concept. Currently under the
IDE, to ADD "Existing Item" it makes a copy. It would preferred to have
some method within the main project file to say
Click to expand...


That is why "Add as link" is often prefered.

IMPORTS "FQDN source code" as oppose to assembly namespace

or just use well known traditional concept of #include, after all VB.NET
is really sprinkled with these related ideas.

I have thousands, millions of line of code under my belt. Sometimes I will
do:

#include "mylib.h"

to link in a "reference" (object) or maybe I might just do:

#include "mylib.cpp"
Click to expand...


I would have added mylib.cpp to the makefile.

to burn it all in. The same idea can apply in VB.NET which is being
molded to be more attractive to people like myself by sprinkling it with
"common language" concepts.

Second, it is difficult to explain all the reason because they are VAST,
every programmer has their reasons. Like without out product line source
codes, look at other large projects where the source code is LOADED with
both imports and includes - because the language allowed it.

#include "mylib.h" <-- akin to INTERFACE file
#include "mylib2.cpp" <-- akin to project File
#prama comment(lib,"mylib3.lib") <-- akin to IMPORTS

Thirds, I use alot of compiler #define statements or as it would be in
VB.NET, #const and including in on a single or more files, would be a
godsend.

Forth, personally, I program mostly via the console with my power
programming editor of nearly 30 years - qedit. I have tons of code
snippnets that I generally create and save include like a puzzle. I don't
need this to be .NET dlls in only to use it. I have created some basic
VB.NET classes and right now I needed to add it (the include files) to the
VBC options setup in my F9 compiler action. A simple #include would be
very useful here.

So maybe that doesn't explain it the "reasons" fully that is only
understood by those who are active with these concepts, but honestly, that
is really besides the point here. What is more disconcerting is the
attitude that this or that is not needed, useful. I *hate* people say such
things. :-)

--
Click to expand...

Needed means that it is required for without it, you cannot accomplish a
task.
To me, what you describe does not meet the "needed" mark. You may
have shown it useful in certain cases. It has to be weighed against
maintainable code. That remains to be seen.
 
Jack said:
I have used C and C++ for at least 20 years before I started using VB
.NET. Not once have I said to myself, "gee, I wish VB .NET had
#include".

My guess is that either you use #include for something I have never
used it for and if I was aware of that use I would want it in VB, or
you are not aware of the different ways that VB .NET works that makes
my previous need for #include not necessary in VB .NET.
Click to expand...

Fair enough.

Maybe I am different than most here. In fact, I am sure of it. :-)

I am both a project and product R&D person. I am a divide and conquer
and functional programming power developer. To me, needing to create
a project with a test class when you can simply do:

#include "testcode.vb"

is a waste. Doing it this way, it very fast, is my normal way of doing
things. But thats just one usage.

Thank god for the condition compile directive because I am inserting
different cuts of trial and error code in the different #if #elseif
blocks.

Examples

1) In learning .NET interop, I am trying different DLLImport and
unmanaged statements using compiler directives.

2) In learning Constructor/Destructor concepts in VB.NET, I have new
abstract, interface, implementations, classes, etc of different
versions, different ways to do it using compiler directives.

A lot of this can be consolidated and cleanup with #include.

--
 
Family said:
That is why "Add as link" is often prefered.
Click to expand...

Where is that ADD option?
Needed means that it is required for without it, you cannot accomplish a
task.
To me, what you describe does not meet the "needed" mark. You may
have shown it useful in certain cases. It has to be weighed against
maintainable code. That remains to be seen.
Click to expand...

Good point. Is anything really needed :) Programming is an Art.

But I venture to say that many developers will find #include to be
more useful than not. And if it was available, no doubt it will be
used. Look at the C++/CLR class explore where you can add a METHOD
and optionally separate the method into its own CPP file. Again, VB is
just a LANGUAGE and if the concept is in C/C++, inevitable as VB.NET
moves closer to C/C++ features, you will see similar includes concepts.

Just consider a relative large class or module and consider that
#Regions were added to help with the visual display, to hide blocks
and section of code. Why is that?

Consider that region be so solid that it can move to a separate file.
Maybe in some future of the outliner,
the #region statement can have a link to a file.

#region "private methods" src="c:\common\class1.vb"
#end region

Silly? Perhaps. Just consider the possibilities.

---
 
Mike said:
Well, if you were in a position to see the point, you would. I don't mean
that sarcastically, but if I never came across the idea before, I would
probably have the same feeling. Look at what I did for my CLR class
library:

// WcServerAPICLR.h

#pragma once
namespace NativeWildcat {
#include <wcserver.h>
};
using namespace System;
using namespace System::Runtime::InteropServices;

namespace WcServerAPICLR
{
public ref class Wildcat
{
// wrapper functions
};
}

I can tell you right not, in MS failed to support #include for CLR, I
would probably project side because it would not be to do above.
Click to expand...

Yes, but that's due to the way the C++/CLI compiler works. How would this
make sense in VB/C#? There is simply no need for that! Both languages can
be used to write code executed on the CLR only, and both languages do not
support adding C/C++ header files.

AFAIS you are using the '#include' in the above sample to write a managed
wrapper around unmanaged functionality, whose interface is specified in
"wcserver.h". Well, that's perfectly valid in C/C++, but how would this
concept apply to VB/C#?
It would of been nice to do something similar for my VB.NET version.
Click to expand...

What would "wcserver.vb" contain in the VB version? With both C++/CLI and
VB differing in the feature set they provide, the solution you have chosen
in C++/CLI cannot be applied to VB directly. '#include' in VB/C# would not
solve the problem.
Currently, if I have to include a 'module" to the project, I add "Add
Existing Item", but it makes a freaking copy of the file. So what I do
now is close the solution/project, manually edit the project file and add
a far call to the source file.

If the IDE added an "Add Existing File" that yields a prompt:

"Do you want a copy of keep the current path?"

[ YES-COPY ] [ NO-KEEP ]

Then there would be one less reason for an include.
Click to expand...

Well, the dialog provides the option to create a reference/link to the
external source file. However, I'd try to avoid creating links to other
files because they'd add an additional dependency on source code level.
But overall, now that VB.NET supports #const, this is where it become
really useful where a product may have different const directives

' hardcode it or pass via compiler define option
#const DEMO_VERSION=1

#if DEMO_VERSION then
#include "my_special_class_demo_only.vb"
#else
#include "my_special_crack_protector.vb"
#end if

Also, now that VB.NET supports the INTERFACE declaration, the creativity
is expanded for VB.NET people:

Public Interface IDemo
funtion CheckLicense() as boolean
sub CrippleCode(byval OnOff as Boolean)
End Interface
#if DEMO_VERSION then
#include "implement_idemo_trial_version.vb"
#else
#include "implement_idemo_full_version.vb"
#end if
Click to expand...

Code file:

\\\
#Const LICENSE_VERSION_TRIAL = 1
#Const LICENSE_VERSION_FULL = 2
#Const LICENSE_VERSION = LICENSE_VERSION_TRIAL
///

"ILicenseValidator.vb":

\\\
Friend Interface ILicenseValidator
Function ValidateLicense() As Boolean
End Interface
///

"TrialLicenseValidator.vb":

\\\
#If LICENSE_VERSION = LICENSE_VERSION_TRIAL Then

Friend Class TrialLicenseValidator
Implements ILicenseValidator

Friend Function ValidateLicense() As Boolean _
Implements ILicenseValidator.ValidateLicense

...
End Function
End Class

#End If
///

"FullLicenseValidator.vb":

\\\
#If LICENSE_VERSION = LICENSE_VERSION_FULL Then

Friend Class FullLicenseValidator
Implements ILicenseValidator

Friend Function ValidateLicense() As Boolean _
Implements ILicenseValidator.ValidateLicense

...
End Function
End Class

#End If
///

(I would not recommend this apporach, I just wanted to show that it's
possible to achieve the same effect in VB without huge effort.)
Ok and thats acceptable. Nothing wrong with that. But it really depends on
what level of software engineering and production stage you are at.
Click to expand...

No, it depends on the way you are using the tool.
Why not? Why the hard nose stance in adding a feature that will make
VB.NET and C# cater to an extremely large developer base that might be
employing .NET more into their wares?
Click to expand...

Because it's not required in VB in most of the cases, and in the few other
cases it's neglegible because there are other solid solutions available.
After all, you don't have to use it. :-)
Click to expand...

Nobody has to use VB if he doesn't like the way things are done in VB!
 
Mike said:
Where is that ADD option?
Click to expand...

In the "Add existing item" dialog. You can change the option in the accept
button's drop-down menu.
But I venture to say that many developers will find #include to be more
useful than not. And if it was available, no doubt it will be used. Look
at the C++/CLR class explore where you can add a METHOD and optionally
separate the method into its own CPP file.
Click to expand...

In VB that would be done using a partial class.
Just consider a relative large class or module and consider that #Regions
were added to help with the visual display, to hide blocks and section of
code. Why is that?

Consider that region be so solid that it can move to a separate file.
Maybe in some future of the outliner,
the #region statement can have a link to a file.

#region "private methods" src="c:\common\class1.vb"
#end region

Silly? Perhaps. Just consider the possibilities.
Click to expand...

Just take a look at the 'Partial' keyword ;-)!
 
Mike said:
Where is that ADD option?
Click to expand...


On the "Add Existing Item" dialog, the "Add" button has a down arrow. Click
the down arrow, and you have a choice of "Add as a link".
 
Mike said:
Where is that ADD option?
Click to expand...

Found it! Its the ADD pull down button in the SELECT FILE DIALOG
display. That will raise the productivity bar by allowing me to single
source my code.

Greatly appreciate it and thanks for keeping calm and patience with me. :)

--
 
Herfried said:
Code file:

\\\
#Const LICENSE_VERSION_TRIAL = 1
#Const LICENSE_VERSION_FULL = 2
#Const LICENSE_VERSION = LICENSE_VERSION_TRIAL
///

"ILicenseValidator.vb":

\\\
Friend Interface ILicenseValidator
Function ValidateLicense() As Boolean
End Interface
///

"TrialLicenseValidator.vb":

\\\
#If LICENSE_VERSION = LICENSE_VERSION_TRIAL Then

Friend Class TrialLicenseValidator
Implements ILicenseValidator

Friend Function ValidateLicense() As Boolean _
Implements ILicenseValidator.ValidateLicense

...
End Function
End Class

#End If
///

"FullLicenseValidator.vb":

\\\
#If LICENSE_VERSION = LICENSE_VERSION_FULL Then

Friend Class FullLicenseValidator
Implements ILicenseValidator

Friend Function ValidateLicense() As Boolean _
Implements ILicenseValidator.ValidateLicense

...
End Function
End Class

#End If
///

(I would not recommend this apporach, I just wanted to show that it's
possible to achieve the same effect in VB without huge effort.)
Click to expand...

Hmmmmmmm, 9 lines of code versions 51 lines... hmmmmmmmm :-)

I get your point. See ya.

--
 
Mike wrote, quoting Herfried Wagner:
[Mike]
Also, now that VB.NET supports the INTERFACE declaration, the
creativity is expanded for VB.NET people:
Public Interface IDemo
    funtion CheckLicense() as boolean
    sub CrippleCode(byval OnOff as Boolean)
End Interface
#if DEMO_VERSION then
   #include "implement_idemo_trial_version.vb"
#else
   #include "implement_idemo_full_version.vb"
#end if
Click to expand...
{Herfried]
#Const LICENSE_VERSION_TRIAL = 1
#Const LICENSE_VERSION_FULL = 2
#Const LICENSE_VERSION = LICENSE_VERSION_TRIAL
///
"ILicenseValidator.vb":
Click to expand...

\\\
Friend Interface ILicenseValidator
   Function ValidateLicense() As Boolean
End Interface
///
"TrialLicenseValidator.vb":
Click to expand...

\\\
#If LICENSE_VERSION = LICENSE_VERSION_TRIAL Then
Click to expand...
Friend Class TrialLicenseValidator
   Implements ILicenseValidator
Click to expand...
   Friend Function ValidateLicense() As Boolean _
       Implements ILicenseValidator.ValidateLicense
Click to expand...
       ...
   End Function
End Class
Click to expand...
#End If
///

\\\
#If LICENSE_VERSION = LICENSE_VERSION_FULL Then
Click to expand...
Friend Class FullLicenseValidator
   Implements ILicenseValidator
Click to expand...
   Friend Function ValidateLicense() As Boolean _
       Implements ILicenseValidator.ValidateLicense
Click to expand...
       ...
   End Function
End Class
Click to expand...
#End If
///
Click to expand...
Click to expand...
Hmmmmmmm,  9 lines of code versions 51 lines... hmmmmmmmm :-)

I get your point. See ya.
Click to expand...
<snip>

Lol, it seems you are having a little trouble to *aham* open your mind
to the fact that this use of #include is not really necessary in the
way compilation happens in VB... In other words, it's not a case of a
bunch of completely illiterate newbie programmers that can't see the
value of proven compilation tricks of yore. It actually seems to be
the case of a *new* guy in town who can't get rid of his past habits
and embrace the way of the language he's trying to learn. I know how
you must be feeling, one of the first things I did when I started
programming in C++ was to hack Properties into the language -- you
know, instead of those uggly C->GetValue()/C->SetValue(V) things.
Yeah, stupid from a C++ programmer point of view, even though
perfectly plausible from the point of view of a VB programmer new to
the C++ way of life, who wondered how no C++ programmer could see the
obvious value of having getters/setters with the same name and a
distinctive syntax =D.

I guess you'll have to live with the fact that programming units in
VB.Net are more "closed" than, say, in C/C++ and the use of the pre-
processor (which, if I'm not mistaken, dates back from VB 3.0) is very
limited (fortunately, IMHO) if compared to the (in)famous pre-
processing approach in those languages (I may be wrong, but it seems
Stroustrup himself abhors the C preprocessor [1], not only because of
the #include directive, but also because of the #define directive that
you also seem to like -- and I sense your next argument will be that
Vb.Net is crippled because we don't have such a powerfull macro
mechanism =)). At least, that's the way the compiler works in the IDE.
If you use another editor and call the command-line compiler yourself
(using custom build files) I don't see why you couldn't hack this kind
of preprocessing. But if you use the IDE, this kind of functionality
ins't provided and you can get by without it by using other
approaches, such as the one Herfried exemplified (btw, leaving in his
example only the lines responsible for the "inclusion" of the correct
code, his solution accounts for 4 lines of code, only, not 51 as you
stated =)))))

Best regards and good luck with your VB.Net experiments.

Branco.

[1] http://www.research.att.com/~bs/bs_faq2.html#macro
 
Jack,

I see the word "include" in this thread used in all different kind of
meanings as the same

I think those who do this should use an apple to write there messages
instead of a pear.

However, one thing looks clear to me, those who do that show that they don't
know about what they are writing.

It is simple trolling.

Cor
 
Please accept my apologizes for wasting people thing with include issue.

I didn't meant harm to anyone. Won't happen again.

--
 
I wish they hadn't removed #INCLUDE from the language.

I want to have an object that represents a string field, but where I can
have the possible values drop down in intellisense. Sounds easy right? WRONG.

The way I've done it is to have an interface called IPDomain. Each
implementer of the class has an ENUM called Domain_ENUM, but with member
values unique to the class. I then have to cut and paste common code to each
class which compares strings to Domain_ENUM, provides delegates for
validation etc.

Whenever I change the common code it is a complete pain because I need to go
through and update each implementation. If I had #INCLUDE, I could just
update the include file.

I don't buy the claim that #INCLUDEs would confuse the compiler. There are
already conditional compilation directives; #INCLUDE would be no different.

--
David Streeter
Synchrotech Software
Sydney Australia
 
Mike said:
Found it! Its the ADD pull down button in the SELECT FILE DIALOG display.
That will raise the productivity bar by allowing me to single source my
code.

Greatly appreciate it and thanks for keeping calm and patience with me. :)
Click to expand...

You can also select multiple files in Windows Explorer and drop them on the
project name in Solution Explorer window, and VB will add all of them to the
project. This is true for classic VB as well.
 
I wish they hadn't removed #INCLUDE from the language.
From which language?
Click to expand...

BASIC.

QB45/QBX has '$INCLUDE but Microsoft removed it somewhere along the way to
VB.NET

(off-topic, but MS also got rid of GOSUB too, which is annoying. I like to
make my methods to be 'top-down' in structure and I don't like SUBs which are
called only once ever. GOSUB allowed me to break up the code within a SUB...
now I need to have SUBs called SubName, SubName_ThisPart, SubName_ThatPart
etc)
Creating enumerations of items with a certain arbitrary data type
<URL:http://dotnet.mvps.org/dotnet/faqs/?id=anytypeenums&lang=en>

No need for '#include'.
Click to expand...

Thanks, I'll check that out. Not sure if that solution is exactly what I am
looking for though. What I want is a Class "DomainField" which allows
different ENUMs in it, so I can intellisense drop down of possible values,
but also common code for DomainField instances which treat the ENUM in a
generic fashion. I'm blurring the line between design time and run time,
which is why I am having troubles.

--
David Streeter
Synchrotech Software
Sydney Australia
 
Back
Top