473,322 Members | 1,538 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

static member function, with no public/private/etc.

What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.

thanks

Zytan

Feb 25 '07 #1
26 2401
Zytan wrote:
What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.
Yes - private.

Arne
Feb 25 '07 #2
Yes - private.

Thanks Arne!

Zytan
Feb 25 '07 #3
Zytan <zy**********@yahoo.comwrote:
What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.
C# uses the excellent policy of making the "default" privacy level the
most private that can be used at the time. So, for instance:

class Outer
{
class Nested
{
}
}

The class Outer.Nested is private (because that's the most restrictive
access for a nested class) but class Outer is internal (because that's
the most restrictive access for a top-level class).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 25 '07 #4
Zytan wrote:
What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.

thanks

Zytan
Yes, they are private.

C# Language Specification - 3.5.1 Declared accessibility:

"Struct members can have public, internal, or private declared
accessibility and default to private declared accessibility because
structs are implicitly sealed."

http://msdn2.microsoft.com/en-us/lib...27(VS.71).aspx

--
Göran Andersson
_____
http://www.guffa.com
Feb 25 '07 #5
C# uses the excellent policy of making the "default" privacy level the
most private that can be used at the time. So, for instance:

class Outer
{
class Nested
{
}

}

The class Outer.Nested is private (because that's the most restrictive
access for a nested class) but class Outer is internal (because that's
the most restrictive access for a top-level class).
Jon,

great! I'll have to look up what internal means, but I know what
you're saying, and it's great that c# does this. But, i wonder why it
doesn't just force you to write the restriction attributes
explicitly? Is it common for people to rely on the default? I would
have thought no.

Zytan

Feb 26 '07 #6
Yes, they are private.
>
C# Language Specification - 3.5.1 Declared accessibility:

"Struct members can have public, internal, or private declared
accessibility and default to private declared accessibility because
structs are implicitly sealed."

http://msdn2.microsoft.com/en-us/lib...27(VS.71).aspx
Thanks Göran!

Zytan

Feb 26 '07 #7
Zytan wrote:
>I'll have to look up what internal means
It means only accessible from same assembly.

Arne

Feb 26 '07 #8
On Feb 25, 11:52 pm, Arne Vajhřj <a...@vajhoej.dkwrote:
Zytan wrote:
I'll have to look up what internal means

It means only accessible from same assembly.

Arne
Ok. thanks. I was just looking this up myself:

http://msdn2.microsoft.com/en-us/library/7c5ka91b.aspx
"Internal types or members are accessible only within files in the
same assembly"

http://msdn2.microsoft.com/en-us/library/ms173099.aspx
"An assembly is a fundamental building block of any .NET Framework
application. For example, when you build a simple C# application,
Visual Studio creates an assembly in the form of a single portable
executable (PE) file, specifically an EXE or DLL."

So, any file at all in the whole project (that ends up being a single
EXE or DLL) can access something labelled 'internal', right?

Zytan

Feb 26 '07 #9
Zytan <zy**********@yahoo.comwrote:
great! I'll have to look up what internal means, but I know what
you're saying, and it's great that c# does this. But, i wonder why it
doesn't just force you to write the restriction attributes
explicitly? Is it common for people to rely on the default? I would
have thought no.
Personally I like relying on the defaults. In general, things should be
as private as they can be, so if I rely on the default it means that
anywhere there's an access modifier (public, internal etc) it means
I've deliberately made something more public. Different people have
different styles though.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 26 '07 #10
Personally I like relying on the defaults. In general, things should be
as private as they can be, so if I rely on the default it means that
anywhere there's an access modifier (public, internal etc) it means
I've deliberately made something more public. Different people have
different styles though.
Yes, this makes sense, once you know what the defaults are. Before I
am comfortable with what is done implicitly, I like to see the access
modifier so I know what it IS. If it's set to default, I would be
wondering what is it implicitly set to. That's why i like explicit.
Many times implicit is not a good thing.

But, now I know that I'm ok for this, since the compiler is smart.
So, your method makes sense. thanks.

Zytan

Feb 26 '07 #11
Jon Skeet [C# MVP] wrote:
Zytan <zy**********@yahoo.comwrote:
>great! I'll have to look up what internal means, but I know what
you're saying, and it's great that c# does this. But, i wonder why it
doesn't just force you to write the restriction attributes
explicitly? Is it common for people to rely on the default? I would
have thought no.

Personally I like relying on the defaults. In general, things should be
as private as they can be, so if I rely on the default it means that
anywhere there's an access modifier (public, internal etc) it means
I've deliberately made something more public. Different people have
different styles though.
I guess a lot of people like the code to be verbose.

Especially people using multiple languages: what is
default in C# class, Java class, C++ class and C++ struct.

Arne
Feb 28 '07 #12
Arne Vajhřj wrote:
Jon Skeet [C# MVP] wrote:
>Zytan <zy**********@yahoo.comwrote:
>>great! I'll have to look up what internal means, but I know what
you're saying, and it's great that c# does this. But, i wonder why it
doesn't just force you to write the restriction attributes
explicitly? Is it common for people to rely on the default? I would
have thought no.

Personally I like relying on the defaults. In general, things should
be as private as they can be, so if I rely on the default it means
that anywhere there's an access modifier (public, internal etc) it
means I've deliberately made something more public. Different people
have different styles though.

I guess a lot of people like the code to be verbose.

Especially people using multiple languages: what is
default in C# class, Java class, C++ class and C++ struct.

Arne
One reason for always writing the access specifier is that then it's
visible that it's not forgotten. If one always include them, one can
easily see the difference between members that are intentionally private
and those that are accidentaly private by forgetting to specify anyting.

--
Göran Andersson
_____
http://www.guffa.com
Feb 28 '07 #13
Göran Andersson <gu***@guffa.comwrote:
Especially people using multiple languages: what is
default in C# class, Java class, C++ class and C++ struct.
One reason for always writing the access specifier is that then it's
visible that it's not forgotten. If one always include them, one can
easily see the difference between members that are intentionally private
and those that are accidentaly private by forgetting to specify anyting..
But because the default is the most limited, it's very rare that you
can get away with something *accidentally* being too limited - because
if you need something to be less limited, the compiler will tell you
because you'll be trying to access it from elsewhere!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #14
Especially people using multiple languages: what is
default in C# class, Java class, C++ class and C++ struct.
One reason for always writing the access specifier is that then it's
visible that it's not forgotten. If one always include them, one can
easily see the difference between members that are intentionally private
and those that are accidentaly private by forgetting to specify anyting.

But because the default is the most limited, it's very rare that you
can get away with something *accidentally* being too limited - because
if you need something to be less limited, the compiler will tell you
because you'll be trying to access it from elsewhere!
You all raise good points here.

For now, I'll be verbose, since I want to see what's going on. I
don't think I'll get in trouble since I'm only using public and
private.

Good point about multiple languages. Is the default case *always* the
most limited, for all languages?

Zytan

Feb 28 '07 #15
Zytan <zy**********@yahoo.comwrote:
But because the default is the most limited, it's very rare that you
can get away with something *accidentally* being too limited - because
if you need something to be less limited, the compiler will tell you
because you'll be trying to access it from elsewhere!

You all raise good points here.

For now, I'll be verbose, since I want to see what's going on. I
don't think I'll get in trouble since I'm only using public and
private.
I rarely use anything other than public, private and internal.
Good point about multiple languages. Is the default case *always* the
most limited, for all languages?
Definitely not. Java has an odd default (for most things) that you
can't even specify explicitly. I don't know about other .NET languages
though.

Personally I don't mind thinking differently for different languages
though - I find that if I don't, I end up with terrible code (with
incorrect use of conventions and idioms) anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 28 '07 #16
I rarely use anything other than public, private and internal.

I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?
Definitely not. Java has an odd default (for most things) that you
can't even specify explicitly. I don't know about other .NET languages
though.
Ok, I thought so. Too bad.
Personally I don't mind thinking differently for different languages
though - I find that if I don't, I end up with terrible code (with
incorrect use of conventions and idioms) anyway.
Yeah, and some you have to. Imagine coding VB with arrays stated with
highest index rather than length. I'm glad I moved to C#.

Zytan

Feb 28 '07 #17
Zytan wrote:
Good point about multiple languages. Is the default case *always* the
most limited, for all languages?
No:

C# - private = most restricted
Java - package = something in the middle
C++ class - private = most restricted
C++ struct - public = least restricted

Arne
Mar 1 '07 #18
Good point about multiple languages. Is the default case *always* the
most limited, for all languages?

No:

C# - private = most restricted
Java - package = something in the middle
C++ class - private = most restricted
C++ struct - public = least restricted

Arne
Yes, I should have known, since I knew about C++ class vs struct.

Thanks Arne.

Zytan

Mar 1 '07 #19
On Feb 28, 3:21 pm, "Zytan" <zytanlith...@yahoo.comwrote:
I rarely use anything other than public, private and internal.

I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?
A member that is public is visible to any code that can see the class.
So if
your class is public, its public members will be visible outside of
the
assembly. If the class is internal (the default), its public members
are
visible only to other classes within the same assembly.

A member that is internal is only visible within the assembly, but to
all
code within that assembly. It is roughly equivalent to private in C++
with
all of the methods in the assembly being friends, but just for those
members.

Using protected in C# requires you to decide whether it is just
available
to derived classes in the assembly, or to all derived classes. So C#
gives you a lot more flexibility than Java.
Mar 1 '07 #20
A member that is public is visible to any code that can see the class.
So if
your class is public, its public members will be visible outside of
the
assembly. If the class is internal (the default), its public members
are
visible only to other classes within the same assembly.
[snip]
Ok, I get that. That's the technical definition that I already know.

What I am asking is: What is the assembly?

I think it's the current compilation (.exe or .dll). So, what is the
point of this distinction? What can possibly be outside the assembly
for us to care if something outside of it can see our stuff? What is
the difference between public and internal assuming 'assembly' isn't
defined? Your answer assumes the asker knows what 'assembly' means.
And this is precisely the term whose meaning I am trying to determine.

I hope my question is more clear now.

thanks!

Zytan

Mar 1 '07 #21
On Feb 28, 6:50 pm, "Zytan" <zytanlith...@yahoo.comwrote:
What I am asking is: What is the assembly?
The output of a compilation process in .NET -- an
application (solution in VS2005 terminology) is a
set of assemblies (one exe and many dlls) that are
cobbled together to work together to provide the
services you need.
I think it's the current compilation (.exe or .dll). So, what is the
point of this distinction? What can possibly be outside the assembly
for us to care if something outside of it can see our stuff?
If you are creating a library (dll), presumably you are doing
it because you want to reuse those classes in several
different applications. Unless your classes are public, there
is no way to use them. If your classes are public, there
would still be no way to use them unless they had public
members.
What is
the difference between public and internal assuming 'assembly' isn't
defined? Your answer assumes the asker knows what 'assembly' means.
And this is precisely the term whose meaning I am trying to determine.
I see now what you were asking. Assemblies are so key
to what .NET is that it didn't occur to me that you were
asking that question in a round-about way.

It is true that it is rare for anything in an executable
assembly (exe) to need to be public, still most people do
make their classes and several of their members public
(mostly just out of habit).

As you get more experience with .NET and start using it
for real work, you'll probably find that, like most people,
you spend more time developing dll assemblies
(.NET components, if you will) since they are where
domain-specific class families (collaborating classes,
not necessarily inheriting classes) reside. As you put
those dlls together you will be able to develop lots
of applications, but you will need to access the pieces
of the different assemblies you have developed to make
them work, so the distinction between public and
internal is very important.

Mar 1 '07 #22
Zytan <zy**********@yahoo.comwrote:
I rarely use anything other than public, private and internal.

I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?
Yes, that's exactly the case.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #23
The output of a compilation process in .NET -- an
application (solution in VS2005 terminology) is a
set of assemblies (one exe and many dlls) that are
cobbled together to work together to provide the
services you need.
So each single .exe and .dll is *one* assembly?
If you are creating a library (dll), presumably you are doing
it because you want to reuse those classes in several
different applications. Unless your classes are public, there
is no way to use them. If your classes are public, there
would still be no way to use them unless they had public
members.
So, if I have a .dll with classes that many other programs will use:

If they have everything as internal, other programs cannot see them,
since they are internal to the .dll assembly itself, and not visible
outside of the .dll assembly? And if they are public, then the
program can them see inside of the .dll assembly?
I see now what you were asking. Assemblies are so key
to what .NET is that it didn't occur to me that you were
asking that question in a round-about way.
Yes, I figured this was the case. And this is why I want to have a
proper understanding of them.
It is true that it is rare for anything in an executable
assembly (exe) to need to be public, still most people do
make their classes and several of their members public
(mostly just out of habit).
Yes, as I do. So, these people should all be using internal instead
of public, since they are never going to need for them to visible
outside of their assembly (to other programs that may use the .dll
that they are creating).
As you get more experience with .NET and start using it
for real work, you'll probably find that, like most people,
you spend more time developing dll assemblies
(.NET components, if you will) since they are where
domain-specific class families (collaborating classes,
not necessarily inheriting classes) reside. As you put
those dlls together you will be able to develop lots
of applications, but you will need to access the pieces
of the different assemblies you have developed to make
them work, so the distinction between public and
internal is very important.
Right, like little sets of tools to be used by may current / future
programs, and they need to be 'seen' by these programs for them to be
used.

Thanks for the indepth explanation xperthands.

Zytan

Mar 1 '07 #24
I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?

Yes, that's exactly the case.
Thanks, Jon.

Zytan
Mar 1 '07 #25
Zytan <zy**********@yahoo.comwrote:
The output of a compilation process in .NET -- an
application (solution in VS2005 terminology) is a
set of assemblies (one exe and many dlls) that are
cobbled together to work together to provide the
services you need.

So each single .exe and .dll is *one* assembly?
Yes.
If you are creating a library (dll), presumably you are doing
it because you want to reuse those classes in several
different applications. Unless your classes are public, there
is no way to use them. If your classes are public, there
would still be no way to use them unless they had public
members.

So, if I have a .dll with classes that many other programs will use:

If they have everything as internal, other programs cannot see them,
since they are internal to the .dll assembly itself, and not visible
outside of the .dll assembly? And if they are public, then the
program can them see inside of the .dll assembly?
Spot on.
It is true that it is rare for anything in an executable
assembly (exe) to need to be public, still most people do
make their classes and several of their members public
(mostly just out of habit).

Yes, as I do. So, these people should all be using internal instead
of public, since they are never going to need for them to visible
outside of their assembly (to other programs that may use the .dll
that they are creating).
Indeed. It's usually laziness which makes people use public when they
mean internal - and that applies very much to myself, by the way. On
the other hand, it rarely does any harm. (Making things public which
should be *private* is more of an issue, of course.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 1 '07 #26
So each single .exe and .dll is *one* assembly?
>
Yes.
So, if I have a .dll with classes that many other programs will use:
If they have everything as internal, other programs cannot see them,
since they are internal to the .dll assembly itself, and not visible
outside of the .dll assembly? And if they are public, then the
program can them see inside of the .dll assembly?

Spot on.
Yes, as I do. So, these people should all be using internal instead
of public, since they are never going to need for them to visible
outside of their assembly (to other programs that may use the .dll
that they are creating).

Indeed. It's usually laziness which makes people use public when they
mean internal - and that applies very much to myself, by the way. On
the other hand, it rarely does any harm. (Making things public which
should be *private* is more of an issue, of course.)
Ok! Thank you, xperthands and Jon!!! :)

Zytan

Mar 1 '07 #27

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: Roger Leigh | last post by:
The C++ book I have to hand (Liberty and Horvath, Teach yourself C++ for Linux in 21 Days--I know there are better) states that "static member functions cannot access any non-static member...
15
by: cppaddict | last post by:
I have class with two static member objects, one of type int and one of type vector<int>. static int myStaticMemberInt static vector<int> myStaticMemberVector; I know how to initialize the...
15
by: Samee Zahur | last post by:
Question: How do friend functions and static member functions differ in terms of functionality? I mean, neither necessarily needs an object of the class to be created before they are called and...
13
by: Adam H. Peterson | last post by:
I just made an observation and I wondered if it's generally known (or if I'm missing something). My observation is that static protected members are essentially useless, only a hint to the user. ...
6
by: Bill Rubin | last post by:
The following code snippet shows that VC++ 7.1 correctly compiles a static member function invocation from an Unrelated class, since this static member function is public. I expected to compile the...
11
by: Kevin Prichard | last post by:
Hi all, I've recently been following the object-oriented techiques discussed here and have been testing them for use in a web application. There is problem that I'd like to discuss with you...
4
by: Josefo | last post by:
Hello, is someone so kind to tell me why I am getting the following errors ? vector_static_function.c:20: error: expected constructor, destructor, or type conversion before '.' token...
6
by: VSP | last post by:
Hello, I am just implementing singleton pattern in various ways. In one implementation I created a static member and returning that static member in the getInstance() function. I have made...
5
by: Tim Frink | last post by:
Hi, I'm experimenting with function pointers and found two questions. Let's assume this code: 1 #include <iostream> 2 class A; 3 4 //////////////////////////////////////////// 5 class B
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.