Ask Me About Programming

Sure, why not. It seems some people are interested, but I focus specifically on these languages (please bear in mind that the word 'programming' is frankly a bit vague):

• C++
• C#
• PHP
• CSS, XHTML, Javascript...

I'm not listing "weiner" languages.

In particular web development (PHP/SQL/XHTML/LAMP stacks), Winsock/networking and DirectX are topics I'm handy with. Also, don't ask me a thing about, say, programs that run on punch cards.

I've thought about learning C#. Give me a run-down on how it compares to C++.

C# is quite an interesting language, (relatively) new. A lot of the people I know that develop in it gush over it. To be perfectly honest, I've yet to develop anything substanial in C# - this is not a failing of the language, rather of my time and the energy I can put into things.

Because of the way Microsoft pushes it it's also commonly associated with .NET 3.0 and other such things which apparently cooperate pretty well. C# and .NET are supposedly one of those "killer stacks".

The change in C# from C++ is quite big but not without reason, I've found. The syntax itself is all relatively self explanatory but it's gone from the OOP/pragmatic compromise that C++ was to a pretty hardcore OOP stance. 90% of all things are just classes now and at first I found it slightly disconcerting. OOP is lovely, but not that lovely.

But the main benefits are:

• OOP can now be implemented much cleaner and better than ever before, as I mentioned.
• A bit more "bang for your buck" - perhaps you could call it higher level - than C++. When you'd be mucking around with general internals and juggling of bits and bytes with C++, painstakingly coming from the ground up, you'll just use one of the prefabricated control structures or other things with C# and it works.
• Some sorely needed language additions, like foreach and using blocks (which are now pretty important).
• Garbage collection. Memory leaks are no longer such a terrible calamity, although I'm sure quite possible.
• Code documentation is (sort of) XML based. It's odd, but a different improvement from the "fuck ever" of C++.

With my limited experience, I'm probably missing out some "killer features". Those are what I find most compelling, but you'd probably feel different.

I think there is nothing in C# you can't do in C++. C++ is still very powerful but very dangerous if you don't know what you're doing - complexity just shoots through the roof and sometimes it's better to bite the bullet. I sense C# as being the way things may just be headed (it's quite a logical progression) and so it's definitely worth a more in depth look.

It also seems like a rather fast developing language. Why I don't know, but there are are several "versions" of C# (1.0, 2.0, 3.0...) although I'd recommend the Visual C# 2005 Express IDE/compiler from Microsoft's website which is available for free if you were interested in playing with it a bit. Frankly the examples they give in the IDE are pretty shit, but I've already seen some very interesting things with DirectX and C#. Speed impacts aren't as huge as I thought they might be.

It's not ECMA standard but, well, who cares?

woo! C# sounds worth looking at.

I've got an interesting logic question. I want to dick around and just make a randomly generated 'nethack' style map. Any theories?

I guess you could do it in stages:

- generate rooms
- generate exits to rooms
- (randomly) match room exits
- generate (random) paths between matched exits
- generate doors/items/mobs/etc

I've got a Sil level 3 application ro control, should I use a partitioned PLC to garuntee safety or use an independently wired relay solution?

BTW, we are making sodium azide.

Quote:

---

Originally Posted by spoon

I guess you could do it in stages:

- generate rooms
- generate exits to rooms
- (randomly) match room exits
- generate (random) paths between matched exits
- generate doors/items/mobs/etc
[/b]

---

There is still the issue of overlapping rooms.

Well, you could check the bounds of each generated room before adding it. Or you could let rooms overlap, and just overlay them, which would let you get more complex shapes from just generating rectangles.

Quote:

---

I've got a Sil level 3 application ro control, should I use a partitioned PLC to garuntee safety or use an independently wired relay solution?

BTW, we are making sodium azide.[/b]

---

I can't even tell if that makes sense or not :). I don't know if I should be happy or sad. Universities don't teach the good stuff anymore I guess. Bet that makes you happy with the state of your job security :D

Why don't you look at the Nethack source code? I guess it wouldn't be "too hard" to make an algorithim to do it. Then again..

Quote:

---

I've got a Sil level 3 application ro control, should I use a partitioned PLC to garuntee safety or use an independently wired relay solution?

BTW, we are making sodium azide.[/b]

---

I would use an independently wired relay solution, since you seem to be coming in from the buzzwords/lack of maintainability angle.

Any general tips on programming C++?

Quote:

---

Originally Posted by BohmaN

Any general tips on programming C++?
[/b]

---

depends on what you're used to
if, like me, you came from procedural languagues into C++, then getting a good overview of OOP is a must
there's countless tutorials floating around

Quote:

---

Any general tips on programming C++?[/b]

---

If C++ is one of your first languages, not a bad choice (I learned C++ before HTML, although to be honest that's a bit of a fluke). The syntax is not very complicated and once you learn that you'll realise so many other languages share the same sort of syntax - but syntax takes practically about half an hour to get to grips with and a few days to be entirely fluent in so don't consider that too impressive like a lot of [dumb] people do.

Like Ynot said, what you REALLY need to get your head around is object oriented programming. While I don't, and any half decent programmer won't, consider it the holy grail and method to end all methods, you are going to do yourself a huge favour if you can understand that. This does not apply specifically to C++, but almost any decent language these-a-days deals with OOP. C++ doesn't do the world's best job of helping an object-oriented programmer, but it can work.

C++ is actually a dangerous language in the sense that it can do just about anything, but it does not take much to get complicated or completely obtuse and end up repeating yourself and code and over again. If you find C++ to be a bit infuriating in that you seem to be putting everything together from scratch or dealing with reams of code that perform simple things, you might want to try a 'softer', but equally interesting and rewarding language like PHP.

I would suggest, once you get up to scratch, and it won't take long (I recommend the 'C++ Primer' book which goes through just about everything on the planet, including the STL) you take a look at a "serious" project like BZFlag, which is an open source game - fun too - and consequently you can get the code for it and see how C++ "works". I find that you can do so many tutorials before you begin to wonder if something substantial can be made of it other than dumb little examples, so looking at someone else's source like that is always good.

And remember, pointers aren't half as confusing as people say they are!

:)

But what exactly is "object oriented programming"

Object oriented programming is a good way to keep coding simple enough to not be frustrating to do when developing anything, especially something large. So reading up an article or tutorial should explain it well enough as it's far from rocket science.

Either way though, OOP is great and I doubt many would have a problem understanding the concept but what I've never understood (probably because I don't go into sysdev) is pointers...
It seems nearly every C++ tutorial and guide has a whole paragraph on pointers not far from the beginning but no matter how much I read about them there's one thing I can't grasp - their practical usage.
Addressing memory? For what? Why? And so on...

Quote:

---

I can't grasp - their practical usage.
Addressing memory? For what? Why? And so on...
[/b]

---

Pointers are good for dynamically allocating memory. The allegro library uses pointers for bitmaps, midi files and data files so that you don't have to know the size of the file. Pointers are also good for controlling other variables. Let's say you have a function in which you need to change the value of one of it's arguments, you would do with with a pointer like this:

Code:

---

void foo(int *bar)
{
&bar=45;
}

---

Also if you can use pointers to write directly into video memory, thereby giving you graphics without a graphics library.

But given that example, why is there a need for a pointer?
I mean, you're still declaring bar as an int type, even if it is a pointer. So it will still have the same limitation as just "int bar", right? 0 through 65535 and what not.

Quote:

---

But given that example, why is there a need for a pointer?
[/b]

---

Because I'm changing the value of the argument passed without returning a value.

Uh...that doesn't make much sense, at least at first.
The variable "bar" in void foo(int bar) is a parametre for the function. Thus, apparnetly, by using a pointer you could make it public (I think) but there's not much point when you can just use a public variable and use the function to change that.

Okay my example wasn't the best, but imagine that you are making a word processing program
you could do this

Code:

---

char doc[1000];

---

With this variable when the user types more than 1000 characters the program will crash due to buffer overflow, but if you do this:

Code:

---

char *doc;

---

The document can be any length

Some dodgy C++ knowledge here.

Code:

---

void foo(int *bar)
{
&bar=45;
}

---

Would be:

Code:

---

void foo(int *bar)
{
*bar=45;
}

---

Why you have a & (the symbol for a reference) I am not entirely sure. You might call the function as such:

Code:

---

foo ( &mrBar );

---

And besides which, returning the int is entirely possible and much more understandable. As for the char* doc example, I would use the std::string class so that's also a bad example in any case. An example of where you might need pointers because they're inescapable is a function like this:

Code:

---

int x = 1;
int y = 2;
swapTwoVariables ( &x, &y );

printf ( "%i and %i", x, y );

---

Which would return "2 and 1" (noting the swap). Functions like that tend to be a bit crappy and I would say that if you're swimming in pointers that don't make apparent sense then you're doing something wrong. A 'real world' example of pointers is something like the DirectX API are absolutely chock full of pointers and references:

Code:

---

D3DXMatrixRotationY ( &upMatrix, YDelta / 400 );
D3DXVec3TransformCoord ( &this->upVector, &this->upVector, &upMatrix );

---

Note all the use of &, which is "address" (creating a pointer to the variable instead of a copy). So it definitely has got practical applications.

What you meant by "public variable" makes no sense. It's a function, not a class, in Pyro's example.

All this said, I don't like pointers and references very much in C++ either and try to avoid them where possible. This is not to say they don't have their uses, and they're not overly complex to understand, but by and large you can avoid them.

following on from that,

imagine your program loaded into memory, and running
imagine it as a box

everything inside the box is "your program"
everything outside isn't

Code:

---

MEMORY

** +---------+
** |******** |
** |** MY****|
** |**PROG** |
** |******** |
** +---------+

** +---------+
** |******** |
** |SOMETHING|
** |** ELSE**|
** |******** |
** +---------+

---

now, if you have a variable in your program, Eg. Name
and you use normal memory allocation
that variable will be "inside" your program
so it has to have a fixed size

char name[20] ;

Code:

---

** +--------------------+
** |********************|
** |********************|
** |**[name variable]** |
** |********************|
** +--------------------+

---

so, if you set the name variable at 20 characters
you will always have 20 characters space for the person's name

If your guy's name is Bob Hope
that's 8 characters
meaning there's 12 characters' worth of wasted space in memory

Code:

---

****name
****[Bob Hope************]

---

however, if the guys name is longer than 20
your program won't be able to store it

so, dynamic memory allocation (and pointing to it with pointers)

"inside" your program you have a pointer to a piece of memory "outside" the box

so when the guy inputs his name, a "strip" of memory the exact size to store the inputted name is temporarily "given" to the program

however, it is outside your box, so you have to point to it
using a pointer

Code:

---

** +--------------------+
** |********************|
** |********************|
** |**[name pointer]****|
** |****** |************|
** +-------|------------+
********** |
**********\|/
** +------------+
** |** Name**** |
** +------------+

---

So, your program stays as small as possible (no wasted spaces)
and is "given" some memory when you need it
and your program "gives it back" when it's finished with it

All thanks to pointers

And following on from that (isn't this fun?) is the distinction between the heap and the stack. The stack is memory you allocate like:

Code:

---

void myFunction ( void )
{
****int myInteger = 0; /* INT memory allocated. */
****/* Some other stuff. */
}

---

myInteger ceases to exist when the variable goes out of scope - basically when the function ends and the function itself goes off the stack. The memory is freed up and you don't have to do anything else. This is all very nice, pragmatic and no end of use but has problems like we've mentioned.

So you might need to dynamically allocate memory like this:

Code:

---

void myFunction ( void )
{
****int* myNiceInteger = new int;
}

---

But now you've opened a whole new can of worms. The trade off is you get your dynamically allocated memory, but now you have to be very careful what you do with it because it's on the heap instead of the stack.

It's easy to forget to delete the int, and as you're using up memory that the OS doesn't know when to free up (because you explicitly put it on the 'heap' instead of the nicely ordered 'stack' it's not going to touch it) it's used until the program ends. A few thousand calls to that function - you can imagine it being a new class or something much more memory intensive instead of a humble int - and you very quickly have a problem. One that can be hard to find.

But you do need a pointer to allocate memory like that else you won't be able to find it, and you do often have to allocate memory on the heap. If you lose the pointer, you're also going to have trouble finding that variable again and deleting it. That is to say, it will be impossible. There's also problems with causing what Windows 98 charmingly called a general protection fault: buffer overruns, accessing memory that isn't yours by mistake and the popular "causing your program to go up in flames in front of your boss". It's not something a compiler is able to catch either, and the only obvious effect is when your program quietly corrupts itself or crashes.

Nice, isn't it?

So if you don't delete (italicised because it's the C++ keyword) that memory you will get the good old fashioned memory leak. The memory will just sit there whiling away RAM until the program ends and the OS can then (and only then) be confident in cleaning up in the heap without upsetting whatever your program is doing. Memory leaks and the management of dynamically allocated memory - or lack of it - is one reason that people do not like C++ as much as they otherwise might. Hence Java and C# having what's known as garbage collection to tackle this problem and make your life that much easier. Me, I like the sense of adventure that a lack of guard bytes and so on can bring.

I'm not entirely sure who I'm explaining this to, either, but it's fun.

and following on from that
you can think of a memory leak as "losing the pointer" to a piece of memory

you've dynamically allocated some memory "outside" the box
with a pointer pointing to it, so your program knows where it is

but if you delete the pointer (by expressly doing so, or allowing your program to come to an end)
you will be stuck with that "strip" of memory still in memory

the process that owned it has ended
and no other process has access to it,
so it's stuck there until you reboot your machine

By a public variable I meant a global variable.
But aye, I've been in Perl/PHP too long. Forgot that in C++ you have to create your own dynamic strings, if I recall correctly.

Quote:

---

Originally Posted by Merlock

By a public variable I meant a global variable.
But aye, I've been in Perl/PHP too long. Forgot that in C++ you have to create your own dynamic strings, if I recall correctly.
[/b]

---

now-a-days, the STL (standard template library) largely deals with it
but it's still important to know