This kind of trolling might get you a lot of responses on /g/, but seriously, /backplate getgoes/.
It's too obvious.
Name:
Anonymous2011-01-10 19:19
have fun with that, D sucks... c++ is were its at
Name:
Anonymous2011-01-10 19:20
and im not trolling, i love c++, i love pointers and being able to do low level stuff..... just seeing other peoples oppinions, never knew about /prog/
Name:
Darkr2011-01-10 19:26
I like the concept of C++, just not the implementation. D is essentially C++ done right and I absolutely love it. The problems of C++ stem from a lack of foresight into some of the features that evolved and from design by committee. Things like templates which are difficult to parse due to the poor choice of <> as the operator, the long compile times, header files instead of proper modules, having 'delete' and 'delete[]', etc.
Most people seem to bash C++ because everyone else is doing it. Few people actually understand why C++ sucks. They just repeat the line like a parrot.
>>5 The D Programming Language has pointers, classes, all your sepples shit done better and has a standard way to inline assembly code.
Back to /g/, now.
>>1
Personally, I think C++ is a wonderful tool, once you managed to understand it. I doo agree with >>6-san that D has an interesting concept, HOWEVER I really dislike two things about D:
1. The builtin Garbage Collector
2. There are practically only two usable compilers (dmd and dmd2) Althoough there is also ldc (D compiler using the LLVM backend), and gdc (D compiler using the GCC backend)
Beside that, you really should ask yourself: What does D do, that C++ can't do? It's obvious that everything you can do in C++, you can do in D, and vice versa. The main difference being, that C++ is an ISO standardized language, is well tested, has a far bigger community, and a far broader choice of implementations (that includes compilers and interpreters).
D still has a loooooooooooooong way to go. A very long way.
Name:
Anonymous2011-01-10 20:14
I am fond of programming in C++. Despite it's imperfections and learning curve, the years I have spent mastering it have not gone to waste. C++ has helped keep me employed during these trying times.
I'm quite looking forward to working with more of C++0x as more compilers implement the new features.
I think the people that are quick to attack the language are nothing more novice programmers who have been drinking the koolaid served by their dark masters from the Ivory Towers of Academia.
Are there any C++ compilers that can trace use of objects so that objects that are not used after the function where they were new'd returns are allocated on stack instead of hogging up heap space and causing memory leaks if the programmer is sclerotic/careless/stoned? (I am aware that one can use a portable alloca-based hack; I want a REAL-WORLD ENTERPRISE SOLUTION.)
>>19
As a matter of fact, this is a theoretical feature being considered for C++4X. Google "automatic storage duration".
Name:
Anonymous2011-01-11 1:25
It's a horrible language. I've used it and read Bjarne's entire book, so I am officially the most qualified person on /prog/ to evaluate Sepples. It's holding the whole field of computing back by:
1. Wasting programmer brainpower coping with its pointless complications.
2. In cooperation with C, obscuring the need for kernels that give garbage collectors and databases the tools they need to be efficiently implemented.
3. Being solely responsible for the bastardized version of OOP that most of you morons probably believe correct.
>>10 1. The builtin Garbage Collector
You can disable it and manage your memory by hand, unlike Go 2. There are practically only two usable compilers (dmd and dmd2)
I have to agree, but the dmd2 is good enough for now.
What does D do, that C++ can't do? It's obvious that everything you can do in C++, you can do in D, and vice versa.
Well, you know, they are both Turing-complete. But D has much nicer metaprogramming facilities, doesn't inherit nothing of the bad things of C and has pointers. It has built-in dynamic arrays instead of buggy vectors in the standard library, therefore it also has safe strings. You can still have 0-termined strings with char* and '0', IIRC.
Smalltalk was created by the man who invented OOP and was the first language to use the term.
Name:
Anonymous2011-01-11 4:34
>>24 But D has much nicer metaprogramming facilities
You mean, nicer syntax for metaprogramming facilities. D doesn't do metaprogramming better, it just uses a different syntax.
It has built-in dynamic arrays
C++ as std::vector.
instead of buggy vectors in the standard library
Buggy in what way? At this point i start to get the feeling you never really wrote anything in C++, and you just dump raw hearsay.
therefore it also has safe strings
C++ has std::string. Thing is, D attempts to fix "problems", even though these aren't problems at all; as you correctly pointed out, C++ started out as an extension to C, to allow OOP facilities, such as RAII and thereof. Today, C++ is no longer an extension to C, but a standalone language, but the concept of primitive type arrays didn't change in this time.
>>30
Being massraped by illiterate nigger immigrants while denying actual dissidents of white color political asylum is a Norwegian invention first implemented in Norway.
Just like how software transactional (STM) memory will be for morons once the average desktop computer gets around 16 cores.
Real programmers manage their own memory and are aware of the memory footprints of their data structures as well as hardware cache coherency and memory hazards. The build their own memory allocators to suite different requirements.
Just like how real programmers today use fine-grained lock-free and wait-free synchronization primitives such as multi-producer/single-consumer bounded queues and RCU (read-copy-update) and build their work/task schedulers to be NUMA aware. You loose all of that fine grained control with one-size fits all STM.
This is why C/C++ will continue to be the language of choice for high-performance computing even in the age of massively parallel computation. C1x/C++0x have well defined memory models around which atomic operations can be implemented.
Enjoy your garbage collected and sequentially consistent programming environments, morons.
>>29 You mean, nicer syntax for metaprogramming facilities. D doesn't do metaprogramming better, it just uses a different syntax. >>33 No, it's not different syntax, it's different semantics.
What a surprise, both are Turing-complete!
Name:
Anonymous2011-01-11 11:12
My biggest complaint is the performance of your average C++ Standard Library implementation. Most implementations are fucking garbage, where it seems like the main goal of the implementer is obfuscation rather than performance.
I've been writing my own containers. Here's some micro benchmarks against the MSVC++ 2010 Standard Library. Not currently on a Linux machine, but I've benchmarked it there and the GCC libstdc++ containers are even worse in performance than the MSVC++ ones. My containers are in the prog namespace and have the EXACT same interfaces--they're drop in replacements.
You'll notice up to factors of 10 and beyond in performance improvements with my containers (lower times are better). I've tried submitting patches to the GCC maintainers, but they won't accept them because it's too much code to look at and they don't want to risk breaking ABIs.
So instead, I've been submitting patches to Clang/LLVM's libc++ implementation and they're getting accepted. Fuck GCC.
>>37
That's why you end up with using the C-like subset of C++.
Use D and extern (C) when needed.
Name:
Anonymous2011-01-11 11:22
>>38
Well, my point is that the standard library doesn't have to have shit performance. The performance isn't handicapped because of the design of the library facilities, but rather due to the skill of the implementor.
My containers, if used correctly, will at least meet the performance of equivalent hand-written C code, and will also often beet out naive hand-written variants that don't take advantage of hardware-specific instructions.