[IMG]http://i.imgur.com/TNMKfni.gif[/IMG]
I added bombs and destruction to my game
but std::getchar/getc?
oh god missed a whole page. the c functions aren't deprecated and there's nothing wrong with using C functions in C++ unless it's some taboo I haven't been told about
[QUOTE=Map in a box;45775505]but std::getchar/getc?
oh god missed a whole page. the c functions aren't deprecated and there's nothing wrong with using C functions in C++ unless it's some taboo I haven't been told about[/QUOTE]
Design. The standard has its own things for C things now, like std::array for C-style arrays.
The STD lib is so ugly. Operator overload bonanza party
[QUOTE=Map in a box;45775524]The STD lib is so ugly. Operator overload bonanza party[/QUOTE]
Nothing is stopping you from using C in C++, that is what it was designed for after all.
[editline]23rd August 2014[/editline]
[QUOTE=ECrownofFire;45775313]Nothing from C is deprecated. Except gets(), but that's also deprecated in C.[/QUOTE]
That doesnt make sense.
C printf sucks. Since C++11 you can write your own typesafe version of it.
[url]http://en.wikipedia.org/wiki/Variadic_template[/url]
Content time
Playing with mandelbrots
[img]http://i.imgur.com/OrZ8t38.png[/img]
[QUOTE=WeltEnSTurm;45775633]C printf sucks. Since C++11 you can write your own typesafe version of it.
[url]http://en.wikipedia.org/wiki/Variadic_template[/url][/QUOTE]
Not exactly. You can make a type-safe wrapper that uses std::cout or printf.
[vid]https://zippy.gfycat.com/WanJoyfulKoi.webm[/vid]
[editline]23rd August 2014[/editline]
sharex is terrible
[QUOTE=WTF Nuke;45774574]Correct me if I'm wrong, but I thought getchar is deprecated and a carryover from C much the same as Printf (the C part).[/QUOTE]
The thing is, even though gets is deprecated in C11, it doesn't mean "remove support in newer releases", it simply means "if standard used is <C11 then define gets".
Which to be honest is a bit strange way of doing things, because it means than you can, and will always be able to, write ANSI C with full support from compilers, or you can chose to use a newer standard for your code.
Not to forget that it only really matters to YOUR code, as far as I know. Linking with a C11 library may not have any issues, just as well as linking a C11 application with ANSI C libraries should work just fine too.
Compilers and standards, man.
[editline]23rd August 2014[/editline]
[QUOTE=WeltEnSTurm;45775633]C printf sucks. Since C++11 you can write your own typesafe version of it.
[url]http://en.wikipedia.org/wiki/Variadic_template[/url][/QUOTE]
But what is "type safe" though? Does it mean "support every type ever", or does it mean "guarantee that the type required is also the type passed"? This isn't a one to one thing, and people use this term in many ways.
And with good reason, because the term itself is quite ambiguous, not to mention that it could (potentially) mean different things in different languages.
And even in C++ it could mean a lot of things.
So why are we using these terms to define solutions to problems with such ambiguity, instead of simply stating the facts and our final conclusions?
It should be easy to see, but even with the second definition I wrote, C and C++ are already type safe. With the former definition, C++ can, to some degree I suppose, be type safe too.
But does it really matter?
Is it not more important to write clean and performant code that works as many places as possible, and is a pleasure to work with? Is that not the most important part? To be expressive of ideas, and to write those ideas down and see them come to life?
Hell I'm not even sure myself anymore, but I fucking love programming.
[QUOTE=mastersrp;45775935]The thing is, even though gets is deprecated in C11, it doesn't mean "remove support in newer releases", it simply means "if standard used is <C11 then define gets".
Which to be honest is a bit strange way of doing things, because it means than you can, and will always be able to, write ANSI C with full support from compilers, or you can chose to use a newer standard for your code.
Not to forget that it only really matters to YOUR code, as far as I know. Linking with a C11 library may not have any issues, just as well as linking a C11 application with ANSI C libraries should work just fine too.
Compilers and standards, man.
[editline]23rd August 2014[/editline]
But what is "type safe" though? Does it mean "support every type ever", or does it mean "guarantee that the type required is also the type passed"? This isn't a one to one thing, and people use this term in many ways.
And with good reason, because the term itself is quite ambiguous, not to mention that it could (potentially) mean different things in different languages.
And even in C++ it could mean a lot of things.
So why are we using these terms to define solutions to problems with such ambiguity, instead of simply stating the facts and our final conclusions?
It should be easy to see, but even with the second definition I wrote, C and C++ are already type safe. With the former definition, C++ can, to some degree I suppose, be type safe too.
But does it really matter?
Is it not more important to write clean and performant code that works as many places as possible, and is a pleasure to work with? Is that not the most important part? To be expressive of ideas, and to write those ideas down and see them come to life?
Hell I'm not even sure myself anymore, but I fucking love programming.[/QUOTE]
Type safety in the context of a (variadic) template-based printf equivalent, means that the program will attempt to behave in a manner which prevents undefined behaviour, catches type errors as early as possible, and executes in a manner that makes sense from the programmers perspective, [I]in that order[/I].
[CPP]
#include <iostream>
template<typename T>
void print_as_str(T t)
{
std::cout << t << std::endl;
}
int main()
{
print_as_str("Hello");
print_as_str(1234);
printf("%s\n", "Hello");
printf("%s\n", 1234); // HCF
return 0;
}
[/CPP]
It's not at all ambigious, it makes sense. And it's extensible on top of that. Try implementing print_as_str using printf, and watch your codebase crash and burn once a new class somehow finds its way to your debug/logging code path.
[QUOTE=Map in a box;45775811]
sharex is terrible[/QUOTE]
"its terrible because i cant figure out how to work it properly"
[QUOTE=Dr Magnusson;45776038]Type safety in the context of a (variadic) template-based printf equivalent, means that the program will attempt to behave in a manner which prevents undefined behaviour, catches type errors as early as possible, and executes in a manner that makes sense from the programmers perspective, [I]in that order[/I].
[CPP]
#include <iostream>
template<typename T>
void print_as_str(T t)
{
std::cout << t << std::endl;
}
int main()
{
print_as_str("Hello");
print_as_str(1234);
printf("%s\n", "Hello");
printf("%s\n", 1234); // HCF
return 0;
}
[/CPP]
It's not at all ambigious, it makes sense. And it's extensible on top of that. Try implementing print_as_str using printf, and watch your codebase crash and burn once a new class somehow finds its way to your debug/logging code path.[/QUOTE]
My point was that type safety only makes sense to talk about in very specific cases, and a lot of people tend to use it out of context which makes no sense.
For instance, if I write a library containing a function that takes a a path as const char*, then it makes no sense to me, as the library developer, to handle any case where that path is not a const char*, because anyone passing values to it in the form of anything else is just being a moron and can go fuck themselves or read the documentation.
A lot of people seem to think that functions should handle all edge cases, and if the value passed to a const char* is casted from an int, then it should return some sort of error.
I disagree on that front, and disregard any talk of "type safety" in [b]that[/b] context, because that's just being retarded and trying to do things that are essentially undefined behavior.
In that case, it is totally alright for the user of said library to have their application crash and burn and segfault to hell, because [b]they[/b] did their shit wrong.
However, in the cases where it makes sense to talk about type safety, such as the example with templates that you mentioned, it's a whole other story.
Both printf and iostream formatting are unsuitable for i18n and l10n so really they both lose.
[QUOTE=Map in a box;45775638]Content time
Playing with mandelbrots
[img]http://i.imgur.com/OrZ8t38.png[/img][/QUOTE]
More please..
Also it kind reminds me of an asshole
Funny you should say that, the cardioid-like part(the bit on the right) of the mandelbrot set also looks like an arse.
[t]http://upload.wikimedia.org/wikipedia/commons/thumb/2/21/Mandel_zoom_00_mandelbrot_set.jpg/800px-Mandel_zoom_00_mandelbrot_set.jpg[/t]
[QUOTE=Map in a box;45775524]The STD lib is so ugly. Operator overload bonanza party[/QUOTE]
I hate working with it honestly
I'm doing a uni course on it atm and we're told to use STL as much as possible and part of me just wants throw my laptop off the balcony because of a billion specific little idiosyncrasies with each container that could easily be generalised and has not been for whatever reason
at least its pretty quick
[QUOTE=killerteacup;45777391]I hate working with it honestly
I'm doing a uni course on it atm and we're told to use STL as much as possible and part of me just wants throw my laptop off the balcony because of a billion specific little idiosyncrasies with each container that could easily be generalised and has not been for whatever reason
at least its pretty quick[/QUOTE]
Try making a const function that does [] on a map.
[QUOTE=Map in a box;45775524]The STD lib is so ugly. Operator overload bonanza party[/QUOTE]
Sometimes the STL feels like it's just supposed to showcase obscure C++ functionality
MS-DOS SSH server (or infact, anything that operates on 16bit real mode ssh server)
[vid]https://daringssl.benjojo.co.uk/DataStore/tmp/msdos_ssh.webm[/vid]
This uses hacks that are so bad [del]that it may not see the light of day[/del] That you can find here: [url]https://github.com/benjojo/dos_ssh[/url] .
[QUOTE=2sp00ky;45775441]I added bombs and destruction to my game[/QUOTE]
Don't just violently rotate the screen when shaking, move it around too.
In the last few years C++ has made more progress then it did since release.
Doesn't matter too much tho since even now 90% of the "C++" projects still remain C with C++ for Classes and Templates and an occasional std::vector when nobody is looking.
Hey guys, i'm really shy to post here, but i was lurking here for a bit. And i want you to help me choose: C# or C++? I have programmed in C#, JavaScript(Unity), CSS, HTML, and batch :v:
[QUOTE=EmilioGB;45777773]Hey guys, i'm really shy to post here, but i was lurking here for a bit. And i want you to help me choose: C# or C++? I have programmed in C#, JavaScript(Unity), CSS, HTML, and batch :v:[/QUOTE]
It's best to ask these things in [url]http://facepunch.com/showthread.php?t=1250528&page=150[/url]
Since otherwise this thread explodes with opinions/arguments and what people think are the best, not what they are working on
If its for learning i'd say C#.
If you're making something and you're choosing between C# and C++, then it pretty much depends on what you want to make.
Vote:
C# [img]http://www.facepunch.com/fp/ratings/tick.png[/img]
C++ [img]http://www.facepunch.com/fp/ratings/cross.png[/img]
[QUOTE=EmilioGB;45777773]Hey guys, i'm really shy to post here, but i was lurking here for a bit. And i want you to help me choose: C# or C++? I have programmed in C#, JavaScript(Unity), CSS, HTML, and batch :v:[/QUOTE]
If you already know some C# then go with C#. Assuming you're doing this as a hobby it all comes down to personal preference anyway, but I would suggest using whatever you're already familiar with since it's likely you're comfortable with it. If it turns out you don't like C# after all, then start looking for alternatives that are more like what you want.
[IMG]http://kirk.by/s/raw/1480432fb05.png[/IMG]
I'm the reason we can't have nice things.
I realize that's not the most efficient solution, but the fact that I can generate a solution at all still pleases me.
And yes, I am essentially bruteforcing the move tree with some minor optimizations.
[QUOTE=killerteacup;45777391]I hate working with it honestly
I'm doing a uni course on it atm and we're told to use STL as much as possible and part of me just wants throw my laptop off the balcony because of a billion specific little idiosyncrasies with each container that could easily be generalised and has not been for whatever reason
at least its pretty quick[/QUOTE]
What specifically annoys you in the standard library?
[QUOTE=RusselG;45776107]"its terrible because i cant figure out how to work it properly"[/QUOTE]
It is legitimately terrible. The codebase is horrible, too :v: The reason I said it was terrible though is because I used it to record 15 seconds and it cut it off 5 seconds while uploading twice and giving me the short end of the stick. All three times I used it
[QUOTE=Map in a box;45779078]It is legitimately terrible. The codebase is horrible, too :v: The reason I said it was terrible though is because I used it to record 15 seconds and it cut it off 5 seconds while uploading twice and giving me the short end of the stick. All three times I used it[/QUOTE]
Then you did something wrong.
Sorry, you need to Log In to post a reply to this thread.
