>>7
Q: So, what are the errors in the FQA?
A: FQA is clueless nonsense written by clueless nitwit, blah blah, blah blah, can't point out a single factual error or even minor inaccuracy because I don't know C++ anywhere near as good as Yossi (he still is a clueless nitwit though), but it doesn't matter because hurr durr it's his subjective opinion and nobody can make their own opinion based on facts in his FQA.
Name:
Anonymous2012-06-14 6:00
if you have to link shit you read because you cant come up with a coherent argument on your own then you have no right to even join the discussion
>>9
look at me, linking shit all over your thread
u mad?
LOL!
>>13
C is a shitty language. C++'s backwards compatibility with C is a major flaw. However, without it, C++ would not be here today as a faster, more popular, better alternative.
There is a reason why you should not program in C++ as if it were C today, and that is because there are much safer alternatives.
C is unsafe crap.
Name:
Anonymous2012-06-14 16:48
>C is unsafe crap.
This is truly typical for a modern age developer: scared as shit.
Instead of behaving/developing like a man, they need Mom to hold their hand. Mom being a safe language. Just like what is happing around us, kids playgrounds are made safe, to such a degree that kids cannot get injured even how hard they try. Because they were never exposed to threatening situations, they will be incapable to sense it when they are grown-up and enter the real world. Always longing for a world with reduced opportunities because being safe has become the new holy grail.
Of course we need unsafe languages, because they give opportunity to explore and discover new opportunities. And yes, they can be hot to handle, that is why we have multi-year training. Computers with software have always been very complex machines. Only a fool would expect this otherwise. Only the ignorant feel comfortable in environments where mistakes have no consequence.
>>15
Stop! You hurt >>16,14s feelings.
You shouldnt be this mean, he is still a child.
Name:
Anonymous2012-06-14 17:10
>>15
this is really how C programmers think, they want to use C for everything just because they think it gives them more power and control. You can make compiled code in D that is just as fast and C, has safe pointers and garbage collection, but a C programmer wont use it because they think its a sissy language.
Name:
Anonymous2012-06-14 17:12
>>17
fuck off and die you in a fire you cock sucking piece of shit
>>18
If you want power and control, use assembly. C has plenty of instances of undefined behaviour which may translate into security bugs in your code.
Name:
Anonymous2012-06-14 17:50
>>19
If you are a shit programmer, you can use the best tools ever designed and still produce shit code. In contrast the best programmers really don't care which language they use because what they touch turns to gold. Fussing and bitching about languages is more a reflection of ones own abilities.
>>20 In contrast the best programmers really don't care which language they use because what they touch turns to gold.
Right, then go write golden code in PHP 4.
>>22
To be honest, compilers are so complex that all those layers of optimization might introduce security issues even if the initial code is perfectly standard-compliant. An assembler is far smaller and easier to check for errors.
Name:
Anonymous2012-06-14 18:28
>>23 To be honest, compilers are so complex that all those layers of optimization might introduce security issues even if the initial code is perfectly standard-compliant. An assembler is far smaller and easier to check for errors.
Yes but how do you know that what you assemble with your now safe assembler is safe? Besides optimization isn't exactly what Annex K is all about, you should check it out.
C: The language where you are rewarded with a segfault by reinventing the wheel.
Did I rustle your jimmies, Cfags? I'll be over here, enjoying my standard SEPPLES algorithm implementations and not having to manually manage my strings.
>>24 Yes but how do you know that what you assemble with your now safe assembler is safe?
I can cross-check it with another assembler, or disassemble the generated code manually if I'm really bored.
Name:
Anonymous2012-06-14 19:53
>>24
>Yes but how do you know that what you assemble with your now safe assembler is safe? Besides optimization isn't exactly what Annex K is all about, you should check it out.
that might be true in embedded software where code rarely goes past a few hundred lines. But in large scale code thousands of line long, there is no way you can organise code flow just by stepping through it in a debugger. All the speed gains of asm are lost because there is no way humanly possible that a programmer can optimise code at a high level like a compiler can.
>>28
Use asm for low-level, use Lisp for high-level. Problem solved.
Name:
Anonymous2012-06-14 20:43
It's a well known fact that people who love C and hate C++ are whiny neckbeards who never learned C++ because it was too hard. All of their complaints about C++ are either complaints about its implementation of OO (which is much saner than java's and isn't forced on the user), or all of the flaws that it inherited from C.
Name:
Anonymous2012-06-14 20:50
>>11
The funny thing is that C++ isn't even that powerful. I can do a lot more by mixing C with code generation than I can do with the built in features of C++. But C++ is just powerful enough to make you program implode.
>>19
The solution there is to avoid dependence on undefined behavior.
>>23
If an optimization performed by a compiler introduces a security issue, then that isn't an optimization, that's a delerberate action performed by the compiler to ruin your program. An optimized program and an unoptimized program should be equivalent to one another, outside of undefined behavior. Again, the solution here is to not depend on undefined behavior.
make a facility in seeples that automatically creates a pretty printing method for any class. This is similar to the implicit destructor method that calls the destructor on all of its members, except it is not a built in feature. Write one piece of code in C++ that will automatically create this method for every single class you define. You should not have to write any extra text in the class definition, and there should be no duplicate listings of the members of the class. Duplicate listings of members are error prone and can easily go out of date with respect to the class definition. You can only use features in standard C++. Good luck.
If you believe that this example has no point, and that debuggers are sufficient for getting such information, then change the context to streaming the class instance over an internet connection. Certain elements of the class, based upon their type, will have different sizes and different rules for endian conversion. Make a mechanism that automatically generates a serializer for your favorite protocol.
Name:
Anonymous2012-06-15 1:04
>>35 make a facility in seeples that automatically creates a pretty printing method for any class.
Clarify that... Are you talking about reflection? Or are you talking about a program that reads a .cpp file from disk and reformats it?
The former is very hard (in C++) and the latter is easy in pretty much any language.
Name:
Anonymous2012-06-15 1:12
>>36
Never mind -- I'm going to infer from the rest of your post that you're talking about reflection. I'm not the guy you were arguing with, and I agree that this would be a really nasty thing to do in C++.
However, the hard-core C++ faithfuls would argue that this is something no C++ programmer would ever want. The whole idea of C and C++ is to carry around as little baggage as possible, and what you're asking for is to essentially turn C++ into C#.
This is expressive power that has no run time cost. You may as well say that the automatic calling of destructors introduces needless bloat. This is also very useful in keeping routines that read and write data types to files, data bases, and sockets, consistent with the class representation. Basically any routine that needs to do a typed traversal over its members. This is trivial in lisp.
Automatically generating one subroutine for each data type that is defined is not very complex, and can be done very easily in a variety of ways, although I would not try to do it with standard C. I wasn't saying that C can do this better than seeples, but that C with code generation can do it much better than standard C++ alone could ever attempt to do it.
If you believe that this example has no point, and that debuggers are sufficient for getting such information, then change the context to streaming the class instance over an internet connection. Certain elements of the class, based upon their type, will have different sizes and different rules for endian conversion. Make a mechanism that automatically generates a serializer for your favorite protocol.
That's an even more pointless example. At least the first one helps you understand the code you generate.
>>41 This is expressive power that has no run time cost.
What? I thought you knew what you were talking about right up to this post. A compiled executable from C++ has absolutely no remnants of the original source -- no variable names, nothing. If you want reflection in C++, it's going to come at a huge run-time cost. That's why C++ doesn't have reflection. All the various compilers and IDEs out there come with their own (completely non-standardized) ways of embedding this information in the executable for debug reasons, but this has nothing to do with what you're talking about. You'd have to write your own compiler if this is what you want.
A compiled executable from C++ has absolutely no remnants of the original source -- no variable names, nothing
Is that something you just read about and are parroting now? Look at anything compiled with MSVC defaults for example and you'll see tons of encoded class and method names.
>>44
That's because they use Microsoft's awful macros like DECLARE_DYNAMIC() and IMPLEMENT_DYNAMIC(). Those macros just resolve to a bunch of strings that can be accessed at run-time, for a cost. There's at least the spatial cost of all those strings in the executable, plus the functions to access them.
>>48
It might depend on the version. I have at least these when using MSVC6:
.?AVexception@@
.?AVbad_cast@std@@
.?AVios_base@std@@
.?AV?$basic_ios@DU?$char_traits@D@std@@@std@@
.?AV?$basic_istream@DU?$char_traits@D@std@@@std@@
...
But more shockingly (or maybe not so if you're familiar with cout and friends, although I am (was) and it still surprises me today), the executable was 100KB. One hundred thousand bloody bytes. That's about the size of the earlier versions of uTorrent. All just to create a single object and print out one of its members. Compiling with /MD brought that down to a bit more reasonable 16KB, but that's still full of empty space (and has the names above). This is what I meant in >>11. The language gives you the power to generate immense amounts of code, but to use it responsibly is a different matter. Someone with a newer version can report their experiences with compiling the same code with default settings, I doubt it's any better.
(I consider that iostreamis part of "the original source" because of how the preprocessor works.)
In contrast,
#include <stdio.h>
struct my_class
{
int member_x;
float member_y;
};
int main(int argc, char **argv)
{
struct my_class instance;
construct_my_class(&instance);
printf("%d\n", instance.member_x);
return 0;
}
is 48KB with the default settings and there is no mention of printf.
Name:
Anonymous2012-06-15 4:11
>>42
It can get really messy. Imagine having N objects, M internet protocols, and D database formats. For each object, protocol, and data base format, and reading function and a writing function will need to be implemented. Now what if you have to add a field to an object? You have to update the reading and writing function for each serialization method for the object. Errors are inevitable, and inconsistencies will arise between the methods. And besides, it is perfectly easy to just automatically generate them all. This is a case where the computer can do a better job than a human. Just give one specification of an object, and have the computer echo the representation to everywhere it is needed. People aren't good at keeping duplicate records consistent. Computers are experts at it.
Not to mention, sometimes an object needs to be implemented and used between multiple languages. In this case, the only way to have a unique definition of the object is to use code generation.
>>47
I'd ask you to do it, but I don't think you would respond positively. And I'd provide a quick implementation using python, but I don't feel like it, and I'll instead let someone else provide an example.
This technique can be used with C++ you know. You shouldn't feel any reason to question or attack it in the name of C++. I was just saying that I could use it in combination with C to do anything and more, that can be done in C++ alone.
Writing out raw objects should be discouraged practice anyway, if you want to do anything like save state then either pick exactly what you need or dump the whole process's memory image. The majority of file formats are not like this for a reason.
Name:
Anonymous2012-06-15 8:37
>>52
portable serialization of objects for transmission across networks is a faily basic and universal need. It's good to have a library where you can just do connection.send(obj); on one end and connection.recieve(obj); on the other. This is just one method to obtain that, and it comes with the advantage of not having to do work to keep it up to date with changes made to the objects. But with any case in automation, there is potential for abuse, like storing fields you don't need, as you mentioned. But I think the solution to that is to carefully design the objects to only store what is needed in the file, or what is needed for transmission, etc. The object should be seen as a mandable container for the contents of the file, or transmission. This approach could be used to implement any file format that has a consistent structure. XML is fairly easy. And binary files that consist of several items, one after the other, can also be generated and read this way.
>>40
Your argument is that it would be complex and inefficient to reflect a class in C.
Anon is saying it is *impossible* as C has no classes.
Name:
Anonymous2012-06-15 10:04
>>55
why the fuck would you even use classes in c?
its really awkward and doesn't make sense
Name:
Anonymous2012-06-15 10:53
>>49
that's not a class. You're going to need to handle subclassing and inheritance.
What you have there is an age-old C trick for object-like behavior
Name:
Anonymous2012-06-15 11:42
The FQA is full of inconsistencies and butthurt. Hopefully novices don't actually believe the shit written there, because it would be very easy for them to.
Name:
Anonymous2012-06-15 12:07
>>49
>That's about the size of the earlier versions of uTorrent
... uTorrent being known for being particularly small (hence the "mu", which is the SI prefix for "micro").
Name:
Anonymous2012-06-15 13:03
>>49
C++ classes are more than just glorified syntactic sugar (like using the dot operator to access members that bind the this pointer). You get RAII, polymorphism, encapsulation, operator overloading, functors, and so much more. You're never going to do real OO with C structs and function pointers. Deal with it, it's why C++ was created.
Name:
Anonymous2012-06-15 13:50
>>60
>You're never going to do real OO with C structs and function pointers
Anyone who has done real OO knows that OO isn't about classes, methods, overloading and code re-usability. It is more about event/message/intention-driven and distributed computing. And yes, you can write OO in code with just C structs and function pointers, only it might be a pain. On the other hand you can also write OO code in C++ and NOT using about 75% of functionality C++ offers, like templating.
OO is a way of thinking. The language is a just tool.
Name:
Anonymous2012-06-15 14:15
>>61 OO is a way of thinking. The language is a just tool.
I agree completely.
And with regards to what we today see as OO, I believe that it is the worst way of thinking ever created. Most of the C++ criticism is due to problems in the OO mentality.
But I think the solution to that is to carefully design the objects to only store what is needed in the file
That's no different from making a structure containing the fields needed in the file, and writing that out with a single fwrite(). And do use the Google if you don't know what something is.
>>57,60
All the C++ features (with few exceptions like... exceptions) can be directly translated to C. That's how the first C++ compilers were built. Quick summary: RAII is something you get by the compiler automatically generating constructor and destructor calls in the right places. Polymorphism is just indirect calling via the vtable. Encapsulation is an overused term that doesn't really mean much here. Operator overloading is a syntactic transform: astring + "value" -> astring.operator+("value") (-> string_operator_plus(&astring, "value")). Functors naturally come as an effect of being able to overload operator(). These features do not add any additional expressive power; they're only shorthands to make some things easier.
Had I the time, I would either update Cfront or write my own C++ to C translator that enables a more incremental approach to optimisation --- instead of having to write everything in C, or directly in Asm, use C++ to generate all the C, then you can optimise the C before going to inline Asm. For example, in the above test program I could rip out everything that cout generated and isn't used, and still be able to use the advantages of iostream, operator overloading, etc.
>>59
It's written in C++ too. This shows that it's possible to write efficent code in C++, but you really have to understand how everything works.
C++ is a good language. It is not a perfect language because it inherits from C. C is a flawed language where many things are left undefined. C is an ancient artifact that serves no purpose outside of the domain of kernel design. Because of the improvements made upon C to form C++, beginning programmers and veteran programmers alike may be led astray, thinking that modern C usage is a good idea. It is a mistake to believe the success of C++ justifies the continued use and popularity of C. Just because C++ is successful does not mean the language it has inherited from is of high quality.
C++ wins if only for templates and namespaces. C++ is great because most of the fancy abstractions impose no runtime cost (except for virtuals). You call C++ bloated but it actually is a good thing because all that "bloat" allows alternative programming paradigms. C++11 can even support functional programming. C++11 has also made "managed" programming part of the standard: reference-counted smart pointers. It is officially just as quick to write C++ as it is to write Java or C# (baww no integrated GUI; just get Qt), yet you still can open up the hood and make low-level optimizations all the way down to inline ASM. C++ truly is the end-all-be-all for modern programming languages.
Name:
Anonymous2012-06-19 17:41
I find it quite amusing that so many C-fans believe they're working with arrays, when all they have is some dangerous syntactic sugar for memory manipulation and pointer "arithmetic." Can you say: "unsafe", "core dumped" and "segmentation fault"? If you can, and you still work with it, it's "your fault."
Name:
Anonymous2012-06-19 17:50
>>79
That's a part of the reason why I like C. You actually have to know what the fuck your doing and be a decent programmer to develop something. Not like java where the compiler holds your hand the whole time.
The worst part about C++ are the programmers. C++ as a language is fine, but it takes a while, probabbly longer than C to get a good grasp on what you are doing, and what the best way to do things is. Too many people try to do "C in C++" for example.
If you are using C++ then do C++. If you are doing C then do C.