Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pisskop]

Well, not to exactly hijack this for a moment, but....

to hijack this for a moment, Piss has writtena 'hello world' doodad in c, but is unsure how he make its go.  what program do I use to make it go in linux?

I mean, it wont let me run the code on its own, right?  it wont let me do the limited amount of compiling Im familiar with...

[wierd]

in linux?

You need a makefile, make, and gcc.

[Arx]

in linux?

You need a makefile, make, and gcc.

Not really. You need gcc/g++. And the 'make' command may actually run fine on a simple program without a makefile.

To compile, just run 'gcc <filename>.c -o <output filename>'. For C++, use <filename>.cpp and g++.

Worry about make and makefiles when they're actually relevant.

[pisskop]

\o/

I dun didit
    I also didnt make enough spaces.

Thanks.

[Mesa]

Lua is also a good first choice for similar reasons Python is.

It's also a bit more 'applicable' than Python (at least given the context of this forum) simply because it's used as the go-to scripting language for a lot of games for modding purposes (Don't Starve, Civilization 5, The Binding of Isaac: Afterbirth+ [whenever that comes out], Garry's Mod, Roblox, Factorio, as far as the big ones go) which gives you a good and familiar environment to practice in and get 'tangible' results, compared to just writing abstract algorithm implementations, 'in a void'.
Not sure about its use in engines out there.

It also features an interpreter and has a similarly easy-to-grok syntax.
(I tried to write some Lua today myself but apparently even that is too much for me, but not so much because of the syntax.)

[alexandertnt]

\o/

I dun didit
    I also didnt make enough spaces.

Thanks.

Nice.

I would recommend not putting a file extension on the end of your output binary though. ".cpp" is usually used for C++ source files (.c for C source files).

Just run "g++ 2nummult.cpp -o 2nummult" and "./2nummult"

[Starver]

I could be a bit of a bastard and point you at Perl (I habitually use ActiveState on Windows, never even heard of Strawberry before getting that page) to understand various principles of programming, but it's a bit like plonking you in a general-purpose scrapyard with a complete toolset and persuading you that you can construct a car from the bits without telling you which loose components are actually from whitegoods or nautical/aeronautical machines and probably should be avoided.

But as a powerful scripting language, you can write it in imperatve, procedural and or object-oriented styles as desired (so force yourself to adopt the one(s) used by the compiled language you're trying to work with) and style it in a manner that makes for easy conversion to the other (probably fellow C-dialect) language, perhaps even by writing a "perl2C" script of your own... 

It's more geared towards data (text in, or batch processing, text/binary-files out), so even with Perl/Tk it is inefficient for graphical games programming (and because it is scripting, would be slower than DF's internals even though it's trivial to make it look the same in attempt to reimplement your own).

But I like using Perl to prototype more complex/polished programs before then (if necessary) reimplementing in a compiled flavour of C. You might find Python-then-C++ (or just an IDE for C<flavour> that you find you get along with) to be your equivalent. But LUA on the side (a language I started looking at but haven't touched for ages now, given my Perl obsession) might be as useful as mentioned.

[i2amroy]

Lua is also a good first choice for similar reasons Python is.

Lua's pretty nice, with the benefit of it's more common usage as a scripting language for games, though it does suffer somewhat from the fact that it is, you know, a scripting language that is designed to be embedded within other languages rather than form the core of a program all on it's own.

[pisskop]

Is this the proper thread to cry tears into?

I have a chunk of c++ here.  The former

Spoiler (click to show/hide)

        // Generate bodies / zombies
        rn = rng(15, 20);
        for (int i = 0; i < rn; i++) {
            int zx = rng(0, SEEX * 2 - 1), zy = rng(0, SEEY * 2 - 1);
            if (passable(zx, zy)) {
                if (furn(zx, zy) == f_bed || one_in(3)) {
                    add_item( zx, zy, item::make_corpse() );
                } else {
                    mtype_id zom = mon_zombie;
                    if (one_in(6)) {
                        zom = mon_zombie_spitter;
                    } else if (!one_in(3)) {
                        zom = mon_boomer;
                    }
                    add_spawn(zom, 1, zx, zy);
                }
            } else {
                //This is a wall: try again
                i--;
            }
        }

Works

this:

Spoiler (click to show/hide)

        // Generate bodies / zombies
        rn = rng(50, 70);
        for (int i = 0; i < rn; i++) {
            int zx = rng(0, SEEX * 2 - 1), zy = rng(0, SEEY * 2 - 1);
            if (passable(zx, zy)) {
                if (furn(zx, zy) == f_bed || one_in(3)) {
                    add_item( zx, zy, item::make_corpse() );
                } else {
                    mtype_id zom = mon_zombie;
                } if (one_in(50)) {
                        zom = mon_zombie_child_scorched;
                    } else if (one_in(25)) {
                        zom = mon_zombie_gasbag;
                    } else if (one_in(20)) {
                        zom = mon_zombie_snotgobbler;
                    } else if (one_in(10)) {
                        zom = mon_zombie_spitter;
                    } else if (one_in(10)) {
                        zom = mon_zombie_child;
                    } else if (one_in(6)) {
                        zom = mon_zombie_acidic;
                    } else if (one_in(3)) {
                        zom = mon_boomer;
                    }
                    add_spawn(zom, 1, zx, zy);
                }
            } else {
                //This is a wall: try again
                i--;
            }
        }

Throws errors about zom not being defined.  I dont know.  If I add a mtype_id before zom they read (and then the line add_spawn(zom, 1, zx, zy); fails to read 'zom'), but I shouldnt have to?  zom is simply shorthand for a specific group of monsters.  I am sure Ive otherwise defined the specific critters.


all Im doing is extending the concept of spawning a specified set of critters based upon a dice-roll, correct?



p:
in case you wanna know where I got it from.
this

[wierd]

consider using a SWITCH CASE instead of nested IF THEN ELSE.

I find it is easier to work with, and does not confuse compilers as much.

http://en.cppreference.com/w/cpp/language/switch

Adding more entries to your leveled list will be much easier in the future as well.

[Reelya]

A switch statement wouldn't work with the dice-rolling function he seems to be using. It could work, but he'd have to rethink the logic. e.g. roll the dice once, then assign different outcomes to each value. But switches also can't do a "range" of values, so they have that limitation in comparison to if-else.

[wierd]

That sucks. Switch needs an integer type, not a bool.  It would be much more flexible if it evaluated a bool.

There are ways I can think of to hammer this into a shape I would like, but it isn't nearly as clean as in other languages.

The need to return either an integer or a conditional that evaluates to an integer is bugnuts. This is probably to keep people from making switch statements that have multiple possible cases that would fire though. 

Still, one can "batshit-fake-it", and make "ranges" using something like the integer divide operator.

Something a bit like this?

Code: [Select]


int main()
{
    int i = rng(10,100);
    int iRange = i /10;
    switch (iRange) {
        case 1: std::cout << "i is between 10 and 20";
        case 2: std::cout << "i is between 20 and 30";
        case 3: std::cout << "i is between 30 and 40";
        case 4: std::cout << "i is between 40 and 50";
        case 5: std::cout << "i is between 50 and 60";
        case 6: std::cout << "i is between 60 and 70";
        case default: std::cout << "Catchall for when none of the above hit";
        }
    }

It relies on the fact that integer division discards the remainder, and just tells you how many times i is divisible by 10, as an integer expression.

eg, 10, 11, 12,13,14,15,16,17,18, and 19 all evaluate as "1" when integer divided by 10.

Still bullshit though.  I would much rather that it evaluate a boolean true condition, rather than needing an implicit integer expression.

[Starver]

That sucks. Switch needs an integer type, not a bool.  It would be much more flexible if it evaluated a bool.

If you are using a bool as the conditional, then you might as well just be using an if/else, Shirley?

And you can always "switch (someBoolToIntFunc(boolean_thing)) { case 0: do_false; break; case 1: do_true}" or whatever you want if you want it as a Case for the look of it and/or for continuity...

[wierd]

Say for instance, you want to evaluate a string expression, say after taking some user input.

A string can hold a LOT of possible values, but you only want to act on it when that string is a perfect match for your conditional.

In, eg, visual basic, you would do something like this:
(we are pretending this is a console program, that's why we are using Input$ instead of some other input method to get the user string.)

Code: [Select]


Dim UserString as String
Input$ UserString

Select Case UserString

  Case is = "North"
                  'Do stuff to move north
  Case is = "South"
                  'Do stuff to go south
  Case is = "East"
                  'Do stuff to go east
  Case is = "West"
                  'Do stuff to go West
  Case ELSE
                  'Catch all in case the user string is none of those
END SELECT


Each possible case only fires if the evaluation statement ( (= [some exression]) in this case, but could also be any other logical or comparative operator) evaluates TRUE.

This is VERY robust, and can be used to define ranges--  eg:

Code: [Select]


dim SomeInteger as Int
SomeInteger = RND(100)

Select CASE SomeInteger

  Case is ((>10) AND (<20))
            'do stuff if SomeInteger is greater than 10 and less than 20
  Case ELSE
            'catch all if none of the above are true
END SELECT


There is no real tangible limit to the number of evaluated branches you can suff in a Swith (or Select Case) block.  It is easier to add new branches to than nested IF THEN ELSE, and does not end up with indentation going off into never never land when the evaluated expression list is very deep.

Again, it also does not confuse the compiler as much.

[Starver]

Ah, gotya.  Yes, it varies between languages (I first used Case in Pascal, and I think that allowed complex case-selectors¹, and Ada had that too).

However, same sort of answer. You can probably "enum" something for your "case" value that bunches up a cross-selection (even discontinuous) set of multiple constants, and/or just list some concurrent ones without any statements (even "break") until the last of the list.

Does "case 10:; case 11:; case 12:; case 13:; case 14:; case 15: do_TenToFifteen(); break;" work? I'm not sure without testing, I might be getting my C dialects and C-alike dialects mixed up. "case 10..15: do_Whatever(); break;" would look better, but I'm sure that's not C++...


¹ For TurboPascal/Delphi/Lazarus, I think I did something like (pseudocoded in parts, thanks to being rusty)

Code: [Select]

// Value is a class with a method someMethod such that Value.someMethod = fn(Value)
//   to return someMethod's idea of what Value is supposed to be..
with Value do {
  case someMethod of
    0: ShowMessage("Value "+intToStr(Value)+" was evaluated as action zero.");
    1: ShowMessage("Value "+intToStr(Value)+" was evaluated as action one.");
    else ShowMessage("Value "+intToStr(Value)+" was evaluated as action "+intToStr(someMethod)+", which I do not yet recognise.")
  end;
} // end of 'with Value' enclosure, which might just be an extravogance
  // "case Value.someMethod of" would have worked just as well, but sometimes there's a good reason to do this