Print

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

[Blacken]

Maybe thay might have given sufficient legal assurance(only *maybe*, because I haven't looked it up), but have they guarenteed that any future developments to the language will fall under a similar agreement, and, if not, that they don't have an internal implementation that they will reveal for something that imitators can do but wasn't included in the initial agreement that they can use to eliminate competition?

Irrelevant. New features do not make the old any less useful for applications on Linux--at worst it might reduce porting of .NET applications to Linux (which is already an in-house affair, it's generally used for bizlogic applications only).

If they wanted to make an unnoticable loophole an later use it if they feel like it, they could probably have a few thousand lawyers working on it together, and come up with something that any individual would never spot.

I suggest you get a clue about law before making statements as inane as this. There are no magical backdoors that people somehow can't see. This is not how law works.

Alternatively, they just release a critically important feature that makes everything far easier than ever before, and decide to keep that feature themselves. Since it would be so useful of a feature, unless what they have said forces them to allow imitations, few programs could run on non-microsoft implementations.

Which has nothing to do with GNOME, which uses protected libraries only and is the only thing that Linux has to worry about. Bizlogic porting to Linux is not why Mono exists.

[Lordinquisitor]

Lots of useful input here, i`m really grateful!

Though, i changed my plans. A strategy game seems to be a bit too complex. So i will probably try to make a little roguelike. (Found a little tutorial for python and one for c++, both aren`t finished so i will probably need help somewhere.  )

With pirates and ships. I said it. If anyone steals the idea i`m going to kill him. Slowly.

Still, i haven`t decided which language to use. Basically it`s c++ vs python now.

[eerr]

Just so you know, ASCII lab already has support for color ASCII characters printed at any spot on the screen.

Plus C # isn't liable to write to random parts of your computer...(verses C++)

I don't know anything about python though.

[Jookia]

C++ has bracekts.

[Blacken]

Lots of useful input here, i`m really grateful!

Though, i changed my plans. A strategy game seems to be a bit too complex. So i will probably try to make a little roguelike. (Found a little tutorial for python and one for c++, both aren`t finished so i will probably need help somewhere.  )

You need to learn to walk before you can run. Go through this book, ensure that you understand it (asking questions is always a good idea, and there's #bay12prog on IRC where Alexhans and I at least usually are), and at the end of it you should be competent enough to develop the game you might want to build.

Trying to take on far too much too quickly is the fastest way to lose interest. It's not going to be "fun" to go through a more standard system of learning to write code, but you will be a better programmer capable of more easily turning your ideas into reality. There's a structure to this stuff, and going around it certainly can be done--but you won't be as good and you won't be as able to do what you really want to do down the line.

Still, i haven`t decided which language to use. Basically it`s c++ vs python now.

With all due respect--and I mean that, you clearly aren't stupid, though you are not well-informed and a lot of this thread isn't helping you because it's kind of the blind leading the blind--you aren't competent to write safe, sane C++. I've been using it for almost a decade and I'm not qualified to write it. C++ is incredibly difficult to correctly wield and writing dangerous code is all too easy.

Stick with Python or something similarly well-structured and well thought-out. Python, C#, even some BASIC variants. C++ is not the smart way to go.

[Shades]

C++ is incredibly difficult to correctly wield

I disagree with this, and further think even if it was the case the best way to learn would still be to play around with it. The rest of your advice I'd generally agree with, especially regarding that book, which is useful whichever language you end up learning first, and about asking questions. The community is the way you'll become a great programmer. It's not always about knowing how to solve a problem but often where and who you know you can ask to be pointed in the right direction.

[Blacken]

I disagree with this, and further think even if it was the case the best way to learn would still be to play around with it.

You can disagree all you like, and that's fine, we can trivially see that you don't find massive security holes because of smash stacking or return-to-libc type of failings in .NET or Python or Java. C++ is inherently insecure, extremely exploitable, and beyond "dangerous." Wizard programmers may use C and C++ correctly (and I mean the "OpenBSD badasses" sense, not "lol I wrote a game")...but nobody else does, and it's a crime in progress to foist that shit on other people).

I mean, shit. If I challenged you to write a C program that took two numbers as input, added them together, and printed the result to screen...you couldn't do so robustly. In C++ it's barely possible, and I'd bet anybody with a little knowledge could pretty trivially break even most robustly-designed attempts. It's just absolutely goddamned silly to think you can write secure code with it short of being a wizard programmer, and if you're not...then you should be using something smarter.

[Starver]

To add a wildcard to the mix, I tend to rapidly prototype some things in Perl.  In fact, I do it so much that quite a few things don't get out of the "rapid prototyping in Perl" cycle, and I spoil myself with the complete typeless nature of the language[1].

It is of course far slower than a proper compiled language (and while there's a "perl2exe" out there, it's both subjected to a trial period licence and really only bundles the perl interpreter in with the script it's interpreting, a bit like the original pkzip2exe did for self-extracting files) and I just can't get on with the Tkx module in windows (even though I can get Tk to sing and dance in a Linux environment).  But there's a lot of power in the core code.  Which probably makes it very bad for actually learning, but does concentrate you into good programming practice (proper naming conventions, commenting, structuring your code and, though I don't do this nearly as much as I ought to, developing one's own library of Perl modules to handle common bits of code that one develops in lieu of (or despite) existing modules.

So, I'd never suggest it as a learning language, and probably not as a gaming one, but it could be a handy tool to work out processes.  And alongside another language sufficiently different[2] to add to your computer-polyglotism without confusing yourself about syntax (i.e. mixing with PHP causes problems, IME[3]) but instead lets you work out the general idea of the data flow and forces you to learn what is and isn't possible in the eventual target language when converting.

As you can tell, this isn't so much a recommendation as a "I do this, but it probably wouldn't suit everybody" post, but I started out writing it with far better intentions than that...  I now realise that I might as well suggest you use something like Forth (a nice little language but perhaps not best suited to gaming .  Or just about anything except COBOL, which was one of the most godawful languages I ever had the misfortune to have used, and (IMHO) severely compromised by the fact that it appears to have been developed entirely so that it was more human-readable than other languages of the age (not itself a bad thing, of course), and yet enforced silly syntactic requirements (as opposed to conventions) such as precise white-space indenting that were of practical use to neither man nor machine, in the long run.

Did that help, then?  Probably not.


[1] e.g. Send a variable containing an array reference into a function, test to detect this when you access the parameter by reference itself within the function and then operate both upon the given external array and produce a value that you can poke directly back into the variable originally offered to the function so that the next function along sees it as a value and can access the newly modified referenced array...  I mean, you could do something like that in the likes of Delphi with "procedure Foo(var x: pWhatever)" and some awkwardness, and various C flavours lets you do it if you also wriggle the nature of pointers around a little more than K&R/ANSI really wants you to do.

[2] If in doubt, I suppose you could stick to function-orientation in Perl while using object orientation in whatever C-form you're working with.

[3] e.g. I write my web-site back-ends in pure Perl, serving up the HTML with home-grown routines.  PHP confuses me slightly more than I think it should because it shares so much with Perl, yet is of course more or less as SSI and might as well be Javascript (IMHO) if not for putting most of the load on the server instead of the browser.

[qwertyuiopas]

I mean, shit. If I challenged you to write a C program that took two numbers as input, added them together, and printed the result to screen...you couldn't do so robustly. In C++ it's barely possible, and I'd bet anybody with a little knowledge could pretty trivially break even most robustly-designed attempts. It's just absolutely goddamned silly to think you can write secure code with it short of being a wizard programmer, and if you're not...then you should be using something smarter.

Bad example. Why? Because of how many predefined functions exist for number input/output. You don't even have to worry about buffer length, and that's where the greatest security flaws originate in simple programs.

Spoiler (click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    if(argc<3 || !argv[1] || !argv[2])
      return EXIT_FAILURE;
    printf("The sum is:\n  %ld\n",strtol(argv[1],0,0) + strtol(argv[2],0,0));
    return EXIT_SUCCESS;
}
Due to the nature of the various functions used, it supports taking input as hex or oct numbers, and non-numbers count as 0. Negative numbers are also accepted.
Changing a few small bits, it can work on floats or doubles.

[Lordinquisitor]

You need to learn to walk before you can run. Go through this book, ensure that you understand it (asking questions is always a good idea, and there's #bay12prog on IRC where Alexhans and I at least usually are), and at the end of it you should be competent enough to develop the game you might want to build.

Trying to take on far too much too quickly is the fastest way to lose interest. It's not going to be "fun" to go through a more standard system of learning to write code, but you will be a better programmer capable of more easily turning your ideas into reality. There's a structure to this stuff, and going around it certainly can be done--but you won't be as good and you won't be as able to do what you really want to do down the line.

Oh, be assured that i`ll try to learn step after step. I won`t rush it. I actually decided that my previous goal would have been too ambitious for a beginner like me.
And a great link, btw.

[Kai_Kratz]

Most importantly you should start learning, right now, any language is ok! If you get to a point where you do not know how to continue, ask questions. Maybe head over to http://www.gamedev.net/ and take a look at the beginners section.

Hmm... ok maybe there is something even more important than "start right now" and thats "Have Fun!"

How about you come back and report on your Progress and get some "Assignments" from the forum crowd?

For example:
Write a function to compute the sum of the first n prime numbers.

Write a function to compute the first n numbers of the fibonaci sequence (computed with/without recursion)

I think most people here would be glad to give you a kickstart

-Kai

[Lordinquisitor]

For example:
Write a function to compute the sum of the first n prime numbers.

Write a function to compute the first n numbers of the fibonaci sequence (computed with/without recursion)

Sounds like fun. 

[Kai_Kratz]

For example:
Write a function to compute the sum of the first n prime numbers.

Write a function to compute the first n numbers of the fibonaci sequence (computed with/without recursion)

Sounds like fun. 

Ehem... i admit it doesn't sound like fun ^^

[Shades]

I mean, shit. If I challenged you to write a C program that took two numbers as input, added them together, and printed the result to screen...you couldn't do so robustly. In C++ it's barely possible, and I'd bet anybody with a little knowledge could pretty trivially break even most robustly-designed attempts. It's just absolutely goddamned silly to think you can write secure code with it short of being a wizard programmer, and if you're not...then you should be using something smarter.

Code: [Select]

int main(int argc, char* argv[])
{
  if(argc<3 || !argv[1] || !argv[2]) { return EXIT_FAILURE; }
 
  try
  {
    cout << (boost::lexical_cast<int>(argv[1]) + boost::lexical_cast<int>(argv[2]));
  }
  catch(boost::bad_lexical_cast &)
  {
     return EXIT_FAILURE;
  }
  return EXIT_SUCCESS;
}


Longer than Qwertyuiops version but a different way of doing it. Also I've not compiled it so there might be typos, the concept is clear enough though.

[Blacken]

I mean, shit. If I challenged you to write a C program that took two numbers as input, added them together, and printed the result to screen...you couldn't do so robustly. In C++ it's barely possible, and I'd bet anybody with a little knowledge could pretty trivially break even most robustly-designed attempts. It's just absolutely goddamned silly to think you can write secure code with it short of being a wizard programmer, and if you're not...then you should be using something smarter.

Bad example. Why? Because of how many predefined functions exist for number input/output. You don't even have to worry about buffer length, and that's where the greatest security flaws originate in simple programs.

Spoiler (click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    if(argc<3 || !argv[1] || !argv[2])
      return EXIT_FAILURE;
    printf("The sum is:\n  %ld\n",strtol(argv[1],0,0) + strtol(argv[2],0,0));
    return EXIT_SUCCESS;
}
Due to the nature of the various functions used, it supports taking input as hex or oct numbers, and non-numbers count as 0. Negative numbers are also accepted.
Changing a few small bits, it can work on floats or doubles.

Actually, it's a great example, and you proved my point for me. Your code is not robust. Printf returns the number of characters sent to stdout as its return value. Since you did not ensure you were not dealing with a locked terminal or that your output was being piped somewhere unwritable, your code has failure conditions that are unchecked but very important: it's both very small, and very important, to make sure your output is actually going somewhere. (Your code also takes non-numbers as zero, instead of doing the right thing and complaining and stopping.) And there's no really good way to handle something like this in C/C++, because, for the most part, return values are ignored because valid return values are sometimes used to indicate invalid operations! It is acceptable in Standard C/C++, for example, to return the memory address "0" from malloc()/new--that is, it's not forbidden. Which is almost always overloaded as NULL. Similar gotchas are all over the place.

It's an excellent example, specifically because of how easy it seems.


EDIT: Oh, almost forgot. I actually meant taking textual input from stdin, but that's fine. It's possible to hoist injected code in on the stack via argc/argv too, though, so that's certainly neither robust nor secure.


C++ includes some exceptions for dealing with failure conditions within iostreams, which is marginally better, but they're inconsistently used and few people enable them because C++ is the only language out there where exceptions are notably slower and make for bloated code images.

To be an effective C/C++ programmer you must be an encyclopedic genius who knows everything off the top of his head, or go look up every library function to ensure proper use even when you "know" what it does. Consistency? Predictability? Bah, fuck that, we do what we want! It can be done, though. By geniuses. I've been using C++ for a decade, though, and it serves only to demonstrate how little I actually know.


Below in the spoiler is an example of more robust C code that does the same thing I asked. It is not, however, robust. See if you can spot why not.

Spoiler (click to show/hide)

Code: [Select]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#ifdef _MSC_VER

#ifndef _CRT_SECURE_NO_DEPRECATE
#define _CRT_SECURE_NO_DEPRECATE
#endif

#endif

int main()
{
int err = 0;
int val = 0;
char* input = NULL;

double num1 = 0.0f;
double num2 = 0.0f;
double result = 0.0f; /* yes, there will be rounding errors */

err = fputs("This application is intended to accept two integers\n" \
"as input, add them, and display the resultant addition.\n\n", stdout);
if (err == EOF) {
fputs("Error writing to stdout.\n\n", stderr);
return EXIT_FAILURE;
}


/* get num1 */
err = fputs("First number: ", stdout);
if (err == EOF) {
fputs("Error writing to stdout.\n\n", stderr);
return EXIT_FAILURE;
}
val = scanf("%lf", &num1); /* "lf" = double, as per scanf spec */
if (val != 1) {
fputs("Error receiving first number. Check your formatting.\n\n", stderr);
return EXIT_FAILURE;
}
if (val == EOF) {
fputs("Error receiving first number. EOF located.\n\n", stderr);
return EXIT_FAILURE;
}


/* get num2 */
err = fputs("Second number: ", stdout);
if (err == EOF) {
fputs("Error writing to stdout.\n\n", stderr);
return EXIT_FAILURE;
}
val = scanf("%lf", &num2); /* "lf" = double, as per scanf spec */
if (val != 1) {
fputs("Error receiving second number. Check your formatting.\n\n", stderr);
return EXIT_FAILURE;
}
if (val == EOF) {
fputs("Error receiving second number. EOF located.\n\n", stderr);
return EXIT_FAILURE;
}

result = num1 + num2;

err = fprintf(stdout, "The result is: %f. \n\n", result);
if (err < 0) {
fputs("Error writing output.\n\n", stderr);
return EXIT_FAILURE;
}

return EXIT_SUCCESS;
}