[quote]Email me var emailAddress = new StringBuilder("john.sonmez"); emailAddress.Append("@gmail.com"); emailAddress.ToString();[/quote]
Stopped reading right there.
>>15
That doesn't make any sense since c++ is a super set of c, and every feature provided in c++ can be expressed in c, in a variety of ways. c++ can only implement its features in only so many ways, and it must do it in a way that can also be done in c.
>>18
That doesn't make any sense since both c++ and c have barely changed at all since the 90s. You see, programming languages are not like hardware, where people invent new methods to get better performing equipement subject to the restrictions of physics. Programming languages are subject to the restriction of human thought. This is why they cannot progress. It's because of people like you. I hope you are happy.
The big objections to C++ are poor tools, the runtime requirements, and too complex language features. The first (and partly the second) stem from the mid-90s and have been largely solved by now. The second and third are usually handled by allowing only a subset of the language, but especially with the third you always get some self-titled expert timewaster who insist on using every feature even though they don't understand it themselves.
Name:
Anonymous2012-12-03 8:14
>>22
And all this nonsense is solved by simply not using C++!
Name:
Anonymous2012-12-03 8:16
>>22
Also, the Windows NT kernel is written in a shitty MICROSOFT QUALITY dialect of C, not C++.
>>22 (poor tools, partly the runtime requirements) have been largely solved by now using only a subset of the language RUBY AS FUCK tools, imprecise analyzers, undefined ABI
lel
Name:
Anonymous2012-12-03 22:44
C++ is definitely the best language for large, important software. Chances are you'll run into performance or ``scalability'' problems with shitlanguages like ``.NET Enterprise Beans''. 90% of programming, however, is not large and not important, so go ahead and use whatever you want.
>>30
My browser is written in C, my OS is written in C, and the games I have installed are written in C, Java, Python, Scheme, assembly, and Inform.
Where is your Sepples now?
>>34
the nt kernel is written in c++ and assembly dipshit. all of windows is written in c++.
Name:
Anonymous2012-12-04 2:41
kernel may be written in c but most part of every os is written in c++ anyway
Name:
Anonymous2012-12-04 2:43
w3m is cute but it doesn't support javascript -_-
Name:
Anonymous2012-12-04 2:53
>LE EJPIN JPRO
>LE KAWAI LE DESU
>MY TOUHOU FACE
Name:
Anonymous2012-12-04 4:13
>>37
Win32 is a C API, and the vast majority of the NT kernel is written in C [1]. You can indeed write kernel mode drivers for NT in C++ [2], but this is of limited usefulness because one must dispense with many of the defining features of the language (templates, exceptions, RTTI) in order to get things done. Even RAII is of limited application because kernel destructors can often fail in myriad ways.
I'm not at all convinced that it's worth it to switch from C to C++ for kernel code. For a green-field project, a C++ subset might be a smidge nicer to use, but real world codebases like the Linux kernel have already implemented so many of the niceties in plain C that there's no clear benefit to switching.
>>41
The API is C for MAXIMUM compatibility, it doesn't say anything about the implementation language. Templates, exception, RTTI either didn't exist yet or had only bad/expensive implementations (remember that this is late 80s/early 90s language and compilers).
Most kernels reinvent object orientation anyway (Linux VFS layer just to give a lel randum example), so why not save some work and use a language that supports the features from the start?
Name:
Anonymous2012-12-04 5:56
>>14
The Symbian kernel, written completely in C++, is pretty popular. Ot at least it used to be. That amounts to hundreds of millions C++ kernels shipped. That's 8 orders of magnituds more than GNU/Hurd or whatever you neckbeards endorse here.
Name:
Anonymous2012-12-04 5:56
>>41
I agree that there is not much point in rewriting current kernels in from C to C++.
However, I think that if starting to create new kernel from scratch, it would be very useful to use C++ instead of C. And I also think Linux should make it easier to develop drivers in C++, or maybe allow the use of C++ in certain parts of the kernel itself.
>>43
The Lisp machine kernel, written completely in lisp, is pretty popular. Ot at least it used to be. That amounts to hundreds of millions of lisp kernels shipped. That's 8 orders of magnitude more than Linux/Windows NT or whatever you neckbeards endorse here.
>>46
The Losethos kernel, written completely in AutismC, is pretty popular. Or at least it used to be. That amounts to hundrends of billions of AutismC kernels shipped. That's 8 orders of magnitude more than Linux/Windows NT/Symbian OS/Lisp OS or whatever you enterprise programmers endorse here.
Name:
Anonymous2012-12-04 7:27
>>45
Just not having to rely on macro garbage to make your fake objects palatable is an improvement.
Name:
Anonymous2012-12-04 7:55
The next version of C++ should remove 100% of the language.
And no, C is not an option. Lack of RAII and other "advanced" functionalities will result in terrible bugs.
Only if you're careless.
Name:
Anonymous2012-12-04 8:41
>>51
Yeah, only if I'm careless, or any of the developers that touch the code after me. Basically only if there is any careless developer in the company, or will be. So I can just use C, because every developer touching the code is perfect.
>>51
lel 99.9999% of the bugs in C applications are forgetting to free le resource after usage. and releasing resources in C can only work well if you have only 1 return clause per function.
C++ with OOP, what could go wrong? handicapped polymorphism
undefined as shit C
implicit needles
trashing cache
hit a wall? rewrite in data-oriented C subset
RUBY AS FUCK
Name:
Anonymous2012-12-04 13:15
>>61
A thought-terminating cliché from you, but it's not related to me and my question. Infact it did not even imply your silly rebuttal. To me that was unexpected. There are problems where OOP is a suitable method and if you would have mentioned at least one of them I would be prepared to give alternative methods that are at least to me better since they do not imply the need of an entire programming language, an imperative language would do just fine. But I'm talking with my self since you have nothing else to add, so I'll stop because it is boring me or at least saddening me.
The problem with saying deliberately stupid shit for attention is that eventually it becomes impossible to tell /prog/ apart from people who believe stupid shit.
>>68 what else would you expect from /g/ >>69 maybe /prog/ isn't that bad after all. We are just pretending to be terrible to constantly troll ourselves.
>>54
Good policy, made incredibly annoying by the prescriptions against goto that frequently accompany it. Sanity demands one or the other, but not both. It does not help readability at all to use extra flag variables to direct transfers of control.
There is nothing wrong with this:
int func1(int *f, int x)
{
char *buf;
int err;
int ret;
ret = 0;
buf = malloc(4096);
if (!buf) {
ret = -1;
goto out1;
}
err = func2(buf, x);
if (err) {
ret = -1;
goto out2;
}
The alternative requires creating a new function or nested control structure every time an error code is checked. You can't do this more than 2-3 times without wrapping code off the screen, which leads to creating lots of pointless little functions. The result is much harder to read than just using goto to break out when an error is encountered.
It seems like most of our names for colors come from our German roots (blue/blau, green/grün, red/rot, etc.). But yellow is gelb in German, amarillo in Spanish, jaune in French, and giallo in Italian. I suppose the Italian seems closest, but perhaps they all have something in common?