Roll your own std::vector ???

[Peter Olcott]

It's not necessary to learn "all" of anything. But being afraid to invest time
in a new skill is a sure way to make yourself extinct.

This year I learned Ruby. Do I have a shallow understanding of it? Perhaps.
But I bet it's deeper than yours.

///ark

I am starting a business on very limited resources and must work 40 hours every
day (16 more hours than there are in a day) to get enough done each day. That
tends to leave me with about 24 hours every day of less than no spare time at
all.

 

[Jon Skeet [C# MVP]]

I am starting a business on very limited resources and must work 40 hours every
day (16 more hours than there are in a day) to get enough done each day. That
tends to leave me with about 24 hours every day of less than no spare time at
all.

If your business is relying on the impossible to start with, is it
really realistically viable, whatever platform you use? Whatever you
do, you *cannot* work 40 hours a day, obviously - so either your
"must" is wrong, or you will fail. Logically, I can't see any other
option.

 

[Joanna Carter [TeamB]]

"Peter Olcott" <[email protected]> a écrit dans le message de Zx%[email protected]...

| Bjarne Stroustrup (the creator of C++) once said that he has not yet
learned all
| of C++ yet. Trying to learn a new computer programming language every year
would
| then necessarily result in a very shallow understanding.

Well C# only has 80 keywords, 54 operators and no need to understand
pointers and indirection; assuming that you already know the basic
programming constructs, that really isn't a lot to learn.

Having said that, mastering topics like generics has certainly taken me more
time than I had anticipated.

Joanna

 

[Chris Mullins]

| Bjarne Stroustrup (the creator of C++) once said that he has not yet
| learned all of C++ yet. Trying to learn a new computer programming
| language every year would
| then necessarily result in a very shallow understanding.

Well C# only has 80 keywords, 54 operators and no need to understand
pointers and indirection; assuming that you already know the basic
programming constructs, that really isn't a lot to learn.

Well, it's not really the keywords and operators that take a long time to
learn in any language.

In C++ the area that took me the longest to really wrap my head around was
the combination of multiple-inheritence and the STL - expecially as it
worked with and related to streams and the magic they can work.

In .Net, learning C# (or VB.Net) is (I think) pretty easy. Learning enough
about the 65K classes in the FCL to get things done efficiently has taken a
while.

In both languages, (if you were coming in cold) learning OO and how it works
would be (I believe) by far the biggest hurtle. The realization that you can
make your complex class (or set of classes) implement this silly little
interface (pick one: IEnumerable, IComparable, IClonable, IEquitable,
IPrincipal, etc, etc) and get all this great stuff to happen as a result is
quite a moment.

 

[Peter Olcott]

Well, it's not really the keywords and operators that take a long time to
learn in any language.

In C++ the area that took me the longest to really wrap my head around was the
combination of multiple-inheritence and the STL - expecially as it worked with
and related to streams and the magic they can work.

In .Net, learning C# (or VB.Net) is (I think) pretty easy. Learning enough
about the 65K classes in the FCL to get things done efficiently has taken a
while.

This is the huge learning curve that I am referring to. C# by itself is
essentially for the most part a subset of C++. The trickiest things that I have
not quite completely mastered about C# are those things pertaining to its
interface with the .NET architecture. I still don't understand why there is any
need for the boxing and unboxing stuff.

 

[Mark Wilden]

I am starting a business on very limited resources and must work 40 hours
every day (16 more hours than there are in a day) to get enough done each
day. That tends to leave me with about 24 hours every day of less than no
spare time at all.

I'm sure you have very strong reasons for this decision, and I wish you
luck!

///ark

 

[Peter Olcott]

I'm sure you have very strong reasons for this decision, and I wish you luck!

///ark

Its the culmination of twenty years worth of work. I am actively looking for a
marketing partner to delegate at least half this work to.

 

[Joanna Carter [TeamB]]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| This is the huge learning curve that I am referring to. C# by itself is
| essentially for the most part a subset of C++. The trickiest things that I
have
| not quite completely mastered about C# are those things pertaining to its
| interface with the .NET architecture. I still don't understand why there
is any
| need for the boxing and unboxing stuff.

If you go straight to .NET 2.0, you should never need to use boxing and
unboxing.

Joanna

 

[Marc Gravell]

If you go straight to .NET 2.0, you should never need to use boxing and

unboxing.

For rolling containers, agreed...

....unless you code against the component-model (e.g. providing dynamic
properties) or using reflection; for instance UI binding - in both
cases setters, getters and list access tends to be as "object", so
boxed for the value-type primatives.

I'm not disagreeing... just adding a caveat... ;-p

Marc

 

[Peter Olcott]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| This is the huge learning curve that I am referring to. C# by itself is
| essentially for the most part a subset of C++. The trickiest things that I
have
| not quite completely mastered about C# are those things pertaining to its
| interface with the .NET architecture. I still don't understand why there
is any
| need for the boxing and unboxing stuff.

If you go straight to .NET 2.0, you should never need to use boxing and
unboxing.

So boxing and unboxing was merely a design anomaly of the earlier versions?

 

[Peter Olcott]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| Of even better use the actual std::vector itself that is now available
with the
| currently released version of visual studio, that way I further still
reduce my
| learning curve. There are two reason why I don't want to upgrade yet, (1)
Price,
| (2) The exams refer to the older version.

I think you will find that List<T> should give you most of the functionality
you need. (1)You can get a copy of Visual Studio 2005 Express for free (2)
are you more interested in writing code and achieving results or passing
exams ?

Joanna

Thank you very much for this excellent advice. It looks like all of the Visual
Studio 2005 Express compilers include the optimizer and are free to be used
commercially. The C++ version includes STL .NET, and the C# version includes
generics.

Because most of the complexity has been stripped from these compilers while
still retaining the most useful functionality the learning curve is finally
minimized.

 

[Marc Gravell]

It looks like all of the Visual

Studio 2005 Express compilers include the optimizer and are free to be used
commercially. The C++ version includes STL .NET, and the C# version includes
generics.

[refers to C#; I have no clue about C++]
Strictly speaking, these products don't actually contain the compiler
at all... the compiler is part of the framework itself, so you actually
have *full* access to the compiler ("csc" for c#, etc) *just* by
installing the framework. At a push, all you need is notepad.
VS/VSExpress provide an IDE to make development more productive.

Marc

 

[Jon Skeet [C# MVP]]

So boxing and unboxing was merely a design anomaly of the earlier versions?

No. Boxing and unboxing are fundamental to the unified type system.

I disagree with Joanna's characterisation with regards to generics -
you should rarely if ever need to use boxing and unboxing for
collections, but there are plenty of other places where a method may
have a type of System.Object and call ToString on it, for instance.

Jon

 

[Peter Olcott]

No. Boxing and unboxing are fundamental to the unified type system.

I disagree with Joanna's characterisation with regards to generics -
you should rarely if ever need to use boxing and unboxing for
collections, but there are plenty of other places where a method may
have a type of System.Object and call ToString on it, for instance.

Jon

Can you explain the underlying details why boxing and unboxing are required, and
not merely unnecessary overhead?

 

[Joanna Carter [TeamB]]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| Can you explain the underlying details why boxing and unboxing are
required, and
| not merely unnecessary overhead?

Unlike reference types, value types are "optimised" to be held as their
expected native types (4 bytes, 2 bytes, etc) until they are needed as their
full System.Object derived type. When this transformation takes place, this
is known as boxing; taking an object reference to a value type and assigning
it to a "native" type is known as unboxing.

In effect, the following code happens :

{
int i = 123; // native type, 4 bytes, no methods or properties

string s = i.ToString();

// equivalent to
//
// Int32 = new Int32(i); // Int32 is a struct so boxing occurs here
// string s = Int32.ToString();
//

object o = i;

// equivalent to
//
// object o = new Int32(i);
//

int j = o;

// equivalent to
//
// int j = ((Int32) o).m_value; // pseudocode but unboxing occurs like
this
//
}

Joanna

 

[Peter Olcott]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| Can you explain the underlying details why boxing and unboxing are
required, and
| not merely unnecessary overhead?

Unlike reference types, value types are "optimised" to be held as their
expected native types (4 bytes, 2 bytes, etc) until they are needed as their
full System.Object derived type. When this transformation takes place, this
is known as boxing; taking an object reference to a value type and assigning
it to a "native" type is known as unboxing.

So the compiler designers couldn't figure out a way to provide the capability of
member functions to intrinsic types without a lot of extra overhead? It would
seem that all of this capability could easily be provided at compile-time with
no need for run-time overhead.

 

[Joanna Carter [TeamB]]

"Peter Olcott" <[email protected]> a écrit dans le message de [email protected]...

| So boxing and unboxing was merely a design anomaly of the earlier
versions?

No, it's still an essential part of .NET 2.0, it's just that it is no longer
required when creating typesafe collection classes. See my other post for an
explanation of where (un)boxing is still used.

Joanna

 

[Joanna Carter [TeamB]]

"Marc Gravell" <[email protected]> a écrit dans le message de (e-mail address removed)...

|> If you go straight to .NET 2.0, you should never need to use boxing and
| > unboxing.
| For rolling containers, agreed...
|
| ...unless you code against the component-model (e.g. providing dynamic
| properties) or using reflection; for instance UI binding - in both
| cases setters, getters and list access tends to be as "object", so
| boxed for the value-type primatives.
|
| I'm not disagreeing... just adding a caveat... ;-p

Caveat away, kind sir Good point. Although I have made some generic
extensions to the ComponentModel classes to avoid this where possible.

Joanna

 

[Jon Skeet [C# MVP]]

So the compiler designers couldn't figure out a way to provide the capability of
member functions to intrinsic types without a lot of extra overhead? It would
seem that all of this capability could easily be provided at compile-time with
no need for run-time overhead.

No, that's not it at all.

If you call (for instance) myInt.ToString() then boxing isn't involved.

However, if you want to provide a method which can call ToString on
*anything*, then the type of the parameter needs to be Object. As
Object is a reference type, you need a way to convert the integer value
into a reference type value - and that's what boxing does.

I suggest you read some good books on C# and .NET to understand why
it's a good thing to have both value types and reference types, and why
it's also useful to be able to create a reference type value from a
value type value in certain situations.

It's certainly *not* designer laziness.

Jon

 

[Peter Olcott]

No, that's not it at all.

If you call (for instance) myInt.ToString() then boxing isn't involved.

However, if you want to provide a method which can call ToString on
*anything*, then the type of the parameter needs to be Object. As
Object is a reference type, you need a way to convert the integer value
into a reference type value - and that's what boxing does.

I suggest you read some good books on C# and .NET to understand why
it's a good thing to have both value types and reference types, and why
it's also useful to be able to create a reference type value from a
value type value in certain situations.

It's certainly *not* designer laziness.

It would still seem like far less than the best possible design of all possible
designs. It still seems like run-time overhead that could have been done at
compile-time.