Printable View
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):I'm not listing "weiner" languages.
- C++
- C#
- PHP
- CSS, XHTML, Javascript...
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: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.
- 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++.
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.
There is still the issue of overlapping rooms.Quote:
Originally Posted by spoon
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.
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 :DQuote:
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]
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..
I would use an independently wired relay solution, since you seem to be coming in from the buzzwords/lack of maintainability angle.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]
Any general tips on programming C++?
depends on what you're used toQuote:
Originally Posted by BohmaN
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
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.Quote:
Any general tips on programming C++?[/b]
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...
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:Quote:
I can't grasp - their practical usage.
Addressing memory? For what? Why? And so on...
[/b]
Also if you can use pointers to write directly into video memory, thereby giving you graphics without a graphics library.Code:void foo(int *bar)
{
&bar=45;
}
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.
Because I'm changing the value of the argument passed without returning a value.Quote:
But given that example, why is there a need for a pointer?
[/b]
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
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[1000];
The document can be any lengthCode:char *doc;
Some dodgy C++ knowledge here.
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:void foo(int *bar)
{
*bar=45;
}
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:foo ( &mrBar );
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:int x = 1;
int y = 2;
swapTwoVariables ( &x, &y );
printf ( "%i and %i", x, y );
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.Code:D3DXMatrixRotationY ( &upMatrix, YDelta / 400 );
D3DXVec3TransformCoord ( &this->upVector, &this->upVector, &upMatrix );
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
now, if you have a variable in your program, Eg. NameCode:MEMORY
** +---------+
** |******** |
** |** MY****|
** |**PROG** |
** |******** |
** +---------+
** +---------+
** |******** |
** |SOMETHING|
** |** ELSE**|
** |******** |
** +---------+
and you use normal memory allocation
that variable will be "inside" your program
so it has to have a fixed size
char name[20] ;
so, if you set the name variable at 20 charactersCode:** +--------------------+
** |********************|
** |********************|
** |**[name variable]** |
** |********************|
** +--------------------+
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
however, if the guys name is longer than 20Code:****name
****[Bob Hope************]
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
So, your program stays as small as possible (no wasted spaces)Code:** +--------------------+
** |********************|
** |********************|
** |**[name pointer]****|
** |****** |************|
** +-------|------------+
********** |
**********\|/
** +------------+
** |** Name**** |
** +------------+
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:
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.Code:void myFunction ( void )
{
****int myInteger = 0; /* INT memory allocated. */
****/* Some other stuff. */
}
So you might need to dynamically allocate memory like this:
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.Code:void myFunction ( void )
{
****int* myNiceInteger = new int;
}
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.
now-a-days, the STL (standard template library) largely deals with itQuote:
Originally Posted by Merlock
but it's still important to know
Yes. If you use anything other than std::string, you're a whore. One that probably leaks a lot of memory. It's worth mentioning the OS will clear up your memory leak 99.9% of the time when your program terminates, but if your program hangs around for any longish period of time that will soon become a problem because the OS won't clear the heap until you terminate. And, of course, if you're using magic kinds of memory - shared memory, or you happen to be coding an OS, you're largely fucked.
Sorry, it's been a while since I've used &Quote:
Some dodgy C++ knowledge here.
[/b]
Ok, Kaniaz
proper question
In your opinion, what's the best way to incorporate 3rd party modules into a program?
take the boost libraries, for example
I want to use some of them
Dynamically linked (shared objects), or statically linked to my main program?
I'm thinking:
Dynamic
+ easy to update library's (bug fixes, etc.) without recompiling my project
- DLL Hell (or SO hell, depending....)
Static
+ easy for me, as I know in advance all interfaces to 3rd party components
- have to re-compile entire project if one 3rd party component is updated
My opinion? Probably dynamic, unless your application just so happens to be so terribly suited to static linking for some reason. But this is just out of what seems to be a general convention more than any compelling reason otherwise and I trust you not to take my word as some sort of gospel (duh). I'm going more with instinct than any facts and figures that make either way compelling.
Good old hell with those DLLs is one of the major problems with dynamic linking and something you want to avoid (who wouldn't?), but what with things like Microsoft's 'side-by-side' facilities, a bit of common sense and perhaps a teeny tiny bit of luck you shouldn't really have a problem with that. At least, not in this day and age. You'd think.
If I remember correctly Boost is a bunch of C++ utilities and "things" that just make your life easier. Something like that I might just statically link for speed/"so I know it works", and because it might not inflate the .exe as much as say, statically linking all of DirectX in.
Do you like answers that are basically 'maybe'? To be honest your linking method is probably rather inconsequential.
yeah,Quote:
Originally Posted by Kaniaz
like the boost regex library
it's just a portable class that gives you regular expression functionality
it's internal to my program only (ie. it doesn't communicate with anything outside)
so I'm inclined to statically link it
but something like database API's
dynamic
ok, thanks
I've got a question.
This is less about the programming itself and more about the actual programming process, but here goes:
I'm just getting into C++. I'm still on the basics, but I'm learning quickly, and in a while I'm going to want to get my hands dirty with some experience.
What would you recommend as a good starting point for some actual work for somebody new to C++?
I've looked at possibly joining some open source projects and working on patching problems, would that be a good starting point, or not?
Wouldn't that be:Quote:
Originally Posted by Kaniaz
so as to change the value of the int instead of changing the pointer's target?Code:void foo(int *bar)
{
(*bar)=45;
}
I learned Hypercard first, then VB, then C++, and now I use Java. Hypercard isn't quite a programming language, but I count it because it's what got me interested. The great thing about Hypercard is that some of the commands are grammatically correct.
You know, I think you're right. How's that for irony? Thanks for pointing it out.Quote:
so as to change the value of the int instead of changing the pointer's target?[/b]
Myself, I spend a lot of time mucking around and making me own program - although it doesn't really have much use other than as a learning experience. I would reccomend you took a look at a project similar to one you'd like to try making, so when you do get stuck, you can see how "other people" do it.Quote:
What would you recommend as a good starting point for some actual work for somebody new to C++?
I've looked at possibly joining some open source projects and working on patching problems, would that be a good starting point, or not?[/b]
At college, I started with C++ and then went on to Java. My C++ knowledge isn't the greatest (in fact for a programmer I'm not the most knowleadgeable about computers! lol) but I've done the basics.
I want to create windows apps, I enjoy C++ but I found that Java has a much friendlier way of doing things with Swing. Even so, where would I get tutorials to do that stuff in C++? Or should I just use visual C++?
I also want to, at some point, do some coding with openGL and stuff for games. Where would I get my hands on some tutorials and easy to follow books?
This site has a lot of good tutorialsQuote:
Originally Posted by 13redfan
http://www.cprogramming.com
Main tutorials list
http://www.cprogramming.com/tutorial.html
awesome! thanks man
this site is all about openGL, http://nehe.gamedev.net/