OK, so I know most intelligent people are tired of the MS bashing that 
goes on, but I still couldn't resist the title :)

Anyway, a few days ago I downloaded the free XNA studio* to give it a 
try.  I read a bit on C#** over the last couple of days, decided it 
might be worth trying out (it couldn't be worse than Java, and I gave 
*that* a try), and tonight fired up the studio to look through some of 
the tutorials and examples.

I must say, I'm quite impressed with a couple of things in it.

1) The project frameworks provided are incredibly robust and complete. 
Creating a new project from a template sets up a decent game framework 
that can be extended and customized with ease.  Game properties like 
framerate limits, constraints on video resolution, etc can be set with 
one line of code due to the layout of the data structure.  At best with 
C++ game libraries I've looked at, I've had to copy & paste not only 
several files of generic code to get a working app, but also hunt 
through the Project Settings to look out for anything that might cause 
problems.

2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
simply bring up the context menu and choose "Add Existing" or "Add New", 
give it a name (and select the file if it aleady exists), and it's 
imported into the correct directory.  Loading the resource in your code 
is as easy as one line, and you only specify the resource name as a 
handle - you don't have to worry about the actual file name or directory 
at all.

3) It "compiles" extremely quickly compared to C++.

4) The included documentation seems complete and informative.

In about 15 minutes, I had a bouncing ball and a framerate counter. 
Mind you, this is the first time I've *ever* done anything with either 
C# or XNA Studio.  It was very easy to get into, and I feel like I at 
least know where to look for everything I need.

This weekend I'm going to start work on a larger test project to see how 
it handles.  I'm interested to see how I respond to working on something 
larger, and if I'll remain as positive and hopeful after a few days with it.

*For those of you who are not aware, the XNA Studio is a special 
packaging of Visual Studio designed specifically for creating casual 
games on the XBox and Windows platforms.  Amateur game developers are 
allowed to upload their games to the XBox Live Marketplace, where anyone 
on Windows or an XBox can play them.  If I end up liking C#, then 
playing my games with friends will be one more reason to get an XBox 360.

**I won't comment on the language until I've used it a bit more.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> OK, so I know most intelligent people are tired of the MS bashing that
> goes on, but I still couldn't resist the title :)

Not everyone. :)

> 1) The project frameworks provided are incredibly robust and complete.
> Creating a new project from a template...

Incredible amounts of easy and ready-to-go templates and wizards are to be
expected from companies looking to attract developers for their platforms.

Open-source generally just provides the essential functionality and leaves it to
the user community to provide added value in the form of documentation,
tutorials, plugins and templates scattered through many websites... ;)

> 3) It "compiles" extremely quickly compared to C++.

*Anything* compiles extremely quickly compared to C++.  Just don't perform the
same.

Except, of course, if it really is a wrapper to underlying functionality written
in C/C++...

Post a reply to this message

Chambers wrote:
> OK, so I know most intelligent people are tired of the MS bashing that 
> goes on, but I still couldn't resist the title :)
...

So the ones that aren't tired of it aren't intelligent ?

;)

-- 
Tor Olav
http://subcube.com

Post a reply to this message

nemesis wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> 1) The project frameworks provided are incredibly robust and complete.
>> Creating a new project from a template...
> 
> Incredible amounts of easy and ready-to-go templates and wizards are to be
> expected from companies looking to attract developers for their platforms.

True, but it's still annoying to have to spend so much time to set up a 
project with other tools.

Like I said before, I want to see how I feel after doing something a 
little larger with it :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

nemesis wrote:
> *Anything* compiles extremely quickly compared to C++.  Just don't perform the
> same.

With JIT compilers and such, I'm not sure how you can be so sure. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > *Anything* compiles extremely quickly compared to C++.  Just don't perform the
> > same.
>
> With JIT compilers and such, I'm not sure how you can be so sure. :-)

Look for the top:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&binarytre
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1
with memory performance taken into consideration as well, it only gets worse:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=0&binarytre
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1

Yes, I'm aware theoretically a JITted program running for long should be able to
be extra tuned on the fly and drop irrelevant parts to run faster.  That isn't
reflected in the charts, of course.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > *Anything* compiles extremely quickly compared to C++.  Just don't perform the
> > same.

> With JIT compilers and such, I'm not sure how you can be so sure. :-)

  I have no idea about the principles used in C#, but if it's anything like
Java, the biggest problem is not so much speed as memory usage. In Java
I don't think there's any way around the problem that you cannot create
a data container where each element takes as much memory as the total size
of the members of the object, nothing more. The smaller the object is, the
worse the memory usage overhead relative to this size.

  I actually find it a bit worrying that it seems that no programming
language introduced in the last 20 years which has got some popularity
seems to offer any tools *whatsoever* to create memory-efficient programs
(at least not without resorting to really ugly code which bypasses nice
modular design).

  Many people will say "that doesn't matter, memory amount is increasing
all the time". However, that's only a valid point for programs which use
a *fixed* amount of memory for what they do. In other words, a program
which required a fixed amount of 500 megabytes of memory when written in
a memory-efficient way in C++ 10 years ago may well run ok when written
in Java with a modern computer which has 4 gigabytes of RAM.

  However, it's rather rare that a program uses a huge amount of memory,
and that this amount is somehow fixed. The more usual case is that memory
usage is dynamic, and having more RAM in the computer will allow the program
to perform more than before. In other words, that program which 10 years
ago could perform a certain task with 500 MB of RAM may well be able to
perform a much larger task in a computer with 4 GB of RAM, while the java
version will only be able to perform the same task as the 10yo computer.

  In other words, the same program written in Java will be able to do
less than the version written in C++. And often you just *can't* create
a Java version which would be able to do the same things as the C++ version
with a given amount of memory, no matter what you try. (In some cases
similar memory usage may be achieved in Java, but at the cost of making
the code less modular and a lot more complicated.)

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> 2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
> simply bring up the context menu and choose "Add Existing" or "Add New", 
> give it a name (and select the file if it aleady exists), and it's 
> imported into the correct directory.

  Does it have any support for creating a (possibly encrypted) package
from all the resources so that you don't have to distribute a bare version
of your resources directory structure, but instead you can simply distribute
this single package file with your program?

  (There are many reasons why one would want to do this, but the main
reason is that packaging (and encrypting) all the resources is a simple
"anti-spoiler measure": A curious user navigating the directory structure
of the game won't be able to spoil himself about the contents of the game
by simply double-clicking on the files.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage.

It's a lot like Java, but not in that respect. C# has things called 
"structures" which you can't inherit from, but are otherwise objects. 
They're basically value semantics. It's part of the type rather than the 
variable (unlike C++), but an integer takes the same number of bytes in 
C# as in C++.  I.e., you can make a struct that takes 12 bytes of 
storage, create an array of 10 of them, and it'll take 120 bytes of storage.

C#'s VM is also more targetted at JIT compilation. For example, at any 
given point in the VM bytecode, no matter how you get there, the stack 
has to have the same types on the stack. So in theory, if you had a 
bunch of registers, you could assign anything that was put onto the 
stack into a register instead. Just as one of many examples.

>   I actually find it a bit worrying that it seems that no programming
> language introduced in the last 20 years which has got some popularity
> seems to offer any tools *whatsoever* to create memory-efficient programs

We already have those languages. Anyway, you're missing Ada. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   Does it have any support for creating a (possibly encrypted) package
> from all the resources 

I thought it was pretty cool that you can encrypt the debug info in 
Erlang with a chosen key, so you can understand the stack traces only if 
  you have that key, for example.  Full source-level debugging with the 
package, but no way to recreate the source without knowing the key.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage. In Java
> I don't think there's any way around the problem that you cannot create
> a data container where each element takes as much memory as the total size
> of the members of the object, nothing more. The smaller the object is, the
> worse the memory usage overhead relative to this size.

Wasn't it John Carmack who said that Java is a great way of doing things 
at 1/10th the speed they should be done at? :)

Anyway, one of the first things I noticed in looking over C# is the 
difference in structs and classes.  Basically, a Class is the same as a 
C++ struct / class, with the indirection et al, allocated on the heap. 
A struct, on the other hand, has no member functions, and is a simple 
collection of the base data types all allocated on the stack.  Very 
sparse memory usage, and very fast, either as individual instances or in 
collections.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> 2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
>> simply bring up the context menu and choose "Add Existing" or "Add New", 
>> give it a name (and select the file if it aleady exists), and it's 
>> imported into the correct directory.
> 
>   Does it have any support for creating a (possibly encrypted) package
> from all the resources so that you don't have to distribute a bare version
> of your resources directory structure, but instead you can simply distribute
> this single package file with your program?

It does have support for packaging your projects, but I don't believe it 
has encryption.  It's compiled into a bytecode, so it's very easy to 
decompile into the original sources.  If you encrypted it, then the same 
key which allows it to execute would allow it to be decompiled.

Of course, you could use an obfuscator, and there are commercial 
packages available that integrate nicely with VS to do this 
automagically for you when you build your project.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> C++ struct / class, with the indirection et al, allocated on the heap. A 
> struct, on the other hand, has no member functions,

Woops, this is wrong.  Structs *can* have member functions.

Also, structs are passed by value whereas classes are passed by reference.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> >   Does it have any support for creating a (possibly encrypted) package
> > from all the resources so that you don't have to distribute a bare version
> > of your resources directory structure, but instead you can simply distribute
> > this single package file with your program?

> It does have support for packaging your projects, but I don't believe it 
> has encryption.  It's compiled into a bytecode, so it's very easy to 
> decompile into the original sources.

  Hmm, that's not really what I asked...

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>>>   Does it have any support for creating a (possibly encrypted) package
>>> from all the resources so that you don't have to distribute a bare version
>>> of your resources directory structure, but instead you can simply distribute
>>> this single package file with your program?
> 
>> It does have support for packaging your projects, but I don't believe it 
>> has encryption.  It's compiled into a bytecode, so it's very easy to 
>> decompile into the original sources.
> 
>   Hmm, that's not really what I asked...
> 

Sorry, you're right.  I was thinking of encrypting the sources, you were 
thinking of encrypting the data.

Anyway, as I said, it does support packaging your project.  And, to 
clarify, that includes the resources.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Anyway, as I said, it does support packaging your project.  And, to 
> clarify, that includes the resources.

  To avoid any misunderstanding: By "packaging" I don't mean "create an
installer file which you can distribute and which will install the program
in the user's computer".

  What I mean is that if it supports creating one single file which has
the data inside it, and then at runtime it reads the data directly from
that file instead of unpackaging it to the disk first (thus restoring
the original directory structure and files inside it).

  In other words, can you do so that your program consists of two files:
An executable file and a data file, and the program runs with just those
two files and doesn't create any additional files?

  Moreover, can some light encryption be applied to this data file (to
make unpackaging it slightly harder)?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> Anyway, as I said, it does support packaging your project.  And, to 
>> clarify, that includes the resources.
> 
>   To avoid any misunderstanding:

To clarify: I understand :)  That is indeed what I am trying to say that 
it does.  At least, as far as I understand it.

Hmm... I'll go try it right now to make sure it works...

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> Warp wrote:
>> Chambers <ben### [at] pacificwebguycom> wrote:
>>> Anyway, as I said, it does support packaging your project.  And, to 
>>> clarify, that includes the resources.
>>
>>   To avoid any misunderstanding:
> 
> To clarify: I understand :)  That is indeed what I am trying to say that 
> it does.  At least, as far as I understand it.
> 
> Hmm... I'll go try it right now to make sure it works...
> 

Slight problem: The install file created repeated crashes.  I'll have to 
investigate this further, but I'm done playing with it for today.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

nemesis escribió:
> Darren New <dne### [at] sanrrcom> wrote:
>> nemesis wrote:
>>> *Anything* compiles extremely quickly compared to C++.  Just don't perform the
>>> same.
>> With JIT compilers and such, I'm not sure how you can be so sure. :-)
> 
> Look for the top:
>
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&binarytre
>
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
>
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1
> with memory performance taken into consideration as well, it only gets worse:
>
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=1&xloc=0&binarytre
>
es=1&chameneosredux=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&meteor=0&nbody=1&nsieve=1&nsievebits=1&partialsums=
>
1&pidigits=1&recursive=1&regexdna=1&revcomp=1&spectralnorm=1&hello=0&sumcol=1&threadring=1

www.tinyurl.com for next time...

Post a reply to this message

Warp escribió:
>   I have no idea about the principles used in C#, but if it's anything like
> Java, the biggest problem is not so much speed as memory usage. In Java
> I don't think there's any way around the problem that you cannot create
> a data container where each element takes as much memory as the total size
> of the members of the object, nothing more. The smaller the object is, the
> worse the memory usage overhead relative to this size.

Agreed. I hate how I can't make arrays of objects in Java. Only arrays 
of references to objects.

Post a reply to this message

Warp wrote:

>   I actually find it a bit worrying that it seems that no programming
> language introduced in the last 20 years which has got some popularity
> seems to offer any tools *whatsoever* to create memory-efficient programs
> (at least not without resorting to really ugly code which bypasses nice
> modular design).

I was about to say "Haskell" - but it's not new enough...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Warp wrote:

> >   I actually find it a bit worrying that it seems that no programming
> > language introduced in the last 20 years which has got some popularity
> > seems to offer any tools *whatsoever* to create memory-efficient programs
> > (at least not without resorting to really ugly code which bypasses nice
> > modular design).

> I was about to say "Haskell" - but it's not new enough...

  You are telling me you can create very memory-efficient programs in
haskell without resorting to ugly low-level hacks?
  That seems to be contradictory to what I remember you saying about
those ugly arrays which can be modified in-place and such.

  OTOH, I just can't stop thinking about programming from a modular point
of view. To me a program consists of "concepts". This "concept" is some
kind of module which contains some properties, ie. members (variables,
functions...) Optimally, still from a modularity point of view, these
modules will have an *abstract* public interface (ie. one which does
not expose its internal structure).

  For example, a "pixel" is a concept. On the inside it consists, for
example, of four bytes (or four 16-bit words): The red, green, blue and
alpha components. However, from a modular point of view, these are
internal implementation details, hidden from the outside. The public
interface of this module consists of abstract functions which can be
used to manipulate its contents and behavior.

  Now, this is of course just a concept. It doesn't really exist
physically yet. When you instantiate this concept you get an "object".
You can instantiate the concept many times, getting many "objects".
All these objects can be manipulated through the abstract public
interface.

  The relevant question, from an optimization point of view, is how
much memory do these objects require? If you want to create one million
of such objects, how much memory do they require?

  In C++ you can often make it so that the objects require as much
memory as the contents of the object (eg. 4 bytes) times the number
of objects (plus a few additional bytes for book-keeping). So for
example one million of such objects could require only 4 million bytes
(plus a few bytes more). And this still while keeping the abstraction
of these objects: You still don't need to know what these objects look
in the inside. The inside of the objects doesn't need to be exposed.

  In Java this is impossible. You can't make such objects to take only
4 million bytes of memory, no matter what you do. If for the "pixels"
to take that much memory is completely imperative, what you can do is
dump the nice modular abstractions and nice public interfaces completely
and resort to very ugly hacks using integer arrays. This, of course,
causes all kinds of maintenance problems. (For example, if you would
like in the future to use 8-byte pixels instead of 4-byte ones, you are
screwed.)

  I don't have the slightest idea how all this works in Haskell, though.
Being a functional language it probably doesn't even have the concept of
"module", nor the concept of "object". Can you create "concepts" (such
as "a pixel") at all? Can you instantiate these "concepts" (and, for
example, put them inside diverse types of data containers)? Does it have
the concept of "abstraction" and "public interface" which hides
implementation details?

  If I'm not completely mistaken, in Haskell you can probably define
things like "a pixel consists of these four elements". However, that
already exposes the internal structure of a "pixel". That's asking
for maintenance trouble (because then code that uses that "pixel"
concept will assume it has those four elements, which means that it
may not be possible to modify it in the future without breaking
existing code).

  Maybe there's another completely different way of doing these things
in a functional language like Haskell? I just can't get around the
modular way of thinking about programming.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   You are telling me you can create very memory-efficient programs in
> haskell without resorting to ugly low-level hacks?
>   That seems to be contradictory to what I remember you saying about
> those ugly arrays which can be modified in-place and such.

Accessing an array is no more ugly than accessing a file. (After all, 
what is a file anyway? It's a named array of bytes!) You have to use a 
monad, which makes things a bit more wordy, but that's about it.

(As I have noted before, the various array libraries are currently a 
little incomplete though...)

>   In C++ you can often make it so that the objects require as much
> memory as the contents of the object (eg. 4 bytes) times the number
> of objects (plus a few additional bytes for book-keeping). So for
> example one million of such objects could require only 4 million bytes
> (plus a few bytes more). And this still while keeping the abstraction
> of these objects: You still don't need to know what these objects look
> in the inside. The inside of the objects doesn't need to be exposed.

Short answer: Haskell can do this. But the current level of library 
support is... somewhat lacking.

[I particularly like that way that if I make an array of 4 million 
Boolean values, each one takes up exactly 1 *bit* of RAM. And yet, the 
interface is identical to any other kind of array...]

>   I don't have the slightest idea how all this works in Haskell, though.
> Being a functional language it probably doesn't even have the concept of
> "module", nor the concept of "object". Can you create "concepts" (such
> as "a pixel") at all? Can you instantiate these "concepts" (and, for
> example, put them inside diverse types of data containers)? Does it have
> the concept of "abstraction" and "public interface" which hides
> implementation details?
> 
>   If I'm not completely mistaken, in Haskell you can probably define
> things like "a pixel consists of these four elements". However, that
> already exposes the internal structure of a "pixel".

Here's the Haskell way:

Haskell has "modules". The module is the unit of abstraction in Haskell. 
When you write a module, you can define precisely what parts of it are 
visible from the outside, and which parts aren't.

Most particularly, you can make a type visible without making its 
structure visible. So you could define a Pixel type (and some functions 
for creating and manipulating Pixel values), and export the type name 
only (and the functions for working on it).

You now have a situation not disimilar to a class in Java: Only the code 
in this module knows the true implementation of Pixel. If you change 
that implementation, you'll have to change the rest of the module too, 
but any client modules will be unaffected.

So, really, it's not so different. And indeed, the standard libraries 
provide examples. There is a standard library named "Data.Set". It 
provides a type called "Set". There is a constant named "empty" which 
contains an empty set. There is a function called "insert" which takes a 
set and an item and returns a set containing that item. And so forth. 
Now, I'm *told* it's implemented with some kind of balanced tree 
algorithm, but I don't actually know. Or care. And if it changes in the 
next release of the libraries, it won't matter.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 escribió:
> [I particularly like that way that if I make an array of 4 million 
> Boolean values, each one takes up exactly 1 *bit* of RAM. And yet, the 
> interface is identical to any other kind of array...]

C++ STL vector template class has a specialization for 'bool' that uses 
1 bit per element too. That is, a vector<bool> takes 1 bit per element.

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> [I particularly like that way that if I make an array of 4 million 
> Boolean values, each one takes up exactly 1 *bit* of RAM. And yet, the 
> interface is identical to any other kind of array...]

  But my point was not really that. In Java you can, for example, create
an array if 32-bit integers, and each integer will take only 32 bits of
memory. That's not the problem.

  The problem in Java is that if you are making an array of *objects*,
each object having only one 32-bit integer as a member variable, there's
just no way of making each object take only 32 bits of memory.

  So you have only two options: Create a "low-level" array of integers,
which is extremely rigid and very hard to maintain (as it basically is
an array of "exposed objects"), or you create an array of abstract objects
at the cost of the memory consumption increasing by a considerable factor.

  I understand that you can create an "array of integers" or "array of
booleans" in Haskell, but that's not really what I was asking.

> Haskell has "modules". The module is the unit of abstraction in Haskell. 
> When you write a module, you can define precisely what parts of it are 
> visible from the outside, and which parts aren't.

  So Haskell is really a two-paradigm language: Functional and modular?

  (To understand what the "modular programming paradigm" means, it's
basically the same thing as the "object-oriented programming paradigm"
minus inheritance and dynamic binding.)

  Anyways, my real question was: Given such a module (eg. "a pixel"),
can you, for example, create an array of them so that each one takes
only as much memory as the sum of the sizes of its member variables?

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> C++ STL vector template class has a specialization for 'bool' that uses 
> 1 bit per element too. That is, a vector<bool> takes 1 bit per element.

  The C++ standard library also offers the 'bitset' data container which
is specifically optimized to handle bits. (Its disadvantage is that its
size must be determined at compile time, and this size cannot change,
unline with std::vector<bool>.)

  Many operations doable to bitsets are extremely fast. (For example
counting the number of 1-bits is astonishingly fast.)

-- 
                                                          - Warp

Post a reply to this message

On Tue, 25 Mar 2008 17:34:14 +0100, Nicolas Alvarez  
<nic### [at] gmailisthebestcom> wrote:
> C++ STL vector template class has a specialization for 'bool' that uses  
> 1 bit per element too. That is, a vector<bool> takes 1 bit per element.

Yes, but that specialisation is largely considered a mistake because it  
breaks the interface associated with the generic std::vector. Also, there  
is no actual requirement that the elements occupy a single bit each; this  
is left up to the implementation.
There is std::bitset, but that does not use dynamic allocation.


-- 
FE

Post a reply to this message

Fredrik Eriksson escribió:
> On Tue, 25 Mar 2008 17:34:14 +0100, Nicolas Alvarez 
> <nic### [at] gmailisthebestcom> wrote:
>> C++ STL vector template class has a specialization for 'bool' that 
>> uses 1 bit per element too. That is, a vector<bool> takes 1 bit per 
>> element.
> 
> Yes, but that specialisation is largely considered a mistake because it 
> breaks the interface associated with the generic std::vector.

What exactly is broken in the interface?

Post a reply to this message

On Tue, 25 Mar 2008 19:47:39 +0100, Nicolas Alvarez  
<nic### [at] gmailisthebestcom> wrote:
> Fredrik Eriksson escribió:
>> On Tue, 25 Mar 2008 17:34:14 +0100, Nicolas Alvarez  
>> <nic### [at] gmailisthebestcom> wrote:
>>> C++ STL vector template class has a specialization for 'bool' that  
>>> uses 1 bit per element too. That is, a vector<bool> takes 1 bit per  
>>> element.
>>  Yes, but that specialisation is largely considered a mistake because  
>> it breaks the interface associated with the generic std::vector.
>
> What exactly is broken in the interface?

Well, it does not satisfy the requirements of an STL container, making it  
incompatible for use with some algorithms and other containers.

For a concrete example, consider this code:

// Code begins
template < typename T >
void func()
{
	std::vector< T > v( 10 );
	T& ref = v[0];
}
// Code ends

It works with any instantiation of the generic std::vector - the standard  
guarantees it - but fails with std::vector<bool>.

Also, things like 'std::stack< bool, std::vector<bool> >' do not work  
either.

As someone else once put it: std::vector<bool>, while listed under  
"containers" in the standard, is not a container, nor does it contain  
bools.


If you really need a compact set of booleans, use std::bitset or  
boost::dynamic_bitset instead.


-- 
FE

Post a reply to this message

Warp wrote:

>> Haskell has "modules". The module is the unit of abstraction in Haskell. 
>> When you write a module, you can define precisely what parts of it are 
>> visible from the outside, and which parts aren't.
> 
>   So Haskell is really a two-paradigm language: Functional and modular?
> 
>   (To understand what the "modular programming paradigm" means, it's
> basically the same thing as the "object-oriented programming paradigm"
> minus inheritance and dynamic binding.)

If you consider "modular" to be a programming paradigm then... yes, I 
guess. (Does Pascal count as "module" too?)

Did I mention that Haskell also has "classes"? (Though they don't work 
quite the same as in OOP.)

>   Anyways, my real question was: Given such a module (eg. "a pixel"),
> can you, for example, create an array of them so that each one takes
> only as much memory as the sum of the sizes of its member variables?

You can do this. However, it's sufficiently hard work given the present 
library structure that you would only bother doing this if it was really 
necessary for your particular application.

(In future they're supposed to be adding support for transparently 
storing arbitrary types without pointer indirection. For the moment, 
you'll have to implement it yourself by hand for any type you want an 
array of.)

So it's not a language limitation, it's a library limitation. And I'm 
not sure why nobody is out fixing it, actually...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   So Haskell is really a two-paradigm language: Functional and modular?

The functions are defined inside of modules.  Modularity is a good thing
anywhere.

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Tue, 25 Mar 2008 17:34:14 +0100, Nicolas Alvarez  
> <nic### [at] gmailisthebestcom> wrote:
> > C++ STL vector template class has a specialization for 'bool' that uses  
> > 1 bit per element too. That is, a vector<bool> takes 1 bit per element.

> Yes, but that specialisation is largely considered a mistake

  The alternative would be that there's no specialization, in which
case each element could take even 4 bytes (from which only 1 bit is
actually used).

  I don't see any problem in having an efficient boolean vector.
If it doesn't work with some STL algorithms, then it doesn't. In
the vast majority of cases there isn't any logical use for STL
algorithms for a bool vector anyways (why would you, for example,
try to sort a bool vector? It doesn't make any sense).

  Of course std::bitset should be used whenever possible. However,
it's not always possible. In that case std::vector<bool> is the
next best thing.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> If you consider "modular" to be a programming paradigm then... yes, I 
> guess.

  Yes, modular programming is usually considered a programming paradigm
of its own (a type of precursor of object-oriented programming).

  I think that the quintessential example of a modular programming
language is Modula-2: Its modules are more or less full-fledged classes
(public and private parts, member variables and functions, instanciation,
references to such instances...), except for what would make it an
object-oriented programming language: Inheritance.

  (Modula-3 added inheritance, making it an OOP language.)

> (Does Pascal count as "module" too?)

  Pascal is a programming language, not a module. :P

> Did I mention that Haskell also has "classes"? (Though they don't work 
> quite the same as in OOP.)

  If you can inherit and have dynamic binding (or a messaging system,
ie. delegation) then it would more or less make it an OOP language,
else it's just a modular programming language.

-- 
                                                          - Warp

Post a reply to this message

>> If you consider "modular" to be a programming paradigm then... yes, I 
>> guess.
> 
>   Yes, modular programming is usually considered a programming paradigm
> of its own (a type of precursor of object-oriented programming).

I thought that was structured programming?

>   I think that the quintessential example of a modular programming
> language is Modula-2: Its modules are more or less full-fledged classes
> (public and private parts, member variables and functions, instanciation,
> references to such instances...), except for what would make it an
> object-oriented programming language: Inheritance.

I've heard legend of Modula-2. Never actually seen it though.

(Actually, I've heard legend of another functional language where 
apparently modules *do* have inheritance... There are often debates 
about whether Haskell should do this - with most people agreeing the 
vast increase in complexity isn't worth it.)

>> (Does Pascal count as "module" too?)
> 
>   Pascal is a programming language, not a module. :P

Gah! The difference a few characters makes... :-S

[Obviously I meant "does Pascal count as modular?"]

>> Did I mention that Haskell also has "classes"? (Though they don't work 
>> quite the same as in OOP.)
> 
>   If you can inherit and have dynamic binding (or a messaging system,
> ie. delegation) then it would more or less make it an OOP language,
> else it's just a modular programming language.

Dynamic binding? Sure. That's the entire purpose.

Inheritance? Mmm, not really, no.



[In Java, a class *is* a type. In Haskell, a class is something a type 
may or may not be a member of. For example, the "Show" class provides a 
"show" method. Any type that is a member of the Show class can be 
converted into a string by calling the show function. It is possible to 
make it so that no type can be a member of class X without first being a 
member of class Y - but that's not exactly inheritance.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> >> If you consider "modular" to be a programming paradigm then... yes, I 
> >> guess.
> > 
> >   Yes, modular programming is usually considered a programming paradigm
> > of its own (a type of precursor of object-oriented programming).

> I thought that was structured programming?

  Structured programming is more related to principles related to the
control flow of the program, ie. related to control structures (such as
conditionals, switch-blocks and different types of loops). It's a kind
of subset of the more general procedural programming paradigm.

  I don't think the concept of "module" is part of the structured
programming paradigm. A modular programming language may follow the
principles of structured programming (and make its own additions), but
that doesn't mean it's the same in the other way. And I don't think
there's any requirement for a modular language to use structured programming
principles (in the same way as an OOP language doesn't necessarily have
to follow procedural programming principles).

> (Actually, I've heard legend of another functional language where 
> apparently modules *do* have inheritance... There are often debates 
> about whether Haskell should do this - with most people agreeing the 
> vast increase in complexity isn't worth it.)

  I have never understood why adding *optional* features, which you are
in no way forced to use, to something would make it "too complex".

> >> (Does Pascal count as "module" too?)
> > 
> >   Pascal is a programming language, not a module. :P

> Gah! The difference a few characters makes... :-S

> [Obviously I meant "does Pascal count as modular?"]

  I don't know enough about Pascal to answer that question. (Is there
a "standard" Pascal language anyways? I have the impression that each
compiler company has created their own variant of Pascal, and that there's
no official standard. I may perfectly be wrong, of course.)

> >> Did I mention that Haskell also has "classes"? (Though they don't work 
> >> quite the same as in OOP.)
> > 
> >   If you can inherit and have dynamic binding (or a messaging system,
> > ie. delegation) then it would more or less make it an OOP language,
> > else it's just a modular programming language.

> Dynamic binding? Sure. That's the entire purpose.

> Inheritance? Mmm, not really, no.

  That's a bit contradictory given that dynamic binding (or its
alternative, delegation) is inherently related to inheritance.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Structured programming is more related to principles related to the
> control flow of the program, ie. related to control structures (such as
> conditionals, switch-blocks and different types of loops). It's a kind
> of subset of the more general procedural programming paradigm.
> 
>   I don't think the concept of "module" is part of the structured
> programming paradigm. A modular programming language may follow the
> principles of structured programming (and make its own additions), but
> that doesn't mean it's the same in the other way. And I don't think
> there's any requirement for a modular language to use structured programming
> principles (in the same way as an OOP language doesn't necessarily have
> to follow procedural programming principles).

My take on it is that BASIC [the *original* language] was an 
unstructured language - the entire program is basically a vast list of 
mostly sequential commands. And then we have Pascal, which is a 
structured programming language. It has user-defined data structures, 
subroutines and local variables. Things are more "structured".

As to whether modularity is orthogonal or not... I hadn't really thought 
about it.

>> (Actually, I've heard legend of another functional language where 
>> apparently modules *do* have inheritance... There are often debates 
>> about whether Haskell should do this - with most people agreeing the 
>> vast increase in complexity isn't worth it.)
> 
>   I have never understood why adding *optional* features, which you are
> in no way forced to use, to something would make it "too complex".

Well, take multiple inheritance for example. If your language supports 
multiple inheritance, it can't support using the "super" keyword, 
because it could refer to several different classes. (With single 
inheritance, it is obviously quite unambiguous.) So even if you never 
ever actually use MI, if the language your using supports it, it stops 
you from being able to have a super keyword to use. You'll have to refer 
to superclasses some other way.

It's a minor increase in complexity, but it's an example of how even if 
you don't use a particular feature, if it's available the language 
design has to cope with it.

>> [Obviously I meant "does Pascal count as modular?"]
> 
>   I don't know enough about Pascal to answer that question. (Is there
> a "standard" Pascal language anyways? I have the impression that each
> compiler company has created their own variant of Pascal, and that there's
> no official standard. I may perfectly be wrong, of course.)

Well, there are many dialects of BASIC. [And I'm not talking about VB, 
I'm talking about the *real*, unstructured BASIC.] Each one has its own 
little quirks, but you can still make general statements about BASIC 
overall.

>> Dynamic binding? Sure. That's the entire purpose.
> 
>> Inheritance? Mmm, not really, no.
> 
>   That's a bit contradictory given that dynamic binding (or its
> alternative, delegation) is inherently related to inheritance.

Dynamic binding just means choosing between several possible method 
implementation at runtime rather than compile time depending on the type 
of a particular value. You don't actually need inheritance for that.

[For example, in Haskell the "+" function has several implementations - 
for integers, doubles, ratios, and any user-defined types you care to 
add. When you add two values, it needs to pick the correct one. Often 
this can be done at compile-time, if the types are known. Otherwise it 
must happen at runtime...]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Well, take multiple inheritance for example. If your language supports 
> multiple inheritance, it can't support using the "super" keyword, 
> because it could refer to several different classes. (With single 
> inheritance, it is obviously quite unambiguous.) So even if you never 
> ever actually use MI, if the language your using supports it, it stops 
> you from being able to have a super keyword to use. You'll have to refer 
> to superclasses some other way.

  The solution is rather simple: One of the base classes is the "super"
class, the rest aren't. (This can be differentiated with keywords when
inheriting, or even by the order in which the inheritance list is
specified: The first base class mentioned can be the "super" class.)

  Think of it as the rest of the base classes being interfaces with
support for member variables and function implementations.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 escribió:
> I thought that was structured programming?

Structured programming is if/while/for and functions/methods/whatever 
instead of goto.

Post a reply to this message

Orchid XP v7 wrote:
> If you consider "modular" to be a programming paradigm 

It is. Note that it has been superceded, but at the time the term was 
coined, it was quite a revolutionary idea.

> (Does Pascal count as "module" too?)

No.  :-)  One of the fundamental features of modules is information 
hiding. You can't hide the types in a Pascal program.  At least, not 
standard pascal.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   I have never understood why adding *optional* features, which you are
> in no way forced to use, to something would make it "too complex".

Because you still have to learn these features to understand code that 
someone else has written.

Using the C preprocessor is optional in C. Yet if you don't know how it 
works, you're unable to read 99.44% of all the C code out there.

>> [Obviously I meant "does Pascal count as modular?"]
> 
>   I don't know enough about Pascal to answer that question. (Is there
> a "standard" Pascal language anyways? I have the impression that each
> compiler company has created their own variant of Pascal, and that there's
> no official standard. I may perfectly be wrong, of course.)

There's an official standard, but it was too weak (no modularity, no way 
of (for example) opening a named file, etc) to be useful for work on 
desktop type machines. Worked great on mainframes where you had the JCL 
set up to do stuff like open the files for you.

>> Dynamic binding? Sure. That's the entire purpose.
>> Inheritance? Mmm, not really, no.

>   That's a bit contradictory given that dynamic binding (or its
> alternative, delegation) is inherently related to inheritance.

Not really. Javascript has no inheritance but has dynamic binding. 
Anything with "duck typing" could be said to have dynamic binding 
without requiring inheritance.


-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Orchid XP v7 wrote:
> My take on it is that BASIC [the *original* language]

aka "Dartmouth BASIC".  Just so's ya know. :-)

> As to whether modularity is orthogonal or not... I hadn't really thought 
> about it.

It's orthogonal, but usually modular programming languages are 
structured. Structured programming is sort of like modular programming 
in the small - you know this is a while loop and you don't really need 
to look inside unless you need the details, because control flow won't 
enter or leave it.  Modular programming is sort of structured 
programming for data. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:

>> (Does Pascal count as "module" too?)
> 
> No.  :-)  One of the fundamental features of modules is information 
> hiding. You can't hide the types in a Pascal program.  At least, not 
> standard pascal.

Yeah, this is the flaw. Pascal allows you to hide subroutines, but not 
data structure details. Haskell does not have this unfortunate flaw. :-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> 2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
>> simply bring up the context menu and choose "Add Existing" or "Add New", 
>> give it a name (and select the file if it aleady exists), and it's 
>> imported into the correct directory.
> 
>   Does it have any support for creating a (possibly encrypted) package
> from all the resources so that you don't have to distribute a bare version
> of your resources directory structure, but instead you can simply distribute
> this single package file with your program?

OK, more on this:
No.

:(

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Warp wrote:
> > Chambers <ben### [at] pacificwebguycom> wrote:
> >> 2) Resource manage is *incredibly* easy.  In the "Solution Explorer", 
> >> simply bring up the context menu and choose "Add Existing" or "Add New", 
> >> give it a name (and select the file if it aleady exists), and it's 
> >> imported into the correct directory.
> > 
> >   Does it have any support for creating a (possibly encrypted) package
> > from all the resources so that you don't have to distribute a bare version
> > of your resources directory structure, but instead you can simply distribute
> > this single package file with your program?

> OK, more on this:
> No.

  I thought so.

-- 
                                                          - Warp

Post a reply to this message