[QUOTE=supersnail11;33945322]They fuck up code structure.
[editline]29th December 2011[/editline]
[url]http://fakenamegenerator.com[/url]
You're an idiot, you know that?[/QUOTE]
Those numbers do not pass Luhn's algorithm, YOU'RE the idiot.
[img]http://i.imgur.com/1M4DX.png[/img]
[QUOTE=cody8295;33945403]Those numbers do not pass Luhn's algorithm, YOU'RE the idiot.[/QUOTE]
You're the idiot. As if all credit cards go off just 6 digit issue identification plus some random set of numbers that pass mod 10, hah.
[QUOTE=cody8295;33945403]Those numbers do not pass Luhn's algorithm, YOU'RE the idiot.[/QUOTE]
They do.
[quote=http://www.ee.unb.ca/cgi-bin/tervo/luhn.pl]
Checking [5538 4594 9038 0217]
5 5 3 8 4 5 9 4 9 0 3 8 0 2 1 7
x2 x1 x2 x1 x2 x1 x2 x1 x2 x1 x2 x1 x2 x1 x2 x1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10 5 6 8 8 5 18 4 18 0 6 8 0 2 2 7
1 + 5 + 6 + 8 + 8 + 5 + 9 + 4 + 9 + 0 + 6 + 8 + 0 + 2 + 2 + 7 = 80
80 = 0 mod 10
The test PASSED since the result is zero.
In the above summation, any two-digit product is included
as the sum of its two digits. (e.g. 18 --> 1 + 8 = 9)
[/quote]
[QUOTE=cody8295;33945124]Credit Card Generator, deal with it...
[IMG]http://content.screencast.com/users/codydv/folders/Jing/media/7eab2cad-7a2e-4151-901d-f5be143afda3/2011-12-29_0012.png[/IMG][/QUOTE]
[QUOTE=cody8295;33945181]People still buy them.[/QUOTE]
[QUOTE=cody8295;33945403]Those numbers do not pass Luhn's algorithm, YOU'RE the idiot.[/QUOTE]
[QUOTE=supersnail11;33945464]They do.[/QUOTE]
quoted the hilarious parts
[QUOTE=supersnail11;33945322]They fuck up code structure.[/quote]
How so?
[QUOTE=Kepler;33945518]How so?[/QUOTE]
Because instead of having a nice tree to reason about, your code jumps all over the fucking place.
This is your code:
[img]http://i.imgur.com/6gD1x.png[/img]
This is your code on goto:
[img]http://i.imgur.com/yW0er.png[/img]
Well, I. Am. Embarrassed.
[QUOTE=swift and shift;33945575]Because instead of having a nice tree to reason about, your code jumps all over the fucking place.
This is your code:
[img]http://i.imgur.com/6gD1x.png[/img]
This is your code on goto:
[img]http://i.imgur.com/yW0er.png[/img][/QUOTE]
Well, if I manage my code well, won't it be fine? After all, I've almost completed my Not Skyrim demo with goto statements and it works well.
[QUOTE=Kepler;33945605]Well, if I manage my code well, won't it be fine? After all, I've almost completed my Not Skyrim demo with goto statements and it works well.[/QUOTE]
:gotoexit:, :gotofrog:, :etc:
Though honestly, I've never seen a legitimate need to use gotos. I would bet good money that the way you're using them is unnecessary and your code could be cleaned up significantly by just using standard function calls.
Would you mind sharing your code? We could help you by pointing out things you could change.
I used gotos once.
[h2]Goto. Not even once[/h2]
Had never worked with images before apart from as sprites etc.
So I did this, it was easier than I expected.
[IMG]http://i.imgur.com/CkVZp.gif[/IMG]
GIF messed with the colours but you get the idea.
[QUOTE=swift and shift;33945451][img]http://i.imgur.com/1M4DX.png[/img][/QUOTE]
Can't wait for the final version. Mainly because I still can't get over this:
[IMG]http://dl.dropbox.com/u/27714141/cars.png[/IMG]
[editline]29th December 2011[/editline]
[QUOTE=swift and shift;33945575]Because instead of having a nice tree to reason about, your code jumps all over the fucking place.
This is your code:
[img]http://i.imgur.com/6gD1x.png[/img]
This is your code on goto:
[img]http://i.imgur.com/yW0er.png[/img][/QUOTE]
I think gotos are frowned upon because of situations like this:
[cpp]
#include <iostream>
class MyClass
{
public:
bool myValue;
MyClass() : myValue(false)
{
std::cout << "MyClass::MyClass()" << std::endl;
}
~MyClass()
{
std::cout << "MyClass::~MyClass()" << std::endl;
}
int getSomeValue() { return (myValue = !myValue); }
};
int main()
{
SomeLabel:
MyClass instance;
if (instance.getSomeValue())
goto SomeLabel;
return 0;
}
[/cpp]
This program will never return.
I have never seen the need for a goto ever, in fact this is probably the first time I have ever typed it without a space in the middle.
Well, the statement is there for a reason. In some very specific scenarios it's unavoidable. When you have to implement a recursive algorithm but must avoid recursion (for stack-related reasons) on an embedded system for example.
It shouldn't be abused as a common practice though.
[QUOTE=voodooattack;33946047]Well, the statement is there for a reason. In some very specific scenarios it's unavoidable. When you have to implement a recursive algorithm but must avoid recursion (for stack-related reasons) on an embedded system for example.
It shouldn't be abused as a common practice though.[/QUOTE]
I was working on a particular DOM parser library way back before I even needed a solution for parsing Facepunch with the fpapi. Considering I was binding this library to Lua for a C module, it was directly stack related, but perhaps not in the same literal manner you're speaking of.
It was a module with literally one function, asmxml.totable(), and I couldn't use typical recursion loops due to the way I was pushing data back to Lua's stack.
I knew there had to be a proper way of addressing my problem, but considering I never even think about using gotos, at the time it wasn't even in mind. Now that I recall the structure of the module's parsing function, it's a perfect example of when a goto is unavoidable.
[QUOTE=amcfaggot;33946139]I was working on a particular DOM parser library way back before I even needed a solution for parsing Facepunch with the fpapi. Considering I was binding this library to Lua for a C module, it was directly stack related, but perhaps not in the same literal manner you're speaking of.
It was a module with literally one function, asmxml.totable(), and I couldn't use typical recursion loops due to the way I was pushing data back to Lua's stack.
I knew there had to be a proper way of addressing my problem, but considering I never even think about using gotos, at the time it wasn't even in mind. Now that I recall the structure of the module's parsing function, it's a perfect example of when a goto is unavoidable.[/QUOTE]
Sounds like you could've used a stack or a queue with a loop.
Non-recursive implementations of DFS and BFS: [url]http://codepad.org/lObKKULh[/url]
[editline]![/editline]
Sorry, those are wrong. Here's a correct, more generic version:
[lua]
do
local type, unpack = type, unpack
local iterator_default = function(s, v)
if type(s) == "table" then
return pairs(s)
end
return nil
end
function table.bfs(t, iterator, func, ...)
iterator = iterator or iterator_default
local queue, queue_in, queue_out = {t}, 2, 2
local curr = t
while curr do
local iterator_func, iterator_s, iterator_var = iterator(curr)
if iterator_func then
for child_i, child in iterator_func, iterator_s, iterator_var do
queue_in = queue_in+1
queue[queue_in] = child
end
end
local res = {func(curr, ...)}
if res[1] ~= nil then
return unpack(res)
end
queue_out = queue_out+1
curr = queue[queue_out]
end
end
function table.dfs(t, iterator, func, ...)
iterator = iterator or iterator_default
local stack, stack_inout = {t}, 1
local visited = {}
local curr = t
while curr do
if visited[curr] then
local res = {func(curr, ...)}
if res[1] ~= nil then
return unpack(res)
end
else
local iterator_func, iterator_s, iterator_var = iterator(curr)
if iterator_func then
stack[stack_inout] = curr
stack_inout = stack_inout+1
for child_i, child in iterator_func, iterator_s, iterator_var do
stack[stack_inout] = child
stack_inout = stack_inout+1
end
visited[curr] = true
else
local res = {func(curr, ...)}
if res[1] ~= nil then
return unpack(res)
end
end
end
stack_inout = stack_inout-1 curr = stack[stack_inout]
end
end
end
[/lua]
Example usage:
[lua]
table.dfs({1, 2, {5, {6, 22}, 7}, 4}, nil, print)
[/lua]
[QUOTE=supersnail11;33945707]I used gotos once.
[h2]Goto. Not even once[/h2][/QUOTE]
They're the nicest way to break out of nested loops. <3
[QUOTE=Shrapnel :3;33946784]They're the nicest way to break out of nested loops. <3[/QUOTE]
Pssh, don't be so lazy.
[code]
while(something)
{
bool breakOut = false;
while(somethingelse)
{
if(somethingHappened)
{
breakOut = true;
break;
}
}
if(breakOut) break;
}
[/code]
I wish C++ had a [I]break 2;[/I] or [I]break(2);[/I] thing to break out of nested loops :v:
A few ways of avoiding goto in nested loops:
Make the nested loop a function, when you want to break, just return;
Have a bool that you check in the outer loop iteration, set it to true when you want to break.
I know that at least Java has named blocks, and you can wrap the nested loop in one and then "break nameOfBlock;"
[editline]29th December 2011[/editline]
If it's a regular for loop you can just set the iteration variables to a number that will make the for condition false (eg INT_MAX - 1)
[QUOTE=robmaister12;33947125]A few ways of avoiding goto in nested loops:
Make the nested loop a function, when you want to break, just return;
Have a bool that you check in the outer loop iteration, set it to true when you want to break.
I know that at least Java has named blocks, and you can wrap the nested loop in one and then "break nameOfBlock;"
[editline]29th December 2011[/editline]
If it's a regular for loop you can just set the iteration variables to a number that will make the for condition false (eg INT_MAX - 1)[/QUOTE]
Both do the exact same as a goto, but less efficiently.
I consider readability and maintainability more important than speed when that extra speed is only a few nanoseconds.
Also I'd rather not get attacked by raptors for using goto.
[img]http://imgs.xkcd.com/comics/goto.png[/img]
On the subject of goto, it's not terrible when you realize it exists in C++ because it exists in C, and it exists in C because C started out as a macro assembly language (and also the 'while loop' construct wasn't really a "thing" back in the 60's and 70's). I'd rather use a `goto some_clean_up;` in a C function than have to write if (pointer) { free(pointer); } each time I handle an if statement that might return an error (which is quite often if you're using posix!)
C++ has very nearly gotten rid of the need for a goto statement because of RAII, but it sticks around because it's fun to make people mad, I think.
Here's an example of decent use of a goto [url]http://www.daemonology.net/blog/2008-06-05-faster-utf8-strlen.html[/url]
I'd also stray from quoting Dijkstra on the goto statement because it's from the 1960's (and the goto statement then worked a lot differently in the languages of its time compared to today. Especially considering we can't goto a label that exists outside of a function). If we took everything that was said then at face value, then by gosh darn golly, you're letting the communists win. It's also kind of like that horrible misquote of Knuth that everyone and their brother likes to throw around "Avoid Premature Optimization", or something to that effect, when he really said Premature [i]micro[/i]optimization. (The difference being that you should optimize your algorithms (like say, taking advantage of short-circuit boolean logic in C or C++ rather than using a large series of if-elseif branches. Sure it _might_ result in the same code, but it might not because the semantics of a boolean logic differ from a branched if-else), but not start out by writing said algorithms in assembly)
Anyhow, the real reason for my post: I started writing up an explanation of how my SFINAE routing of the C preprocessor with templates was done, when I figured some poor soul out there might see it, but not comprehend the actual reasoning behind why it actually works, so I'm turning it into a series of posts. Here's the first one titled: [url=tmblr.co/ZGnAtwDy5lQv]Substitution Failure Is Not An Error (It is also not a Waffle House) Part 1[/url]
Let me know if there are things within that you don't understand so I can tweak it and keep them easy to understand for everyone.
[QUOTE=supersnail11;33945707]I used gotos once.
[h2]Goto. Not even once[/h2][/QUOTE]
[IMG]http://i.imgur.com/lm3L2.png[/IMG]
[QUOTE=foszor;33947476][IMG]http://i.imgur.com/lm3L2.png[/IMG][/QUOTE] Our computer classwhatever teacher actually forces us to use gotos. And we use FBide.
PS: Once he even told us to google devc++ and look at the amazing things it can do.
[editline]hahalol[/editline]
He even said that gotos are an useful way to manage your code. They keep the code nice and clean.
[editline]hahaloltwice[/editline]
Some content since you love it so much:
[IMG]http://i.imgur.com/Ae2eY.png[/IMG]
Kind of big image, but that's how the game looks normally.
[QUOTE=Funley;33947766]Our computer classwhatever teacher actually forces us to use gotos. And we use FBide.
PS: Once he even told us to google devc++ and look at the amazing things it can do.
[editline]hahalol[/editline]
He even said that gotos are an useful way to manage your code. They keep the code nice and clean.[/QUOTE]
I just looked up FBide... [url]http://fbide.freebasic.net/[/url]
[quote]This website has gotten a new fresh look tnx to Voodo![/quote]
[quote]a new fresh look tnx to Voodo![/quote]
[quote]tnx to Voodo![/quote]
[quote]tnx[/quote]
[QUOTE=robmaister12;33947875]I just looked up FBide... [url]http://fbide.freebasic.net/[/url][/QUOTE]
[quote]I'm happy to announce the availability of new FBIde relase.[/quote]
[quote]of new FBIde relase.[/quote]
[quote]relase.[/quote]
People treat goto in a really retarded way, in my opinion. It's just another keyword, albeit one that isn't used as often as others (do - while, anyone?)
It isn't inherently [I]bad[/I] to use it, it's just in a lot of cases it's used to make up for a bad code structure. Breaking out of deeply nested loops is a perfectly acceptable use of goto, and it's a hell of a lot cleaner and easier to read than a lot of other solutions to that. I do admit that a break(x) would be a nice thing to have, but since we can't then goto works too.
Sorry, you need to Log In to post a reply to this thread.
