I have posted a C# critique at http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up
the following issues :
- unsafe code
- attributes
- garbage collection
- non-deterministic destructors
- Objects can't exist on the stack
- Type / Reference Types
- Boxing / Unboxing
- Mutability
- Classes as Modules and Programs
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
- C# Missing Template Template Parameters
- Late Added Generics
- Source File Layout
- Public Fields
- Special Primitives
- Is it a Property or is it a field?
- Microsoft
I am perhaps guilty somewhat of being a flame baiting troll, but at the same
time I honestly want to improve on the critique.
Thanks in advance for your responses.
--
Christopher Diggins
yet another language designer http://www.heron-language.com
Nov 15 '05
188  7005 
> Is there a clear advantage to *having* a header file? The C# devs and
users don't seem to think so.
The metadata is available and readable, just not in notepad (or your text
editor of choice), but i think that's hardly a good reason to enforce the
usage of header files :-)
Could be this is just another case of personal preference, which goes back
to the analogy of programmers of one language not liking how the other
language reads.
Header files sucks, always synchronization problems with them, wrong search
paths, 2 locations to edit...
The Delphi way is better, you have your class description en then the
implementation section, but still 2 locations to edit.
The C# is far better in use, only one location to edit. And you have an
immediate overview what is actually inside that method.
One note: Visual Studion .NET C# have this outlining function and the
#region trick, to hide code so your classes become as readable as the
original use of header files. Hiding the implementation details. Reading C#
in notepad is maybe harder to read, these outlining functions in Visual
Studio makes programming a lot easier.
You DONT need to duplicate method signitures in this day and age, the reason
C++ has that is because of the bad design in the compilers.
Function prototypes are bad and are only there to fix compiler bad design.
Tools should work for us not us work for them.
You just are stuck in the dark ages and refuse to budge. I guess no job here
for you :D We need better Software Designers and not ones that stick to old
ways for the sake of it.
<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be... Is there a clear advantage to *having* a header file? The C# devs and users don't seem to think so.
The metadata is available and readable, just not in notepad (or your
text editor of choice), but i think that's hardly a good reason to enforce
the usage of header files :-)
Could be this is just another case of personal preference, which goes
back to the analogy of programmers of one language not liking how the other
language reads.
Header files sucks, always synchronization problems with them, wrong
search paths, 2 locations to edit...
The Delphi way is better, you have your class description en then the
implementation section, but still 2 locations to edit.
The C# is far better in use, only one location to edit. And you have an
immediate overview what is actually inside that method.
One note: Visual Studion .NET C# have this outlining function and the
#region trick, to hide code so your classes become as readable as the
original use of header files. Hiding the implementation details. Reading
C# in notepad is maybe harder to read, these outlining functions in Visual
Studio makes programming a lot easier.
Are we in a flaming mood?????
Please make your point why you think that we are stuck in old ways?
Because both the original writer and I wrote that we don't prefer header
files at all.
And my message below clearly indicates that I prefer the C# way without
function prototyping.
<di********@discussion.microsoft.com> wrote in message
news:Ow**************@TK2MSFTNGP11.phx.gbl... You DONT need to duplicate method signitures in this day and age, the
reason C++ has that is because of the bad design in the compilers.
Function prototypes are bad and are only there to fix compiler bad design.
Tools should work for us not us work for them.
You just are stuck in the dark ages and refuse to budge. I guess no job
here for you :D We need better Software Designers and not ones that stick to
old ways for the sake of it.
<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be... Is there a clear advantage to *having* a header file? The C# devs and
users don't seem to think so.
The metadata is available and readable, just not in notepad (or your text editor of choice), but i think that's hardly a good reason to enforce the usage of header files :-)
Could be this is just another case of personal preference, which goes back to the analogy of programmers of one language not liking how the other
language reads.
Header files sucks, always synchronization problems with them, wrong
search paths, 2 locations to edit...
The Delphi way is better, you have your class description en then the
implementation section, but still 2 locations to edit.
The C# is far better in use, only one location to edit. And you have an
immediate overview what is actually inside that method.
One note: Visual Studion .NET C# have this outlining function and the
#region trick, to hide code so your classes become as readable as the
original use of header files. Hiding the implementation details. Reading
C# in notepad is maybe harder to read, these outlining functions in Visual
Studio makes programming a lot easier.
There is no reason for function prototypes, this was only there to fix a bad
compiler design.
And yeah I got my flameproof suit on.
Every day I hear oh I miss the C .H function prototypes in the header files,
thats the OLD ways, there is NO point in them except bad compiler design.
Its not there to make it easier to give out developer information becuase
they contain private and protected information also, so that arguemnt is out
of the window. Its plain and simply a bad compiler design issue.
<Ol**********@skyscan.be> wrote in message
news:40*********************@news.skynet.be... Are we in a flaming mood?????
Please make your point why you think that we are stuck in old ways?
Because both the original writer and I wrote that we don't prefer header
files at all.
And my message below clearly indicates that I prefer the C# way without
function prototyping.
<di********@discussion.microsoft.com> wrote in message
news:Ow**************@TK2MSFTNGP11.phx.gbl... You DONT need to duplicate method signitures in this day and age, the
reason C++ has that is because of the bad design in the compilers.
Function prototypes are bad and are only there to fix compiler bad
design. Tools should work for us not us work for them.
You just are stuck in the dark ages and refuse to budge. I guess no job
here for you :D We need better Software Designers and not ones that stick to
old ways for the sake of it.
<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be... > Is there a clear advantage to *having* a header file? The C# devs
and users
> don't seem to think so.
> The metadata is available and readable, just not in notepad (or your
text > editor of choice), but i think that's hardly a good reason to
enforce the > usage of header files :-)
> Could be this is just another case of personal preference, which
goes back > to the analogy of programmers of one language not liking how the
other > language reads.
>
Header files sucks, always synchronization problems with them, wrong
search paths, 2 locations to edit...
The Delphi way is better, you have your class description en then the
implementation section, but still 2 locations to edit.
The C# is far better in use, only one location to edit. And you have
an immediate overview what is actually inside that method.
One note: Visual Studion .NET C# have this outlining function and the
#region trick, to hide code so your classes become as readable as the
original use of header files. Hiding the implementation details.
Reading C# in notepad is maybe harder to read, these outlining functions in
Visual Studio makes programming a lot easier.
Yes, you are right in this, but why flame me????
I am the good guy, not the bad guy!!!!
I hate header files!
<di********@discussion.microsoft.com> wrote in message
news:eo**************@TK2MSFTNGP12.phx.gbl... There is no reason for function prototypes, this was only there to fix a
bad compiler design.
And yeah I got my flameproof suit on.
Every day I hear oh I miss the C .H function prototypes in the header
files, thats the OLD ways, there is NO point in them except bad compiler design.
Its not there to make it easier to give out developer information becuase
they contain private and protected information also, so that arguemnt is
out of the window. Its plain and simply a bad compiler design issue.
<Ol**********@skyscan.be> wrote in message
news:40*********************@news.skynet.be... Are we in a flaming mood?????
Please make your point why you think that we are stuck in old ways?
Because both the original writer and I wrote that we don't prefer
header files at all.
And my message below clearly indicates that I prefer the C# way without
function prototyping.
<di********@discussion.microsoft.com> wrote in message
news:Ow**************@TK2MSFTNGP11.phx.gbl... You DONT need to duplicate method signitures in this day and age, the
reason C++ has that is because of the bad design in the compilers.
Function prototypes are bad and are only there to fix compiler bad design. Tools should work for us not us work for them.
You just are stuck in the dark ages and refuse to budge. I guess no
job here for you :D We need better Software Designers and not ones that stick
to old ways for the sake of it.
<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be...
> > Is there a clear advantage to *having* a header file? The C# devs
and > users
> > don't seem to think so.
> > The metadata is available and readable, just not in notepad (or
your text
> > editor of choice), but i think that's hardly a good reason to
enforce the
> > usage of header files :-)
> > Could be this is just another case of personal preference, which goes back
> > to the analogy of programmers of one language not liking how the other > > language reads.
> >
> Header files sucks, always synchronization problems with them, wrong
search
> paths, 2 locations to edit...
> The Delphi way is better, you have your class description en then
the > implementation section, but still 2 locations to edit.
> The C# is far better in use, only one location to edit. And you have an > immediate overview what is actually inside that method.
>
> One note: Visual Studion .NET C# have this outlining function and
the > #region trick, to hide code so your classes become as readable as
the > original use of header files. Hiding the implementation details. Reading C#
> in notepad is maybe harder to read, these outlining functions in Visual > Studio makes programming a lot easier.
>
>
>
As for preprocessors, theyre evil, hard to debug and just not good in any
way to have mixed compiled code.
I prefer to use a const value rather than conditional compile, at least C#
has reduced this need by having defines limited to true or false values,
still I would prefer it not there at all.
The lack of .lib static linking was a bad thing to not have, thankfully its
back in 2.0.
<Ol**********@skyscan.be> wrote in message
news:40*********************@news.skynet.be... Yes, you are right in this, but why flame me????
I am the good guy, not the bad guy!!!!
I hate header files!
<di********@discussion.microsoft.com> wrote in message
news:eo**************@TK2MSFTNGP12.phx.gbl... There is no reason for function prototypes, this was only there to fix a
bad compiler design.
And yeah I got my flameproof suit on.
Every day I hear oh I miss the C .H function prototypes in the header
files, thats the OLD ways, there is NO point in them except bad compiler
design. Its not there to make it easier to give out developer information
becuase they contain private and protected information also, so that arguemnt is
out of the window. Its plain and simply a bad compiler design issue.
<Ol**********@skyscan.be> wrote in message
news:40*********************@news.skynet.be... Are we in a flaming mood?????
Please make your point why you think that we are stuck in old ways?
Because both the original writer and I wrote that we don't prefer header files at all.
And my message below clearly indicates that I prefer the C# way
without function prototyping.
<di********@discussion.microsoft.com> wrote in message
news:Ow**************@TK2MSFTNGP11.phx.gbl...
> You DONT need to duplicate method signitures in this day and age,
the reason
> C++ has that is because of the bad design in the compilers.
>
> Function prototypes are bad and are only there to fix compiler bad
design. > Tools should work for us not us work for them.
>
> You just are stuck in the dark ages and refuse to budge. I guess no job here
> for you :D We need better Software Designers and not ones that stick to old
> ways for the sake of it.
>
>
>
> <Ol**********@skyscan.be> wrote in message
> news:40***********************@news.skynet.be...
> > > Is there a clear advantage to *having* a header file? The C#
devs and > > users
> > > don't seem to think so.
> > > The metadata is available and readable, just not in notepad (or your > text
> > > editor of choice), but i think that's hardly a good reason to
enforce > the
> > > usage of header files :-)
> > > Could be this is just another case of personal preference, which
goes > back
> > > to the analogy of programmers of one language not liking how the
other > > > language reads.
> > >
> > Header files sucks, always synchronization problems with them,
wrong > search
> > paths, 2 locations to edit...
> > The Delphi way is better, you have your class description en then the > > implementation section, but still 2 locations to edit.
> > The C# is far better in use, only one location to edit. And you
have an > > immediate overview what is actually inside that method.
> >
> > One note: Visual Studion .NET C# have this outlining function and
the > > #region trick, to hide code so your classes become as readable as the > > original use of header files. Hiding the implementation details.
Reading > C#
> > in notepad is maybe harder to read, these outlining functions in
Visual > > Studio makes programming a lot easier.
> >
> >
> >
>
>
[snip] You must be disapointed by the .NET framework then. There are many types
like e.g. FileStream, where the constructors can throw and the finalizers
perform actions that can fail. Why exactly do you think a constructor should not propagate exceptions? Why is it better to first construct a type and
then call Open/Init/Whatever?
Ok, with the use of exceptions constructors could do more things that might
fail.
The big problem lays in the fact that if something goes wrong, you have no
access to internal error information since the class does not exist since it
failed.
That's why you can define your own exception classes. Put all error
information in the exception and there won't be a problem.
You have to rely on specialized exception classes that pass on enough
information.
Exactly. What's so bad about that?
For small classes that generates only one unique error, this is
not a problem, but classes that could generate multiple errors (e.g.:
copying multiple files,...loading a big document and parse multiple fields
that might contain errors) could be a big problem.
Why? Do it just like they did with the FileStream class. Define a new
exception for each error you want to give your clients the opportunity
to discriminate on. Expose all necessary info with properties and
you're done. I don't see any problems at all.
Since I do not like to program in a mixed style, I try to use this general
rule to create constructors that normally do not fail. But sometimes you
have exceptions of course.
What's mixed about throwing from a constructor?
But destructors should not! (e.g.: close files) .
I didn't say that, did I? I just said that finalizers sometimes have
to call functions that can fail (e.g. FileStream). If the function
fails the finalizer simply swallows the error. You claimed that
destructors should not call functions that can fail.
The class that opens files should have at least one exposed method to
release the resources used, for example close a file.
Some .NET components do not have this, ...
A really? Exactly which classes are you talking about?
... and I had this very annoying problem
that when I opened the same file 2 times in a row, then it sometimes failed
the second time because it was still locked the first time. The destructor
was not called yet, so the file did not close when I tried to reopen it. It
did not show up in the debug version, but only the release version.
That's one of the reasons why you have to call Dispose() on all
objects of classes that implement IDisposable...
Regards,
Andreas
Thanks to the excellent response from this group, I have re-written the
critique significantly. It is much less of a soapbox now, and has fixed up
many technical flaws and inconsistencies. This new version is going to need
picking apart as well, and I would appreciate more comments.
The new version is at the same location as the old one : http://www.heron-language.com/C-sharp-critique.html.
In regards to the common suggestion that I should write a comparison between
C# and Heron, perhaps I will in the future but I don't think it negates a
stand-alone C# critique.
Thanks to all for your time and input.
--
Christopher Diggins
yet another language designer http://www.heron-language.com
christopher diggins <cd******@videotron.ca> wrote: Thanks to the excellent response from this group, I have re-written the
critique significantly. It is much less of a soapbox now, and has fixed up
many technical flaws and inconsistencies. This new version is going to need
picking apart as well, and I would appreciate more comments.
The new version is at the same location as the old one :
http://www.heron-language.com/C-sharp-critique.html.
In regards to the common suggestion that I should write a comparison between
C# and Heron, perhaps I will in the future but I don't think it negates a
stand-alone C# critique.
Thanks to all for your time and input.
Two things spring to mind after only a very cursory glance
1) Garbage collection - you've got a sentence which doesn't finish
2) User defined type values can't be used as constant expressions, but
you can certainly have readonly variables:
readonly MyValueType foo = new MyValueType(...);
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
christopher diggins wrote: Thanks to the excellent response from this group, I have re-written
the critique significantly. It is much less of a soapbox now, and has
fixed up many technical flaws and inconsistencies. This new version
is going to need picking apart as well, and I would appreciate more
comments.
The new version is at the same location as the old one :
http://www.heron-language.com/C-sharp-critique.html.
In regards to the common suggestion that I should write a comparison
between C# and Heron, perhaps I will in the future but I don't think
it negates a stand-alone C# critique.
Thanks to all for your time and input.
AFAICT, array<complex<float>> will be legal ("although constructed types may
be used as generics").
Regards,
Andreas
As I told you before C# 2.0 doesn't have .lib and static linking. Static
linking involves a native code compiler and a linker, these are the domain
of C++.
Willy.
<di********@discussion.microsoft.com> wrote in message
news:O7****************@TK2MSFTNGP10.phx.gbl... As for preprocessors, theyre evil, hard to debug and just not good in any
way to have mixed compiled code.
I prefer to use a const value rather than conditional compile, at least C#
has reduced this need by having defines limited to true or false values,
still I would prefer it not there at all.
The lack of .lib static linking was a bad thing to not have, thankfully
its
back in 2.0.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Two things spring to mind after only a very cursory glance
1) Garbage collection - you've got a sentence which doesn't finish
Pardon my density but which one?
2) User defined type values can't be used as constant expressions, but
you can certainly have readonly variables:
readonly MyValueType foo = new MyValueType(...);
What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
--
Jon Skeet - <sk***@pobox.com>
--
Christopher Diggins
yet another language designer http://www.heron-language.com
"Andreas Huber" <ah****@gmx.net> wrote in message
news:40**********@news.bluewin.ch... Thanks to all for your time and input.
AFAICT, array<complex<float>> will be legal ("although constructed types
may be used as generics").
Regards,
Andreas
In C#, a generic type parameter cannot itself be a generic, although
constructed types may be used as generics. What is a complex<float> if it is
not a generic? Truthfully I don't have a clue what they mean by "constructed
type".
--
Christopher Diggins
yet another language designer http://www.heron-language.com
christopher diggins <cd******@videotron.ca> wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Two things spring to mind after only a very cursory glance
1) Garbage collection - you've got a sentence which doesn't finish
Pardon my density but which one?
Apologies - it was in value type vs reference type:
"There are more allocations on the heap than are strictly neccessary
leading to memory f" 2) User defined type values can't be used as constant expressions, but
you can certainly have readonly variables:
readonly MyValueType foo = new MyValueType(...);
What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
In fact, a reference can't be const - only a variable can be const, and
the only type of reference variable that can be const is a string one.
Const is for constants, and constants aren't the same as immutable
objects.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
christopher diggins wrote: "Andreas Huber" <ah****@gmx.net> wrote in message
news:40**********@news.bluewin.ch... Thanks to all for your time and input.
AFAICT, array<complex<float>> will be legal ("although constructed
types may be used as generics").
Regards,
Andreas
In C#, a generic type parameter cannot itself be a generic, although
constructed types may be used as generics. What is a complex<float>
if it is not a generic? Truthfully I don't have a clue what they mean
by "constructed type".
complex< float > is a normal class/type. I guess with "constructed type"
they mean an instantiated generic what makes sense given the fact that they
are saying that C# will have nothing like C++ template template parameters
(note the double template).
Regards,
Andreas
I suppose it depends who you talk to and what you talk about :-)
For example, I've had some communications with the Mono developers, and they
are outstanding people to deal with, and overall a great bunch of guys.
However, my personal experience with others in the community is far less
spectacular. If the word Microsoft is ever dropped near most of the people i
know from that camp, they revert from geek compatriot to
raving-zealot-burn-the-heretic mode. Frankly, i'm sick of it, and it
demonstrates only vast ignorance, childishness, and unprofessionalism. I
also believe a healthy number of them do get nowhere... just check the
various lists of projects. There are vast numbers of projects in open-source
purgatory that had a three year alpha, a brief beta, a huge log of bugs, and
abruptly *died*. The source is sitting there, rotting and half finished, in
hopes some other geek will revive it. Hell, this even happens with big
companies in open source. The UnitedLinux consortium flopped over and
officially died this week because its members couldn't get along (and MS
wasn't even one of them).
There's just too much pointless partisanship that has nothing to do with
technical merits or accuracy. The kind of stuff I have come to expect from
politicians and Larry Ellison, not engineers. Technology is science. Leave
the blind devotion and religious fervor for more important things.
And i'm not implying at all that these people don't also exist on the
non-OpenSource side of the fence. We have a healthy number in this NG too.
-Rob Teixeira [MVP]
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <"Rob Teixeira [MVP]" <RobTeixeira@@msn.com>> wrote: You're welcome Christopher. I'm glad to see the more cooperative
attitude. Now if I could only convince the other open-sourcers to do the same, we
might actually get somewhere :-)
Actually, open source folks tend to be very co-operative - otherwise
they don't get anywhere. That's certainly true in my experience,
anyway.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
--
Christopher Diggins
yet another language designer http://www.heron-language.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... christopher diggins <cd******@videotron.ca> wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Two things spring to mind after only a very cursory glance
1) Garbage collection - you've got a sentence which doesn't finish
Pardon my density but which one?
Apologies - it was in value type vs reference type:
"There are more allocations on the heap than are strictly neccessary
leading to memory f"
2) User defined type values can't be used as constant expressions, but
you can certainly have readonly variables:
readonly MyValueType foo = new MyValueType(...);
What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
In fact, a reference can't be const - only a variable can be const, and
the only type of reference variable that can be const is a string one.
Const is for constants, and constants aren't the same as immutable
objects.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Sorry about the previous blank post, finger slipped. Damn trigger finger.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Apologies - it was in value type vs reference type:
"There are more allocations on the heap than are strictly neccessary
leading to memory f"
Thank you.
2) User defined type values can't be used as constant expressions, but
you can certainly have readonly variables:
readonly MyValueType foo = new MyValueType(...);
What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
In fact, a reference can't be const - only a variable can be const, and
the only type of reference variable that can be const is a string one.
Quote from MSDN :
The const keyword is used to modify a declaration of a field or local
variable. It specifies that the value of the field or the local variable
cannot be modified
....
One of the types: byte, char, short, int, long, float, double, decimal,
bool, string, an enum type, or a reference type.
http://msdn.microsoft.com/library/de...lrfconstpg.asp
This would seem to contradict you.
Const is for constants, and constants aren't the same as immutable
objects.
A const variable is an immutable variable though an immutable
variable is not neccessarily const. Do you not agree with me on that one?
Nonetheless, I still stand by my statement as in the critique.
--
Christopher Diggins
yet another language designer http://www.heron-language.com
> GC: Problem #2 : Unsafe contexts. There is a problem of being able to modify
managed types. This significantly undermines the effectiveness of a GC and renders all
unsafe code as potentially having classes of errors which are normally removed by a GC
mechanism. From the language specification :
There are certainly issues that can come up from misuse of unsafe code. The
example you cited from the MSDN talks about strings, for example. Strings
are immutable types in the CLI/CLR, which allows the CLR to do
optimizations. For example, assigning one string ref to another doesn't copy
the contents. Since the runtime knows strings shouldn't change, both
references point at the same character array until one is assigned to a
different value. If you use unsafe code with one ref, and change the value,
you are inadvertantly changing another string ref's data as well, which
could cause a series of bugs. However, this in no way affects the GC. The
objects themselves live on the managed heap, and the GC will eventually get
around to cleaning them. I *strongly urge* you to read up on the GC and how
it works internally. Having said that, let's look at a problem with our
string scenario that can't be solved without unsafe or unmanaged code -
let's say you create one string variable and decrypt cipher data into it
containing a password (or any secret bit of info - credit card number,
etc.). You do what you need to do in your function, and when the function
ends, your string variable goes out of scope. The string is now elegible for
collection. However, you have no idea how long it will remain in memory.
It's possible that it's there for some time, and let's say it gets paged
out. Now, a clever hacker can sniff through your page file for secret data,
and it will show up. Programmers who are wary of security concerns need to
wipe secrets out of memory as quickly as possible. Knowing that there is
only ever one reference to the string, there is no reason I can't pin that
string, and using unsafe or unmanaged code, zero it out. You may not like
unsafe code, and it does have the potential of burning developers who don't
know what they're doing, but it does have its legitimate uses. Remember that
you can turn off this feature by not allowing the compiler switch to be used
by your development team. C# will not compile unsafe code by default. You do
not mention that in your text.
Value Type / Reference Types
A type in C# declares its own passing and assigning semantics. This
violates a consistency rule of expected behaviour. Since objects are always reference
types this also leads to several small performance penalties :
a.. An extra word is always needed for the pointer
b.. There are more allocations on the heap than are strictly neccessary
leading to memory fragmentation
c.. There is more memory than strictly neccessary needed to be cleaned up
by the garbage collector
d.. Dereference of pointer penalty As a result of having two kinds of types and in order to have some kind of
unification C# chose to use a boxing / unboxing semantic. Boxing and unboxing is both
subtle and confusing as it can lead to a surprising interpretation of straightforward
code.
Are you saying that there should only be either all value types or all
reference types? If so, which one would you use? Languages like Java use
exclusively reference types (except for special case primitives) because it
is the most flexible type. However, if you kept all reference types, then
you'd have nothing but types that fit your "perforance penalties". On the
other hand, value types have an enormous number of limitations compared to
reference types, so I can't even fathom a language with all value types.
What's your alternative?
Also, the managed heap doesn't suffer from memory fragmentation like heaps
from certain other languages do. Use of the GC allows all memory to be
allocated sequentially. As objects get collected, the space is compacted by
generation. However, let's pretend for a minute this isn't the case. How
does using a non-reference type change the way the heap is used? You are
still allocating and cleaning out memory, and you'd still be leaving
fragments of unallocated space. I don't quite understand this bullet point,
or the next one. Finally, if you are using a system that has no reference
types, how can you have references that point to the same data? Would you
have to copy all your data EVERY time? How would you synchronize instances
to maintain semantics of assignment? Wouldn't that suck for performance?
Special Primitives and Immutabilty
"a const field is a compile-time constant"
You still haven't answered my question about how you would allow reference
types (or other user-defined types) to have this behavior. This is where we
need to develop the syntax that allows programmers to specify literal values
for what could be relatively complex object graphs, THEN on top of that, the
compiler needs to have a mechanism to store this data in the program AND
reconstitute it at runtime. Then we run into the problem of read-only (which
C# can do) vs. immutability. If you reconstitute the value at runtime by
normal instantiation, you are only creating a read-only value (which C# can
already do). If you reconstitute the value in a truly const manner, you
effectively bypass constructors, which is disasterous. This is why all
languages i can think of don't allow this. If you are suggesting that C# is
doing something that is less than ideal, what is your ideal solution?
C# does not support delegating interface implementations to member
classes. This significantly restricts the ability to use interfaces extensively.
Example? I'm not entirely disagreeing with you, but I'm wondering if we are
exaggerating the problem by using "extensively"?
The reason I'm not disagreeing entirely is that i'm not exactly fond of the
syntax C# uses for implementing interfaces. However I disagree that C# can't
do this. It is perfectly capable of delegating interface method calls to
member classes... I think you mean delegating the method call to a method of
a *contained* class (rather than nested class, right?). Anyway, again, C# is
perfectly capable of doing this.
Missing Interface Extensions
Example please? Are you assuming that you can't define Interfaces in C#?
That's what this is reading like, and that certainly isn't true at all. C#
allows you to write classes, abstract classes, AND stand-alone interfaces.
Interfaces in C# have no implementation and are not tied to a class
definition, so I'm confused at what you mean in your statement. Class
inheritance is NOT the only means of polymorphism in C#. That is also an
incorrect statement. You can certainly implement interfaces and create
interfaces. Please clarify this point, because I don't think you understand
what C# is doing here.
Source File Layout
[The lack of seperate and explicit definitions, aka header files]
promotes an unstructured coding style and often leads to bugs that are not
immediately obvious without reading the automatically generated
documentation.
I'm not sure I agree with this. What type of bugs are we talking about here
and how do we know this happens often? If you make an assertion, you are
going to have to back it up or qualify it. You may *prefer* to have header
files for various reasons, but you shouldn't make a blanket statement about
bugs without having data to prove it, or at the very least giving a good
example (or more) of what types of bugs we're dealing with here. I also
think you are going to have to explain why header files are better in your
opinion than documentation... in a sense, they are both being viewed here as
documentation here, and both are nothing but text at this point.
-Rob Teixeira [MVP]
With templates and generics, Complex<float> becomes a type of it's own, just
like Object or float. Therefore there's no reason why Array<Complex<float>>
wouldn't work. If you have an Array<T>, then T can certainly be passed
Complex<float>.
I think you're getting parameter and argument confused. The generic type
argument CAN be a generic type.
The generic type parameter cannot be a generic. For example, in C++
templates you can define a class such as this:
template < template < class A > class B >
class MyTemplateTemplateClass {
};
I've never used this, and many C++ compilers don't even support it.
Microsoft's didn't until very recently.
I've seen a few good uses of these in C++, but I can't honestly think of how
it would be useful in C# (at least with generics being implemented as they
are in C#).
And to do Array<Complex<float>> in C++ you don't need a template template
parameter.
--Matthew W. Jackson
"christopher diggins" <cd******@videotron.ca> wrote in message
news:DZ**********************@weber.videotron.net. ..
"Andreas Huber" <ah****@gmx.net> wrote in message
news:40**********@news.bluewin.ch... Thanks to all for your time and input.
AFAICT, array<complex<float>> will be legal ("although constructed types
may be used as generics").
Regards,
Andreas
In C#, a generic type parameter cannot itself be a generic, although
constructed types may be used as generics. What is a complex<float> if it
is not a generic? Truthfully I don't have a clue what they mean by
"constructed type".
--
Christopher Diggins
yet another language designer
http://www.heron-language.com
christopher diggins <cd******@videotron.ca> wrote: In fact, a reference can't be const - only a variable can be const, and
the only type of reference variable that can be const is a string one.
Quote from MSDN :
The const keyword is used to modify a declaration of a field or local
variable. It specifies that the value of the field or the local variable
cannot be modified
...
One of the types: byte, char, short, int, long, float, double, decimal,
bool, string, an enum type, or a reference type.
http://msdn.microsoft.com/library/de...us/csref/html/
vclrfconstpg.asp
This would seem to contradict you.
Slightly. Of course, you didn't keep quoting to:
<quote>
Therefore, the only possible values for constants of reference types
are string and null.
</quote>
So yes, although I was slightly wrong, I think in practice the only
type of reference variable that is *usefully* const is a string one, as
everything else would have to be null.
Const is for constants, and constants aren't the same as immutable
objects.
A const variable is an immutable variable though an immutable
variable is not neccessarily const. Do you not agree with me on that one?
Yes. const fields are much more restricted than just readonly variables
though. const
Nonetheless, I still stand by my statement as in the critique.
Unless I'm mistaken, the actual wording of your statement has now
changed anyway...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Why not? I heard that this was coming sometime, 2.1 then? We need the
ability to embed an assembly into anotiher assembly (.exe).
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:Oe**************@TK2MSFTNGP09.phx.gbl... As I told you before C# 2.0 doesn't have .lib and static linking. Static
linking involves a native code compiler and a linker, these are the domain
of C++.
Willy.
<di********@discussion.microsoft.com> wrote in message
news:O7****************@TK2MSFTNGP10.phx.gbl... As for preprocessors, theyre evil, hard to debug and just not good in
any way to have mixed compiled code.
I prefer to use a const value rather than conditional compile, at least
C# has reduced this need by having defines limited to true or false values,
still I would prefer it not there at all.
The lack of .lib static linking was a bad thing to not have, thankfully
its
back in 2.0.
"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in message
news:en**************@TK2MSFTNGP10.phx.gbl... With templates and generics, Complex<float> becomes a type of it's own,
just like Object or float. Therefore there's no reason why
Array<Complex<float>> wouldn't work. If you have an Array<T>, then T can certainly be passed
Complex<float>.
I think you're getting parameter and argument confused. The generic type
argument CAN be a generic type.
The generic type parameter cannot be a generic. For example, in C++
templates you can define a class such as this:
template < template < class A > class B >
class MyTemplateTemplateClass {
};
I've never used this, and many C++ compilers don't even support it.
Microsoft's didn't until very recently.
I've seen a few good uses of these in C++, but I can't honestly think of
how it would be useful in C# (at least with generics being implemented as they
are in C#).
And to do Array<Complex<float>> in C++ you don't need a template template
parameter.
--Matthew W. Jackson
How silly of me to confuse arguments and parameters! Thank you very much.
Now I understand.
--
Christopher Diggins
yet another language designer http://www.heron-language.com
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... GC:
Problem #2 : Unsafe contexts. There is a problem of being able to modify managed types. This significantly undermines the effectiveness of a GC and renders all
unsafe code as potentially having classes of errors which are normally removed by a GC
mechanism. From the language specification :
There are certainly issues that can come up from misuse of unsafe code.
The example you cited from the MSDN talks about strings, for example. Strings
are immutable types in the CLI/CLR, which allows the CLR to do
optimizations. For example, assigning one string ref to another doesn't
copy the contents. Since the runtime knows strings shouldn't change, both
references point at the same character array until one is assigned to a
different value. If you use unsafe code with one ref, and change the
value, you are inadvertantly changing another string ref's data as well, which
could cause a series of bugs. However, this in no way affects the GC. The
objects themselves live on the managed heap, and the GC will eventually
get around to cleaning them. I *strongly urge* you to read up on the GC and
how it works internally. Having said that, let's look at a problem with our
string scenario that can't be solved without unsafe or unmanaged code -
let's say you create one string variable and decrypt cipher data into it
containing a password (or any secret bit of info - credit card number,
etc.). You do what you need to do in your function, and when the function
ends, your string variable goes out of scope. The string is now elegible
for collection. However, you have no idea how long it will remain in memory.
It's possible that it's there for some time, and let's say it gets paged
out. Now, a clever hacker can sniff through your page file for secret
data, and it will show up. Programmers who are wary of security concerns need to
wipe secrets out of memory as quickly as possible. Knowing that there is
only ever one reference to the string, there is no reason I can't pin that
string, and using unsafe or unmanaged code, zero it out. You may not like
unsafe code, and it does have the potential of burning developers who
don't know what they're doing, but it does have its legitimate uses. Remember
that you can turn off this feature by not allowing the compiler switch to be
used by your development team. C# will not compile unsafe code by default. You
do not mention that in your text.
I think I shouldn't confuse the compiler with the language spec. The
language spec clearly talks about unsafe contexts. What a compiler defaults
to is not a concern IMO. I agree on a whole that unsafe code has its uses.
And we both agree that it can burn developers who don't know what they are
doing (or who work with such people, etc.). The fact that a feature can be
unallowed (and of course not used) is true for almost any dangerous feature,
with the right compiler / pre-processor tool. But this does not negate my
critique of the feature in the first place. I also don't think I suggest
that modifying unmanaged code affects the GC. I am trying to indicate that
it undermines the role of the GC to provide a memory protection mechanism.
Are you saying that there should only be either all value types or all
reference types? If so, which one would you use? Languages like Java use
exclusively reference types (except for special case primitives) because
it is the most flexible type. However, if you kept all reference types, then
you'd have nothing but types that fit your "perforance penalties". On the
other hand, value types have an enormous number of limitations compared to
reference types, so I can't even fathom a language with all value types.
What's your alternative?
My alternative would that all types can be both value types and reference
types much like C++.
Also, the managed heap doesn't suffer from memory fragmentation like heaps
from certain other languages do. Use of the GC allows all memory to be
allocated sequentially. As objects get collected, the space is compacted
by generation. However, let's pretend for a minute this isn't the case. How
does using a non-reference type change the way the heap is used? You are
still allocating and cleaning out memory, and you'd still be leaving
fragments of unallocated space. I don't quite understand this bullet
point, or the next one.
Stack allocation is in a fixed location, the same memory is used over and
over again, with no gaps in between.
Finally, if you are using a system that has no reference
types, how can you have references that point to the same data? Would you
have to copy all your data EVERY time? How would you synchronize instances
to maintain semantics of assignment? Wouldn't that suck for performance?
Special Primitives and Immutabilty
"a const field is a compile-time constant"
You still haven't answered my question about how you would allow reference
types (or other user-defined types) to have this behavior. This is where
we need to develop the syntax that allows programmers to specify literal
values for what could be relatively complex object graphs, THEN on top of that,
the compiler needs to have a mechanism to store this data in the program AND
reconstitute it at runtime. Then we run into the problem of read-only
(which C# can do) vs. immutability. If you reconstitute the value at runtime by
normal instantiation, you are only creating a read-only value (which C#
can already do). If you reconstitute the value in a truly const manner, you
effectively bypass constructors, which is disasterous. This is why all
languages i can think of don't allow this. If you are suggesting that C#
is doing something that is less than ideal, what is your ideal solution?
C# does not support delegating interface implementations to member classes. This significantly restricts the ability to use interfaces extensively.
Example? I'm not entirely disagreeing with you, but I'm wondering if we
are exaggerating the problem by using "extensively"?
If I wanted to "extensively use" interfaces I would be writing hundreds or
even thousands of implementation delegation functions.
The reason I'm not disagreeing entirely is that i'm not exactly fond of
the syntax C# uses for implementing interfaces. However I disagree that C#
can't do this. It is perfectly capable of delegating interface method calls to
member classes... I think you mean delegating the method call to a method
of a *contained* class (rather than nested class, right?). Anyway, again, C#
is perfectly capable of doing this.
Ah, yes. This will be important for me to differentiate.
Missing Interface Extensions
Example please? Are you assuming that you can't define Interfaces in C#?
That's what this is reading like, and that certainly isn't true at all. C#
allows you to write classes, abstract classes, AND stand-alone interfaces.
Interfaces in C# have no implementation and are not tied to a class
definition, so I'm confused at what you mean in your statement. Class
inheritance is NOT the only means of polymorphism in C#. That is also an
incorrect statement. You can certainly implement interfaces and create
interfaces. Please clarify this point, because I don't think you
understand what C# is doing here.
I did not say nor intend to suggest that class inheritance is the only kind
of polymorphism. I am trying to point out a feature which would adds
significant expressiveness to interfaces but is missing. This feature only
exists in Heron as far as I know. I wrote a short paper about extensions at
http://www.heron-language.com/extensions.html. To summarize my viewpoint :
an extension allows an interface to perform even more like an abstract base
class. Adding it would allow code to use interfaces even more instead of
having to resort to abstract base classes in certain design scenarios. Is
this more clear? Any suggestions on how I can clear up things here?
Source File Layout
[The lack of seperate and explicit definitions, aka header files]
promotes an unstructured coding style and often leads to bugs that are
not immediately obvious without reading the automatically generated
documentation.
I'm not sure I agree with this. What type of bugs are we talking about
here and how do we know this happens often? If you make an assertion, you are
going to have to back it up or qualify it. You may *prefer* to have header
files for various reasons, but you shouldn't make a blanket statement
about bugs without having data to prove it, or at the very least giving a good
example (or more) of what types of bugs we're dealing with here. I also
think you are going to have to explain why header files are better in your
opinion than documentation... in a sense, they are both being viewed here
as documentation here, and both are nothing but text at this point.
-Rob Teixeira [MVP]
I just touched this bit up. Between you and me what I am trying to get at
are situiations like where because all of the member fields are not obvious
a programmer can accidentally add an extra field for the same purpose as one
that already exists because they forgot it was there, asnd the same thing
for functions. Forgetting where in the design they are, etc. Little silly
things like that that are easily recoverable.
Excellent points Rob! I have adjusted some of the points you mentioned to
try and make them more technically accurate and more clear. Maybe I will
have a critique that is actually worth something sometime soon.
--
Christopher Diggins
yet another language designer http://www.heron-language.com
I'd just like to butt-in on question 12, public fields. One of my favourite
C++ questions (with no right or wrong answer) is: "given that we don't like
public data fields, and given that the people who implement STL libraries
are pretty smart, why is pair<A, B> generally implemented with two public
data fields?"
"christopher diggins" <cd******@videotron.ca> wrote in message
news:HO******************@weber.videotron.net...
"William Ryan" <do********@nospam.comcast.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 1) Unsafe Code - Sometimes you need it, plain and simple.
Then I would argue it illuminates weakness in the language to begin with.
2) Attributes - Huh? Take for example FileIOPermission attribute...you
can mark 10 different directories with only Read permissions thereby
eliminating the need for checking hardcoded values and ugly branch logic before
reading or writing a file.
You haven't eliminated ugly branch logic. It is just hidden in the
attribute. Because something has been moved into a library and looks
pretty is not sufficient. There are other attributes that people write that are a
complete mystery making understanding someone else's code a real headache
because the branch logic is no longer apparent.
I could go on and on about this, but I think you are way
off base here. And you aren't forced to use them...I bet there are tons of .NET developers that barely know they exist for God's sake.
Yes, but when they use them wrongly it is the biggest nightmare you can
imagine. (i.e. My code doesn't work, oh I see the problem this harmless
little attribute is written wrong).
3- Garbage Collection - Yes, all of the benefits you get from Managed
code aren't totally free.
Yep. And some of us just plain don't want a GC. Hence the title, "Why I
don't use C#"
4- Allows non-deterministic destructors - If you dispose of your objects
when you are done with them, I'm not sure what the problem is. What
problem is this causing you?
The destructor gets called when the Garbage collector deallocates the
memory. When will that happen?
5- Type/Reference Types.... Dude, there's so few value types I could
recite them off the top of my head. That's hardly a chore and so simple most
college CS freshman would love to have that as a Question on a test
As far as Objects can't exist on the stack....that's part and parcel to
your other complaint
Plus user defined structs.
7-Mutability - Ok, but what does that stop you from doing? Couldn't you
use Attributes to set the objects value and not provide accessors to change
it?
A guarantee of immutability of object across functions and modules is
important for designing well behaved and correct software.
8-Class as Modules and Programs - <<A static class with only static data
and static methods should either be a module or a program.>> Why?
Okay, I definitely don't have enough ammo to back this one up.
9-Polymorphism - Why can't you use multiple Interfaces?
You can, but you have to redeclare every function in every class that
implements an interface. That can quickly become really unmaintainable
with sophisticated interfaces.
10-Generics and Missing Templates.... ok, they didn't get everything up
front, but if you want to use it, use it, if not, don't. Would it be better for them to not provide this functionality? What if you were just
starting C# programming with the advent of 2.0 and didn't have legacy code?
Wouldn't you want generics?
I am just saying that they missed the boat, and are now grafting it on
painfully with some important features missing.
11- Source File Layout - Can't you get all of that information via
reflection or using the CodeModel?
Yes you can. I meant parsing as in reading source code is hard to do.
12 - Public Fields---Not if you don't do it. Is it really Microsoft's
responsibilty to ensure that every programmer doesn't violate the rules
of OOP?
A language has a responsability to try and make it difficult to write bad
code.
Besides, if they tried stopping this, there'd be so many VB
Programmers screaming bloody murder it wouldn't be funny.
Replace them all with properties I say (public fields not the VB
Programmers)
And while I
believe that you shouldn't break encapsulation, there are lots of people
that have...or have inherited code from people that did and prohibiting
it would impede adoption. Say what you want about MS, they bend over
backwards to support legacy code.
C# is a new language, it doesn't need to support legacy code. It is
incompatable with all other languages.
Special Primitives - Once again, so what?
I can't write my own.
13- Is it a field..
If it were a function, you'd see the () around it. Go ahead and try, if
you don't put the parens around it, it won't compile. As testimony to this,
go see how many VB Programmers constantly complain about forgetting the
parens when they call ToString without the Parens.
What I am referring to is that assigning to a property behind the scenes
can map to a Set function call.
And finally, other than the issue of unsafe code which VB.NET doesn't
support, aren't all of these related to the CLR and the Framework rather
than C#?
Nope. All of these issues are part of the C# specification.
--
Christopher Diggins
yet another language designer
http://www.heron-language.com
No problem.
I too would have been pissed if C# wouldn't support Array<Complex<float>>.
Of course, I'm pretty sure that a generic Complex class in C# will require a
second type parameter in order to support numeric operations on the type,
but that's another matter. At first it bothered me, until I came across an
elegant solution involving a helper class to do the arithmetic. Then I came
across an even more elegant solution involving a Generic abstract class to
emulate template-specialization, but that's off topic for this discussion so
I'll leave it at that.
--Matthew W. Jackson
"christopher diggins" <cd******@videotron.ca> wrote in message
news:pM*****************@weber.videotron.net... "Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in
message news:en**************@TK2MSFTNGP10.phx.gbl... With templates and generics, Complex<float> becomes a type of it's own,
just like Object or float. Therefore there's no reason why
Array<Complex<float>> wouldn't work. If you have an Array<T>, then T can certainly be passed
Complex<float>.
I think you're getting parameter and argument confused. The generic
type argument CAN be a generic type.
The generic type parameter cannot be a generic. For example, in C++
templates you can define a class such as this:
template < template < class A > class B >
class MyTemplateTemplateClass {
};
I've never used this, and many C++ compilers don't even support it.
Microsoft's didn't until very recently.
I've seen a few good uses of these in C++, but I can't honestly think of
how it would be useful in C# (at least with generics being implemented as
they are in C#).
And to do Array<Complex<float>> in C++ you don't need a template
template parameter.
--Matthew W. Jackson
How silly of me to confuse arguments and parameters! Thank you very much.
Now I understand.
--
Christopher Diggins
yet another language designer
http://www.heron-language.com
"Stu Smith" <st*****@remove.digita.com> schrieb im Newsbeitrag
news:eO**************@TK2MSFTNGP12.phx.gbl... I'd just like to butt-in on question 12, public fields. One of my
favourite C++ questions (with no right or wrong answer) is: "given that we don't
like public data fields, and given that the people who implement STL libraries
are pretty smart, why is pair<A, B> generally implemented with two public
data fields?"
Uuuh...Performance? But wait! What was the Jit good for?
Yes, it can automatically inline calls to Properties. So what?
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> - unsafe code
You have to place the unsafe-modifier in front of Methods that use unsafe
code
and compile with /unsafe that unsafe code is accepted, what else do you
want?
When using Interop some Functions called from native dll's returns their
results in form
of pointers so what would you do without pointers in c#? - attributes
They can give the Compiler lots of Information about an Method, Optimization
hints,
and so on. Some Attributes are good for the Windows Forms Designer, an
Attribute
can tell it Wheather a Property should displayed in the Toolbox or not.
- garbage collection
You contradict yourself. What do you want? Unsafe code where you have to
free the
memory manually or Automatically? Thanks to GC memory allocation is much
faster
than in C/C++.
- non-deterministic destructors
Deterministic destructors are good for deallocating native resources only.
Theoretically
they could make dtors of value-types deterministic, but they don't. I don't
know why.
- Objects can't exist on the stack
You remember what happened in C++ when you declare an Object on the Stack,
store its Reference and use it elsewhere? Right, a GPF or undefined
behaviour.
- Type / Reference Types
- An extra word is always needed for the pointer
Why word? Why "extra". A Reference in C# comsumes exactly the same space as
a
Reference in C++ does. 4 Bytes.
- There are more allocations on the heap than are strictly neccessary
leading to memory fragmentation
Thanks to Mark&Sweep GC there is *no* memory fragmentation.
- Dereference of pointer penalty
Better than to always passing the whole object on the Stack.
- Boxing / Unboxing
What is better?
Console.WriteLine("{0} + {1} = {2}", a, b, c);
or
Console.WriteLine("{0} + {1} = {2}", new Integer(a), new Integer(b), new
Integer(c));
- Mutability
Huh? You can make very class or struct immutable when you declare no methods
that
can modify the state of the object. Thats what they did with System.String
for example.
- Classes as Modules and Programs
Maybe it could useful for allday use function like abs, sin, cos. But
misused leads to
programs that only have loose functions which aren't encapsulated in a
class.
At the end, you have prodedural programming is that what you want?
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
Huh?
- C# Missing Template Template Parameters
If that is really true, I'll hate them for that.
- Late Added Generics
Yes Indeed. The whole class-Library could have been done better with
Generics.
- Source File Layout
Isn't that what an automatically generated helpfile is good for? I hated it
in C++ where
I always when I wanted to modify a method's signature I had to do it in two
locations.
This was always very annoying.
- Public Fields
Sometimes you make Ad-Hoc code to see if it works the way you though. It
would
be annoying that I must declare every field in a class as a property. Our
app has some
classes with over 40 public field. Making them all a property which does
nothing than
returning and setting that variable would be very stupid, it gains nothing
but bloating code.
- Special Primitives
You can declare you own datatype in C# and make it feel real with operator
overloading.
For example you could declare a 24-Bit Integer and use it exactly as you
would be using an int.
- Is it a Property or is it a field?
You don't have to know that. Why? This is the implementor's concern. If
there is a
property "Color" you know that it can set or get the "Color". Does it matter
how it is
Implemented?
o.x = y;
can mean very different things depending on the following conditions :
Is x or y a property or variable?
[...]
Is o an object reference or a struct value?
The question is: Does that matter? You know what you have to know: You are
assigning y to o.x. All other things are implementation details that should
not be exposed.
- Microsoft
Yes. That is the biggest reason for me to hate C#. But for all other Reasons
I love C#.
One last question: What is your favourite programming language(s)?
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> What is it about my brain? I am having trouble expressing the whole non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
The whole const-stuff in C++ is stupid. Classes should be self-contained,
and therefore everybody should be able to modify them safely. This is
real-world,
or do you know objects in the real world that are constant? :)
Maybe in C++ it was neccesary due to the whole pointer-stuff and so on but
in other
languages it is not.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> *** NO MULTIPLE INHERITANCE ***!!!
Biggest fault of C# in my opinion.
If you can state only one example where multiple nheritance is required I'll
believe you,
otherwise not. Multiple Inheritance is just bad style used by poor
programmers.
All Multiple Inheritance scenarios are best solved using composition
instead.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
Stu Smith wrote: I'd just like to butt-in on question 12, public fields. One of my
favourite C++ questions (with no right or wrong answer) is: "given
that we don't like public data fields, and given that the people who
implement STL libraries are pretty smart, why is pair<A, B> generally
implemented with two public data fields?"
Because the pair is a generic container for two values. The two data members
of the pair don't have anything to do with eachother (even if they had, the
clients of the pair wouldn't want/need know about it). There are no
preconditions, post conditions and invariants to enforce. Consequently,
there are no getter/setter accessors because that would not add anything.
Regards,
Andreas
codymanix wrote: *** NO MULTIPLE INHERITANCE ***!!!
Biggest fault of C# in my opinion.
If you can state only one example where multiple nheritance is
required I'll believe you,
otherwise not. Multiple Inheritance is just bad style used by poor
programmers.
All Multiple Inheritance scenarios are best solved using composition
instead.
Please then tell me how to implement an indirect visitor in C++ without MI
(I'm sure google'll give you all you need to know).
Regards,
Andreas
codymanix wrote: What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
The whole const-stuff in C++ is stupid. Classes should be
self-contained, and therefore everybody should be able to modify them
safely. This is real-world,
or do you know objects in the real world that are constant? :)
Maybe in C++ it was neccesary due to the whole pointer-stuff and so
on but in other
languages it is not.
Oh, yet another ingenious insight! http://www.research.att.com/~bs/blast.html
I'm afraid the "pointer-stuff" has not much to do with whether const makes
sense or not. It is also worth noting that there is an experimental C#
compiler supporting const (Rotor I think) and that most experts would rather
see const back in Java and C#. Reference types with value-type semantics
(e.g. string) would benefit from const (performance-wise).
Regards,
Andreas
codymanix wrote:
[snip] - non-deterministic destructors
Deterministic destructors are good for deallocating native resources
only. Theoretically
they could make dtors of value-types deterministic, but they don't. I
don't know why.
Boxing.
Regards,
Andreas
codymanix <do*********************@gmx.de> wrote: What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
The whole const-stuff in C++ is stupid. Classes should be self-contained,
and therefore everybody should be able to modify them safely. This is
real-world, or do you know objects in the real world that are constant? :)
This really doesn't hold up at all.
For instance, it's handy to be able to return an array from a method,
some times - the array could fundamentally be part of the instance's
state. However, I want the contents of that array to be effectively
read-only, so that the caller can't tamper with the state of the class
just by using:
byte[] data = instance.StateData;
data[0] = 15;
Const-correctness would prevent that (and many similar problems, mostly
to do with collections).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I have questions for you. Please see below.
"codymanix" <do*********************@gmx.de> wrote in message
news:ec**************@TK2MSFTNGP12.phx.gbl... What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
The whole const-stuff in C++ is stupid.
If const-correctness is stupid, does that make it stupid in all of its
forms? For example: are read-only properties and fields stupid? Are you
saying that C# should remove the partial implementation of
const-correctness-support that it already has?
Would support for const-correctness not benefit the class-system designer by
giving him (or her) a whole new degree of control over the users of his
classes? Doesn't const-correctness allow for faster code by removing the
need for unnecessary copies?
Classes should be self-contained,
and therefore everybody should be able to modify them safely. This is
real-world,
or do you know objects in the real world that are constant? :)
What real-world objects are "self-contained?"
If you are thinking of animals, what animal can be safely modified without
restriction?
Which computer programs or class-systems are perfect models of the real
world?
Aren't there objects that cannot be significantly modified by some other
objects? For instance: how could you or I significantly alter the shape of
our galaxy?
Maybe in C++ it was neccesary due to the whole pointer-stuff and so on but
in other
languages it is not.
You hurt my feelings when you refer to C++ in the past tense. It's going to
make a comeback. If C# 2.0 were going to allow for multiple inheritance one
could say it already has.
-- Max
C++ over time has become a language of kludges and fixes that the developer
has to code because the compiler is badly designed in the first place.
"Max Guernsey" <ma**********@harbingersoftware.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... I have questions for you. Please see below.
"codymanix" <do*********************@gmx.de> wrote in message
news:ec**************@TK2MSFTNGP12.phx.gbl...
What is it about my brain? I am having trouble expressing the whole
non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
The whole const-stuff in C++ is stupid.
If const-correctness is stupid, does that make it stupid in all of its
forms? For example: are read-only properties and fields stupid? Are you
saying that C# should remove the partial implementation of
const-correctness-support that it already has?
Would support for const-correctness not benefit the class-system designer
by giving him (or her) a whole new degree of control over the users of his
classes? Doesn't const-correctness allow for faster code by removing the
need for unnecessary copies?
Classes should be self-contained,
and therefore everybody should be able to modify them safely. This is
real-world,
or do you know objects in the real world that are constant? :)
What real-world objects are "self-contained?"
If you are thinking of animals, what animal can be safely modified without
restriction?
Which computer programs or class-systems are perfect models of the real
world?
Aren't there objects that cannot be significantly modified by some other
objects? For instance: how could you or I significantly alter the shape
of our galaxy?
Maybe in C++ it was neccesary due to the whole pointer-stuff and so on
but in other
languages it is not.
You hurt my feelings when you refer to C++ in the past tense. It's going
to make a comeback. If C# 2.0 were going to allow for multiple inheritance
one could say it already has.
-- Max
<di********@discussion.microsoft.com> wrote in message
news:u9**************@TK2MSFTNGP09.phx.gbl... C++ over time has become a language of kludges and fixes that the
developer has to code because the compiler is badly designed in the first place.
Wow! I have never heard it stated quite so eloquently. I've been looking
for someone like you. I only have one question:
Where do I ship the time machine you're going to use to go back and make
sure that C++ was designed properly? Please make sure that it didn't have
templates so that we dinosaurs are lucky enough to have to sprinkle our code
with typecasts like you advanced C# programmers. Also, if you have time,
can you see to it that multiple-inheritance was replaced by interfaces so
that I can spend my life retyping the same method over and over?
Thanks in advance.
And modern C++ compilers can generally inline small functions.
As Andreas said in the next post, it's because pair is one of those classes
that everything is know about; there is nothing to check, no unknown future
uses. In certain cases there are classes like that, and that's (one of the
reasons) why C# and C++ don't disallow public data members.
Why have several lines when two will do?
"codymanix" <do*********************@gmx.de> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "Stu Smith" <st*****@remove.digita.com> schrieb im Newsbeitrag
news:eO**************@TK2MSFTNGP12.phx.gbl... I'd just like to butt-in on question 12, public fields. One of my
favourite C++ questions (with no right or wrong answer) is: "given that we don't
like public data fields, and given that the people who implement STL
libraries are pretty smart, why is pair<A, B> generally implemented with two
public data fields?"
Uuuh...Performance? But wait! What was the Jit good for?
Yes, it can automatically inline calls to Properties. So what?
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
> The whole const-stuff in C++ is stupid. Classes should be self-contained, and therefore everybody should be able to modify them safely. This is
real-world,
or do you know objects in the real world that are constant? :)
I've missed the first part of this discussion, so forgive me if someone has
already said this:
One of the really useful reasons to be able to specify that a function does
not change one of its operands is for self-documentation.
In C++, if you see that a function argument is declared with a const-ref
operand, you need look no further to know that calling that function will
not change the operand. (I'm ignoring erroneous code which casts away the
const in the function - such code is buggy).
In C#, whenever I pass a reference-type to an unfamiliar function, I need to
consult the documentation and/or inspect the function's implementation in
order to determine whether the operand may be changed.
What's more, if I am the implementer of such a function, I can easily forget
and change the operand. If it could be const, then the compiler wouldn't
allow you to.
Now I realise that you can argue that you should always fully consult the
documentation for any function. But the lack of const can make you have to
search more of the code, particularly in the face of incomplete or possibly
out-of-date documentation. Even worse, the documentation may say that the
function doesn't change it's operand - and that may well have been true when
the documentation was written. Alas, a later maintenance programmer has
optimised the code in the function somewhat, and as a side-effect has
changed the operant. Blam! There's a bug that would instantly be caught if
you had constant operands.
As another example, suppose you were looking at some code that used a Matrix
class. You come across this function:
Matrix m1 = new Matrix( 4, 12 );
....
Matrix m2 = invert_matrix( m1 );
You consult the documentation and find that it says: "invert_matrix returns
the inverse of the specified matrix". And that's about it (about from some
info about possible exceptions and un-invertable matrices). Now, of course,
you have to go and inspect a load of complicated matrix-inversion code just
to see if the operand is changed.
You see, it's all about code clarity and self-documentation.
But what exactly did you hear?
Also note that assemblies cannot hold other assemblies, and assembly is the
unit of deployment that consists of one or more modules (NOT assemblies).
Why would you need to embed an assembly into another?
The only possibility to build multiple module assemblies now, is by using
the command-line build tools, the upcomming version of VS will add this
function to the IDE.
But again this has nothing in common with static linking.
Willy.
<di********@discussion.microsoft.com> wrote in message
news:u5****************@TK2MSFTNGP10.phx.gbl... Why not? I heard that this was coming sometime, 2.1 then? We need the
ability to embed an assembly into anotiher assembly (.exe).
"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:Oe**************@TK2MSFTNGP09.phx.gbl... As I told you before C# 2.0 doesn't have .lib and static linking. Static
linking involves a native code compiler and a linker, these are the
domain
of C++.
Willy.
<di********@discussion.microsoft.com> wrote in message
news:O7****************@TK2MSFTNGP10.phx.gbl... > As for preprocessors, theyre evil, hard to debug and just not good in any > way to have mixed compiled code.
>
> I prefer to use a const value rather than conditional compile, at least C# > has reduced this need by having defines limited to true or false
> values,
> still I would prefer it not there at all.
>
> The lack of .lib static linking was a bad thing to not have, thankfully
> its
> back in 2.0.
>
> > > What is it about my brain? I am having trouble expressing the whole non-constness thing. What I mean to say is that I can't have a const
instance of a type. Even though the reference itself can be const.
The whole const-stuff in C++ is stupid. Classes should be
self-contained, and therefore everybody should be able to modify them safely. This is
real-world, or do you know objects in the real world that are constant?
:)
This really doesn't hold up at all.
For instance, it's handy to be able to return an array from a method,
some times - the array could fundamentally be part of the instance's
state. However, I want the contents of that array to be effectively
read-only, so that the caller can't tamper with the state of the class
just by using:
byte[] data = instance.StateData;
data[0] = 15;
Const-correctness would prevent that (and many similar problems, mostly
to do with collections).
As I said, const correctness is only useful with not fully selfcontained
like pointers, arrays and so on.
in C# you would write an accessor method which supports only get to retrieve
the array's values:
int this[int index]
{
get {return a[index];}
}
Iam still waiting for the time where C# will support named indexers like in
VB.
--
cody
Freeware Tools, Games and Humour http://www.deutronium.de.vu
[noncommercial and no fucking ads]
> > If you can state only one example where multiple nheritance is required I'll believe you,
otherwise not. Multiple Inheritance is just bad style used by poor
programmers.
All Multiple Inheritance scenarios are best solved using composition
instead.
Please then tell me how to implement an indirect visitor in C++ without MI
(I'm sure google'll give you all you need to know).
Iam not sure yet was the "indirect visitor" pattern is but iam sure it can
be better
solved using composition or interfaces.
It would be great if you could explain me a little about "indirect visitor".
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> > If you can state only one example where multiple nheritance is required I'll believe you,
otherwise not. Multiple Inheritance is just bad style used by poor
programmers.
All Multiple Inheritance scenarios are best solved using composition
instead.
Please then tell me how to implement an indirect visitor in C++ without MI
(I'm sure google'll give you all you need to know).
Iam not sure yet was the "indirect visitor" pattern is but iam sure it can
be better
solved using composition or interfaces.
It would be great if you could explain me a little about "indirect visitor".
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> > The whole const-stuff in C++ is stupid. Classes should be self-contained, and therefore everybody should be able to modify them
safely. This is real-world,
or do you know objects in the real world that are constant? :)
Maybe in C++ it was neccesary due to the whole pointer-stuff and so
on but in other
languages it is not.
Oh, yet another ingenious insight!
http://www.research.att.com/~bs/blast.html
I'm afraid the "pointer-stuff" has not much to do with whether const makes
sense or not. It is also worth noting that there is an experimental C#
compiler supporting const (Rotor I think) and that most experts would
rather see const back in Java and C#. Reference types with value-type semantics
(e.g. string) would benefit from const (performance-wise).
Why would they benefit from const? Are you talking about immutable classes
or immutable objects now?
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> > The whole const-stuff in C++ is stupid. Classes should be self-contained, and therefore everybody should be able to modify them
safely. This is real-world,
or do you know objects in the real world that are constant? :)
Maybe in C++ it was neccesary due to the whole pointer-stuff and so
on but in other
languages it is not.
Oh, yet another ingenious insight!
http://www.research.att.com/~bs/blast.html
I'm afraid the "pointer-stuff" has not much to do with whether const makes
sense or not. It is also worth noting that there is an experimental C#
compiler supporting const (Rotor I think) and that most experts would
rather see const back in Java and C#. Reference types with value-type semantics
(e.g. string) would benefit from const (performance-wise).
Why would they benefit from const? Are you talking about immutable classes
or immutable objects now?
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> One of the really useful reasons to be able to specify that a function
does not change one of its operands is for self-documentation.
Normally you don't have to care wheather an object is changed or not since
all objects
should be self-contained.
As another example, suppose you were looking at some code that used a
Matrix class. You come across this function:
Matrix m1 = new Matrix( 4, 12 );
...
Matrix m2 = invert_matrix( m1 );
You consult the documentation and find that it says: "invert_matrix
returns the inverse of the specified matrix". And that's about it (about from some
info about possible exceptions and un-invertable matrices). Now, of
course, you have to go and inspect a load of complicated matrix-inversion code
just to see if the operand is changed.
Such things like arrays, matrices, lists and so on are generic containers
which are not
really selfcontained since they represent no real-world object. You can
always use a wrapper or only provide an indexer/enumerator that doesn't
allow changes.
the problem with const correctness is if you change your mind and want that
a method is able to change the parameter, you have to change all const
specifiers in the whole library and all dependent apps!
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> One of the really useful reasons to be able to specify that a function
does not change one of its operands is for self-documentation.
Normally you don't have to care wheather an object is changed or not since
all objects
should be self-contained.
As another example, suppose you were looking at some code that used a
Matrix class. You come across this function:
Matrix m1 = new Matrix( 4, 12 );
...
Matrix m2 = invert_matrix( m1 );
You consult the documentation and find that it says: "invert_matrix
returns the inverse of the specified matrix". And that's about it (about from some
info about possible exceptions and un-invertable matrices). Now, of
course, you have to go and inspect a load of complicated matrix-inversion code
just to see if the operand is changed.
Such things like arrays, matrices, lists and so on are generic containers
which are not
really selfcontained since they represent no real-world object. You can
always use a wrapper or only provide an indexer/enumerator that doesn't
allow changes.
the problem with const correctness is if you change your mind and want that
a method is able to change the parameter, you have to change all const
specifiers in the whole library and all dependent apps!
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
Cody -- wow, you must be incredible if you can make a statement such as: Multiple Inheritance is just bad style used by poor programmers.
MI *IS NOT* bad style, it is a language construct. Style, for the rest of the
world, is *independent of constructs*. If it weren't, we wouldn't have:
recursion
switch statements
global scope/variables
break/continue
return (except at the end of a function/method)
etc.
etc.
etc.
Statements like yours are the *VERY REASON* that MI and other constructs are
frowned upon. Rather than denigrating language features, you should redirect
your energy to elucidating on style for the benefit of all programmers, poor or
otherwise.
codymanix wrote: *** NO MULTIPLE INHERITANCE ***!!!
Biggest fault of C# in my opinion.
If you can state only one example where multiple nheritance is required I'll
believe you,
otherwise not. Multiple Inheritance is just bad style used by poor
programmers.
All Multiple Inheritance scenarios are best solved using composition
instead.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>
Cody -- wow, you must be incredible if you can make a statement such as: Multiple Inheritance is just bad style used by poor programmers.
MI *IS NOT* bad style, it is a language construct. Style, for the rest of the
world, is *independent of constructs*. If it weren't, we wouldn't have:
recursion
switch statements
global scope/variables
break/continue
return (except at the end of a function/method)
etc.
etc.
etc.
Statements like yours are the *VERY REASON* that MI and other constructs are
frowned upon. Rather than denigrating language features, you should redirect
your energy to elucidating on style for the benefit of all programmers, poor or
otherwise.
codymanix wrote: *** NO MULTIPLE INHERITANCE ***!!!
Biggest fault of C# in my opinion.
If you can state only one example where multiple nheritance is required I'll
believe you,
otherwise not. Multiple Inheritance is just bad style used by poor
programmers.
All Multiple Inheritance scenarios are best solved using composition
instead.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Long |
last post by:
How to include an HTML doc in another HTML doc
Problem: to insert the body section of an HTML doc in another HTML document
at a specific location.
One possible way is to add a WebCharm tag...
|
by: TC |
last post by:
Are there any good sites or forums for a web critique? I went to
alt.html.critique and it's pretty dead.
|
by: bowsayge |
last post by:
Inspired by fb, Bowsayge decided to write a decimal integer
to binary string converter. Perhaps some of the experienced
C programmers here can critique it. It allocates probably
way too much...
|
by: Eric |
last post by:
There is a VB.NET critique on the following page:
http://www.vb7-critique.741.com/
for those who are interested. Feel free to take a look and share your
thoughts.
Cheers, Eric.
Ps: for those...
|
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: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
