21 May, 2009, elanthis wrote in the 61st comment:
Votes: 0
I had a number of courses in system administration and the like. The school might have classified those as CS, but I sure as hell don't.
21 May, 2009, JohnnyStarr wrote in the 62nd comment:
Votes: 0
Here's a very non-mud related question, but it seems to be relevent at this point in the thread. So, elanthis, do you program for a living? I take it David does. The reason i ask is i'm allot like you elanthis in that, i'm totally into seemingly boring stuff. I get a thrill out of things i cant figure out. I have a good job, but it is in no way programming. but, CS is my true passion, and as dumb as it may sound, i want to go to school to learn more, not for work. Yes, i'm sure i would be good eventually as a developer for work, but at the same time, i'm curious whether or not i would like doing my hobby for work.

In other words, i program to relax.
21 May, 2009, quixadhal wrote in the 63rd comment:
Votes: 0
Yep, around gcc 4.1, the changed the default so that -Wwrite-strings is now part of -Wall, which is why so many of us cried so many tears a few months back. However, I'd like to note the following from the man page, emphasis mine:

Quote
-Wwrite-strings
When compiling C, give string constants the type "const char[length]" so that copying the address of one into
a non-"const" "char *" pointer will get a warning; when compiling C++, warn about the deprecated conversion
from string constants to "char *". These warnings will help you find at compile time code that can try to
write into a string constant, but only if you have been very careful about using "const" in declarations and
prototypes. Otherwise, it will just be a nuisance; this is why we did not make -Wall request these warnings.


Ummm, yeah. But we changed our minds and decided you should all SUFFER!
21 May, 2009, Kline wrote in the 64th comment:
Votes: 0
-Wno-write-strings is your friend. At least in the short term :).
23 May, 2009, JohnnyStarr wrote in the 65th comment:
Votes: 0
So, I have a question about C++ with MS Visual Studio 2008.

Is there a way to use gcc within VS? I've been learning C++ daily but as we discussed before,
I don't really seem to like VIM despite efforts to get it down, blame it on my windows roots.

Anyway, I have several books on C++ and can't get anything to work within VS. Yes, i'm sure after
hours of googling it i could figure out what's wrong, but i thought i might ask you guys first.
23 May, 2009, David Haley wrote in the 66th comment:
Votes: 0
It's possible but hard. It's far easier to just compile with gcc/g++ separately. Of course, this means you lose things like jumping to errors within the IDE.

You might be better off trying Eclipse's C/C++ mode.

Why are you wanting to use gcc in the first place?

Quote
I don't really seem to like VIM despite efforts to get it down, blame it on my windows roots.

Vim is hard to learn and takes a while; so does Emacs, to use it as more than a plain text editor. It's not surprising that you're not comfortable within just a week or two; it takes practice. :smile:

Quote
Anyway, I have several books on C++ and can't get anything to work within VS.

What specifically is not working? Surely you can compile "hello world" programs within VS. If you can't, something is wrong with either your environment or your program.
23 May, 2009, Sharmair wrote in the 67th comment:
Votes: 0
staryavsky said:
So, I have a question about C++ with MS Visual Studio 2008.

Is there a way to use gcc within VS? I've been learning C++ daily but as we discussed before,
I don't really seem to like VIM despite efforts to get it down, blame it on my windows roots.

Anyway, I have several books on C++ and can't get anything to work within VS. Yes, i'm sure after
hours of googling it i could figure out what's wrong, but i thought i might ask you guys first.

I don't know if you could replace the command line compiler the IDE calls, but I am not sure why
you would want to. The coding differences between MSVC and gcc is really not that much as far
as MUDs go. I in fact do all the coding (other then simple one or so line changes that just have
to be done right away in the shell to fix a bug or whatever) I do for all the MUDs I have ever helped
on in MSVC. Some bases, like SMAUG and circleMUD compile out of the box or with very minor
changes. Other bases like ROMs and empireMUD (though a circle deriv, it seems the win32 stuff
was removed) take a bit more work to get going. ROM I made win32 ready a couple ways, the
first time I did it (compiling stock 2.4b6 just to look at it), I basically added Nick Gammon's
changes over from SMAUG. I kind of felt the services and multi threading stuff was just a bit much,
so when I helped on a quickMUD, I just fixed the issues as I compiled using more direct replacement
of the *nix specific code with the win32 equivalent. Off hand, other then header files what I think I
had to tweak in a number of files, most of the changes were in comm.c with some of the socket code
and adding a couple functions for things win32 did not have (gettimeofday(), opendir(), readdir() and
closedir() come to mind here). The socket stuff was using closesocket() instead of close() and
changing the stuff that used fcntl() to use the win32 equivalents. I of course made the changes so
the code would compile both on my windows computer and when uploaded to the *nix server. I do
still have all the code changed I made, so if you want, I can get more into detail of what I did. But,
if I was you, I would just get the code you are working with to cross platform compile.
23 May, 2009, David Haley wrote in the 68th comment:
Votes: 0
Yes, it's possible to change the compilation command line. You would want to do so because the MUD might not (or probably will not) compile on Windows due to various headers or system calls used, or you might accidentally put in Windows calls that you then need to fix when you go back to a Unix-based environment. Yes, as you say, it's possible to get it to compile on Windows (several people have done so, several times), in which case you wouldn't need to convince MSVS to use g++ instead, but doing so requires understanding the system libraries involved which can be off-putting for a new programmer. I would never recommend that a new programmer start messing with the socket code.
23 May, 2009, JohnnyStarr wrote in the 69th comment:
Votes: 0
Cool, both posts were very helpful. The only reason I wanted to use VS was just because
I know my way around it. Vim isn't hard to use, so much is it's just so different, i've found allot
more time has been spent learning it than getting deeper into the codebase. I would love to be able
to have it compile in both, but perhaps I'll have to take it slowly, which is fine.

Mainly, at this point, I'm just glad I am finally understanding the "mystery of C" and am looking
forward to being able to add cool stuff with C++. I suppose Lua is better for adding to the base
– from what others have said – but it seems that C++ is worth learning. I was amazed to see
how similar the syntax is to Java and C#. I was told not to "waste my time" with C++, but am starting
to see the value.
24 May, 2009, David Haley wrote in the 70th comment:
Votes: 0
C++ is absolutely worth learning, especially if you're remotely considering entering the software industry. (I know you said you weren't sure you wanted to do your hobby for work, but still.) Truly understanding C++ will give you a great understanding of programming concepts in general, because you're getting more exposure to the computer's memory model. It's just important to not get your head stuck in low-level details, and be able to juggle between high-level concepts and low-level details.

By the way, the syntactic relationship between C++ and Java/C# is not at all accidental. In fact, it was intentional: the language designers judged that a good way of encouraging adoption was to make the language look like what people already know.

Adding Lua to a base is a whole other question than learning C++. The things you would do with Lua just aren't what you'd do with C++, really, at least not easily. C++ won't give you on-the-fly dynamic features: it's not meant to.

Anyhow, for your IDE, you can always edit the files in MSVS, and then compile in gcc. This is quite easy if you're using Cygwin, or if you can convince the AndLinux thingiemajig to use a filesystem that MSVS can see. (I'm not sure how AndLinux handles filesystems.) I did this for quite some time, actually, until I got familiar enough with vi that working with vi was actually much more efficient than MSVS.
24 May, 2009, JohnnyStarr wrote in the 71st comment:
Votes: 0
David Haley said:
Anyhow, for your IDE, you can always edit the files in MSVS, and then compile in gcc. This is quite easy if you're using Cygwin, or if you can convince the AndLinux thingiemajig to use a filesystem that MSVS can see.

That's exactly what I've been doing. I'll keep up learning vim as well.
Anyhoo, thanks again for all the help! I'm gonna hit the books for awhile, I'm starting to see that I need to read / program more and forum a bit less.
NOT that you guys haven't been great, but I realize I need to establish a deeper understanding before I can have some of the bigger questions answered.
24 May, 2009, quixadhal wrote in the 72nd comment:
Votes: 0
One key to learning how to use VIM is to learn its history. It's a feature-expanded version of the VI editor, which itself is a visual version of the ED editor. ED was designed to work on hard-copy terminals (teletypes), which had no screen but instead sent everything directly to fanfold paper. As such, it was line-oriented, and designed with very powerful regular expression replacement, all operations could be repeated when prefixed by a count, all operations could be applied to a range of lines. All of this was designed to be done with a minimal amount of typing, and thus suited the environment perfectly. Today, few people use ED directly, but a nearly identical program (SED) is commonly used for post-processing.

When glass terminals started becoming popular, VI started to catch on. It would display the whole page at once, and it contained the entire ED editor as the "colon mode". It allowed simple ways to move around the screen, and scroll the document as needed. The key to remember here is that VI is a moded editor. You are always in "command mode", where every key DOES something, except for the times you have issued a command to insert text – at which point you are in "insert mode", and every key is literally inserted into your document, except the ESCape key, which escapes back to command mode.

Part of the reason I love VI is probably that the very first word processor I had was Easy Script for the Commodore 64. It also used the concept of modes, using the F1 key as escape, and so it was very natural for me to pick up on vi. It also explains why I have trouble using Visual Studio and consider it klunky at best. :)

Remember, the guys who designed UNIX hated typing. Everything in UNIX is designed as if you had to use it blind on a teletype, because that's often what they had to do to get it installed!
60.0/72