[QUOTE=Protocol7;49455913]Even then, a riled up person in the programming subsection is less likely to fly off the handle and go "you're a fucking moron" unless you say something objectively wrong like "C++ doesn't support classes!!!"[/QUOTE]
C++ supports classes?
Alan Kay would have a few words to say on that...
[editline]5th January 2016[/editline]
[QUOTE=Rocket;49457499]by get rid of i don't literally mean delete all C code and you know that.
here's just a sampling of bad things with C:
* there are zero good built-in ways to structure your project. no objects, no classes, no modules. just name your functions with underscores i guess, that's cool.
* so much undefined behavior
* string handling is absolutely shit
* there's not even a real bool type
* lots of things are architecture-dependent. that is dumb.
* bad error handling, if any
* macros, and not good macros
* pointers are bad for 98% of users
* the above issues + many others mean the language is practically asking you to implement a security flaw
* bad debugging support
[editline]4th January 2016[/editline]
C's biggest selling points are that "it's fast" and "it's better than writing assembly" which are not good reasons to use C[/QUOTE]
[I]* there are zero good built-in ways to structure your project. no objects, no classes, no modules. just name your functions with underscores i guess, that's cool.[/I]
When you think about it, using structs and function pointers isn't really all that different to letting the compiler use them for you...
[I]* so much undefined behavior[/I]
So what would you rather have? Every single behaviour be defined, even if it makes no sense and slows down the compiler due to forcing them into a specific implementation? 90% of compilers will give an error or at least warning upon undefined behaviour anyways.
[I]* string handling is absolutely shit[/I]
I'll give you that one, but you can use libraries to improve things.
[I]* there's not even a real bool type[/I]
Is there need for one? Just use an enum and you get literally exactly the same thing.
* lots of things are architecture-dependent. that is dumb.
Are you talking about undefined behaviour here? If you are, that's the reason it's undefined behaviour. If you aren't, then please could you mention them?
[I]* bad error handling, if any
* macros, and not good macros[/I]
I'll also give you those.
[I]* pointers are bad for 98% of users[/I]
I prefer concrete pointers to the wishy-washy maybe-reference-maybe-value depending on what the language designers were feeling that day. At least with C you KNOW what is passed by reference (a pointer) and by value, but with Java and other similar languages it seems as if half of the types are passed by value and half are passed by reference depending on a dice roll.
[I]
* the above issues + many others mean the language is practically asking you to implement a security flaw[/I]
It's probably easier to implement securities flaws in more complex languages. C doesn't really hide much. Now, if you have a 100% sandboxed language, then sure, you're more likely to get security flaws in C, but otherwise C is pretty safe because it's so simple. If you are writing security-critical code, you shouldn't be writing it yourself anyways - get a proven library.
[I]* bad debugging support[/I]
Depends on your IDE. Blaming C for bad debugging support is like blaming pizza for being burnt. It depends on how you cook it.
In Java, any lowercase class is a value (unless you're shit at naming classes).
:goodjob:, mono.
[code]
byte[] Data = new byte[42];
for (int i = 0; i < Data.Length; i++) {
Data[i] = NetworkStream.ReadByte();
}
[/code]
is different than
[code]
byte[] Data = new byte[42];
NetworkStream.Read(Data, 0, Data.Length);
[/code]
[editline]5th January 2016[/editline]
And by this i mean, the first works while the second fails at reading data longer than 7ksomething bytes.
[QUOTE=Rocket;49457438]
rust has some promise on this front.[/QUOTE]
aren't Rust executables pretty big? it's a problem when you're working on embedded systems that only have 64KB memory or some shit. sounds ridiculous, but I had to do it before. there wasn't enough memory for me to use any libraries but the one provided so you can manipulate the I/O on the board
I ended up using my day off of simple peace, quiet, and relaxation to write a simplified flight model for an airplane.
It uses the real formulas for drag and lift, albeit with simplified inputs, so it reacts mostly like a plane does as long as you give it realistic inputs. Examples of stuff you enter in are cross sectional areas for front/top/side, drag coefficients for front/top/side, wing area, and thrust. Stuff like altitude and gravity also affect how the plane will fly.
There’s still some oddities specifically with how the plane reacts to yaw induced side-slips, and the way the player turns the plane is a really abstracted and wonky solution. I want to add (somewhat abstracted, but still physically real) deflecting control surfaces next time I get a chance to work on this. I think it’ll solve a lot of the little physics oddities that remain.
I’m not trying to make DCS or anything, but I think it would be pretty cool if I could plug in real numbers and get rough approximations of real planes. So far it’s already sort of doing that, which is neat.
The old HUD I made a while ago turned out to be surprisingly easy to drop in. Aside from some minor things to fix due to version differences (I originally made it back in the 4.6 beta), it works perfectly fine.
[img]http://i.imgur.com/8Ne6N7L.jpg[/img]
[QUOTE=cartman300;49458614]:goodjob:, mono.
[code]
byte[] Data = new byte[42];
for (int i = 0; i < Data.Length; i++) {
Data[i] = NetworkStream.ReadByte();
}
[/code]
is different than
[code]
byte[] Data = new byte[42];
NetworkStream.Read(Data, 0, Data.Length);
[/code]
[editline]5th January 2016[/editline]
And by this i mean, the first works while the second fails at reading data longer than 7ksomething bytes.[/QUOTE]
Stream.Read is not guaranteed to return a full buffer([url]https://msdn.microsoft.com/en-us/library/system.io.stream.read(v=vs.110).aspx)[/url]. Reading less than requested is pretty typical for tcp. [url=https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/IO/BinaryReader.cs#L505]BinaryReader.ReadBytes[/url] does what you want. It keeps calling read until the buffer is full or EOF.
[QUOTE=proboardslol;49456924]I think Microsoft develops C# to try to get people to stop using explicitly cross-platform languages[/QUOTE]
What? Have you been paying any attention lately?
[url]https://github.com/dotnet/[/url]
[QUOTE=Nigey Nige;49455777]Not stupid at all. That's just capitalism.exe for ya[/QUOTE]
More specifically: A product's known circumstances are part of its perceived subjective value.
I'm pretty sure most people take it into account, but not many go out of their way to make a truly informed decision.
[QUOTE=Clavus;49457229]The Vive being technologically more advanced than the Rift isn't really true, mostly because folks kept comparing it to the old Rift DK2. The Rift and Vive consumer versions will be pretty much equal in feature-set from the looks of it, and the specs are nearly equal too (expecting the Rift's screen to be a bit better cuz Samsung). Vive focusses more on room-scale and launches with it, Rift comes with a Xbox gamepad because devs have been developing for that for the last two years, and launches its hand-tracking Touch controllers in H2 2016. Main difference is that the Vive uses the Lighthouse tracking system which seems to scale more easily, while the Rift can use multiple cameras to do room-scale (but might not scale as well, though using cameras can open up possibilities in the future?)
From a developer standpoint it's not that hard to support all HMDs. OpenVR supports most out of the box, though sometimes lacks some features like the dedicated Oculus SDK does. That'll probably improve in the future, but it's already stupidly easy to build a VR game in Unity or Unreal.[/QUOTE]
I think the positioning and movement aspects of the Vive do have some technical advantages compared to the rift, that said we dont really have anything to compare as we dont have the consumer versions of either.
However, apparently HTC/Steam are going to announce something at CES, so I would wait at least until then to decide wether or not to preorder the rift!
[QUOTE=Richy19;49455858]I would kind of agree with this for most of FP, but the programming subsection is generally quite mature and respectful of peoples thoughts and opinions[/QUOTE]
You can get away with a contrarian opinion, but you have to either package it as non-absolute on most of the site or add hard (statistical) data to support your views.
That's also true for this section here, but to a much lesser extent I'd say. The main issues seem to be bad criticism and bad reactions to criticism, but that's more an issue with (insufficiently thorough) presentation than the core ideas themselves.
Still, I consider Facepunch about a hundred times more amenable to dissent than e.g. Reddit and most similar sites.
What Are You Arguing About? January 2016
I wanted to have cars following set routes in my game but I couldn't be arsed making a whole navigation system so I made trigger boxes which set a vehicle's steering to a certain value when it passes through. I tried to make a video but flying cars kept getting in the way. Job done, next job
[QUOTE=proboardslol;49456924]Right but there's a near 100% chance that a java program will work from system to system. [...][/QUOTE]
I've seen so many Java framework and/or runtime bugs I'm surprised so many of them run properly at all :v:
That said, JDownloader 2 is actually really good (but starts very slowly...), so maybe it's more of a matter of the default systems not encouraging a polished and bug-free end product.
[QUOTE=Rocket;49457438]that's not really a good reason for C to live. get rid of C and come up with a better compile-to-native programming language because C is terrible.
rust has some promise on this front.[/QUOTE]
Oh yeah, Rust is looking like a great alternative to C, it still lets you write the type of code you'd write in C, but with more static analysis to make sure dangling pointers and double-frees do not occur, all skeptics should do themselves a favor and read up on Rust.
Moreoever, it also has an easy way of exposing a C API to Rust code, so you can easily interface with Rust code with anything that has a C FFI integration.
I'm not sure people realise this, but the segfaults you get in C/C++/pretty much any other compiled language which isn't managed *can't* happen in Rust, with no cost at runtime outside of their bounds checking.
[editline]5th January 2016[/editline]
[QUOTE=proboardslol;49457452]Yeah just get rid of C and break 45 years of compatibility. Great idea.
C is a perfectly good language. What about it do you dislike?[/QUOTE]
Christ, nobody is saying "get rid of C", C is staying around but better alternatives are *definitely* due to replace it, I mean who thought the idea of doing strings null-terminated was a good idea? So every time you do a strlen() you potentially run over a buffer if the string actually isn't null terminated, or at least a O(N) operation just to check the length of the string, which is just silly.
[QUOTE=high;49458997]Stream.Read is not guaranteed to return a full buffer([url]https://msdn.microsoft.com/en-us/library/system.io.stream.read(v=vs.110).aspx)[/url]. Reading less than requested is pretty typical for tcp. [url=https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/IO/BinaryReader.cs#L505]BinaryReader.ReadBytes[/url] does what you want. It keeps calling read until the buffer is full or EOF.[/QUOTE][fixed second link]
The [I]buffer[/I] parameter's documentation is incorrect, so it's easy to see why someone would get the wrong impression.
Personally I use something like [code]public static byte[] ReadBytes(this Stream stream, int count)
{
var buffer = new byte[count];
stream.ReadBytes(buffer);
return buffer;
}
public static void ReadBytes(this Stream stream, byte[] buffer) => stream.ReadBytes(buffer, 0, buffer.Length);
public static void ReadBytes(this Stream stream, byte[] buffer, int offset, int count)
{
while (count > 0)
{
var read = stream.Read(buffer, offset, count);
if (read == 0) throw new EndOfStreamException($"Reached end of stream with {count} bytes to read remaining.");
offset += read;
count -= read;
}
}[/code] when I don't have a [I]BinaryReader[/I] anyway (and think it's incredibly silly those aren't built-ins).
[QUOTE=polkm;49459156]superformula stuffs
[t]http://i.imgur.com/bjMmeEq.gif[/t][/QUOTE]
Reminds me of the jellies in Croc
Not sure why
[QUOTE=Profanwolf;49459744]Oh yeah, Rust is looking like a great alternative to C, it still lets you write the type of code you'd write in C, but with more static analysis to make sure dangling pointers and double-frees do not occur, all skeptics should do themselves a favor and read up on Rust.
Moreoever, it also has an easy way of exposing a C API to Rust code, so you can easily interface with Rust code with anything that has a C FFI integration.
I'm not sure people realise this, but the segfaults you get in C/C++/pretty much any other compiled language which isn't managed *can't* happen in Rust, with no cost at runtime outside of their bounds checking.
[editline]5th January 2016[/editline]
Christ, nobody is saying "get rid of C", C is staying around but better alternatives are *definitely* due to replace it, I mean who thought the idea of doing strings null-terminated was a good idea? So every time you do a strlen() you potentially run over a buffer if the string actually isn't null terminated, or at least a O(N) operation just to check the length of the string, which is just silly.[/QUOTE]
Strings are null-terminated in software written in almost any language, not just C. The difference is that other languages tend to do it transparently so that the programmer doesn't need to care about it.
As to why... they are null-terminated so they can be any length. If a value was stored before the string instead, it both makes handling strings more complex (you can't just use an array of chars, you need a more complex structure) and it limits the lengths of strings (if you use 1 byte to store length, strings can only be 127 chars long), unless you use complicated schemes. Any other solution greatly increases the complexity of handling strings, anyways.
It doesn't really matter that finding the length is O(n) because you can loop so quickly anyways. Doesn't matter if the big O is terrible when the worst case situation of strings millions of characters long still takes mere ms to loop through (and if you really can't afford the time, you can just cache the length).
[QUOTE=Richy19;49459445]I think the positioning and movement aspects of the Vive do have some technical advantages compared to the rift, that said we dont really have anything to compare as we dont have the consumer versions of either.
However, apparently HTC/Steam are going to announce something at CES, so I would wait at least until then to decide wether or not to preorder the rift![/QUOTE]
On that note: [URL="http://blog.htcvive.com/2015/12/the-vive-heads-to-ces-2016/"]Quite a few other companies will have presentations involving Vive.[/URL]
[editline]5th January 2016[/editline]
[QUOTE=Tommyx50;49459839]Strings are null-terminated in software written in almost any language, not just C. The difference is that other languages tend to do it transparently so that the programmer doesn't need to care about it.
As to why... they are null-terminated so they can be any length. It doesn't really matter that finding the length is O(n) because you can loop so quickly anyways. Doesn't matter if the big O is terrible when the worst case situation of strings millions of characters long still takes mere ms to loop through (and if you really can't afford the time, you can just cache the length).[/QUOTE]
Many, [I]many[/I] applications and programming systems with transparent string handling length-prefix them instead, which [I]in practice[/I] has all of the same benefits, can be processed much faster in many common scenarios (like skipping past one of them embedded in other data or allocating buffers for editing one) [I]by default[/I], and usually only needs at most four bytes more memory per instance.
[QUOTE=high;49458997]Stream.Read is not guaranteed to return a full buffer([url]https://msdn.microsoft.com/en-us/library/system.io.stream.read(v=vs.110).aspx)[/url]. Reading less than requested is pretty typical for tcp. [url=https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/IO/BinaryReader.cs#L505]BinaryReader.ReadBytes[url] does what you want. It keeps calling read until the buffer is full or EOF.[/QUOTE]
Hey man, what's up?
[QUOTE=Tommyx50;49459839][B]Strings are null-terminated in software written in almost any language, not just C[/B]. The difference is that other languages tend to do it transparently so that the programmer doesn't need to care about it.[/QUOTE]
There's actually quite a few languages like Perl, Python, Java, C#, C++ which all use length-prefixed strings as Tamschi pointed out.
[QUOTE=Tommyx50;49459839]
It doesn't really matter that finding the length is O(n) because you can loop so quickly anyways. Doesn't matter if the big O is terrible when the worst case situation of strings millions of characters long still takes mere ms to loop through (and if you really can't afford the time, you can just cache the length).[/QUOTE]
But if every place where you check string lengths needs to be a O(N) operation it'll quickly add up, besides caching the length would essentially make it a length-prefixed string in which case you might as well make it one from the beginning. There's good reason many languages want to avoid this cost as it is, you can just look through existing and past CVE's and see how many of them involved null-terminated strings.
[QUOTE=Tommyx50;49459839]if you use 1 byte to store length, strings can only be 127 chars long[/QUOTE]
Pretty sure that every language except Java has unsigned byte types so it would be 255. And putting a 4 byte unsigned integer would still be a pittance but allow a 4 GiB (~4.2 billion character) string.
This is a dumb argument though. C still has it's uses, it's pretty much required for low level stuff on micro controllers (perhaps less so in the future as ROM becomes smaller and cheaper) or if you don't like OOP.
Recently I've been following along with [URL="https://handmadehero.org/"]Handmade Hero[/URL] which is entirely in C (compiled as C++ for some extra compiler features IIRC but apart from win32 stuff like DirectInput (which I had to do myself to replace XInput because my controller doesn't do XInput - fun stuff) there is no C++ stuff in there). I think that learning a completely different way of approaching issues that doesn't use any classes will make me better as a programmer even if I never use a non OOP language again.
I wanted to mess around with max file name lengths and decided to do it in WinAPI + C instead of using C# despite knowing that the later would be take a couple of minutes instead of half an hour googling WinAPI functions.
I don't think you can truly be a great programmer if you only ever use one language. You can certainly become a [I]good[/I] programmer with only one but the extra knowledge gained from learning about the different approaches used in each language helps you think outside what is normal. I am personally guilty of pretty much only using C# but I'm working on that.
[QUOTE=Rocket;49457499]by get rid of i don't literally mean delete all C code and you know that.
here's just a sampling of bad things with C:
* there are zero good built-in ways to structure your project. no objects, no classes, no modules. just name your functions with underscores i guess, that's cool.
* so much undefined behavior
* string handling is absolutely shit
* there's not even a real bool type
* lots of things are architecture-dependent. that is dumb.
* bad error handling, if any
* macros, and not good macros
* pointers are bad for 98% of users
* the above issues + many others mean the language is practically asking you to implement a security flaw
* bad debugging support
[editline]4th January 2016[/editline]
C's biggest selling points are that "it's fast" and "it's better than writing assembly" which are not good reasons to use C[/QUOTE]
Sadly, you'll always require at least one language that doesn't have all of that because we still have those little brothers called "microprocessors" and their limited memory. Classes are a no-no because of that.
I like C as intermediary language, even though I don't use a language that compiles to C. And I guess it's the best choice for library bindings.
[QUOTE=Elec;49460179]Sadly, you'll always require at least one language that doesn't have all of that because we still have those little brothers called "microprocessors" and their limited memory. Classes are a no-no because of that.[/QUOTE]
I mean, namespaces have nothing to do with the run-time component of it all, it's just the way of dividing up your program into separate parts that don't overlap, name wise. C just doesn't do this at all, so you end up with stuff like libraryname_function_here, instead of names confined to a namespace like given a c++ example:
[code]
namespace Stuff {
void does_things();
};
Stuff::does_things();
[/code]
And classes? That all depends on how you use them, in a lot of cases (like C++) they're extremely lightweight. (I encourage you to look at the generated assembly for some classful code in C++ some time, it's enlightening)
It's folly to believe that what's on his list can't exist because of "memory constraints" because most of the things he mention are compile-time constructs. Possibly the lack of better error handling can be considered since exceptions aren't always so cheap, but even there people doing projects in C tend to do "exceptions" with longjmp and friends instead, which has it's own share of problems.
I'd be fine with these arguments as long as people are aware that [I]other languages like C which do all of these things better[/I] do exist, the one argument which can be considered is possibly that of compatibility, where a C compiler exists for almost every single platform in existence.
Managed to improve the 'file city' generation algorithm after taking my sweet time during my unpaid leave.
Now it will generate around 500 base files as the city foundation, and will generate more as you walk on the corresponding folders. Still can be optimized though.
Also managed to squash that bug that create those weird floating files
Still looks nothing like a city though :v:
The character is in the middle of the screen. Danm watermark
And the file names (white tags that appears intermittently) are barely visible due to video compression
[img]http://i.imgur.com/SKpELS2.gif[/img]
[img]http://i.imgur.com/q16Mm1t.gif[/img]
[QUOTE=hakimhakim;49460628]Managed to improve the 'file city' generation algorithm after taking my sweet time during my unpaid leave.
Now it will generate around 500 base files as the city foundation, and will generate more as you walk on the corresponding folders. Still can be optimized though.
Also managed to squash that bug that create those weird floating files
Still looks nothing like a city though :v:
The character is in the middle of the screen. Danm watermark
And the file names (white tags that appears intermittently) are barely visible due to video compression
[img]http://i.imgur.com/SKpELS2.gif[/img]
[img]http://i.imgur.com/q16Mm1t.gif[/img][/QUOTE]
That looks rad. If you're sick of watermarks try [url=https://obsproject.com/]Open Broadcaster Software[/url].
[editline]5th January 2016[/editline]
Also I wrote a blog post about [url=https://game-devvo.tumblr.com/post/136679997390/work-dumb-and-fast]my awful methodology[/url] for staying motivated while I work.
[QUOTE=Nigey Nige;49460843]That looks rad. If you're sick of watermarks try [url=https://obsproject.com/]Open Broadcaster Software[/url][/QUOTE]
Or [URL="http://store.steampowered.com/app/400040/?snr=1_7_7_151_150_1"]ShareX[/URL]
Snip. I'm not arguing with the microsoft/c# fan club again
Sorry, you need to Log In to post a reply to this thread.
