whats wrong with c++?

it has namespaces, better standard libraries, a plethora of modern conveniences, and all of c's functionality.

if you don't like objects don't use them

if you want to feel like a programming badass and do everything low level then learn assembly

>>36

The latter would be sufficient, and could be used to implement a mechanism for reflection.


>>37

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.

>>38

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.

>>39

There are a variety of ways to implement classes in C.

>>40

no

>>35
/d1reportAllClassLayout

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.

If it ain't Lisp, it's crap.

>>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.

>>41
Why don't you show the power of your ``C with code generation" and answer your challenge?

>>44
You had me doubting myself for a second...  I just built this with the MSVC command line tools, using all defaults:
[code]
#include <iostream>

class my_class
{
public:

    int member_x;
    float member_y;

    my_class() { member_x = 5; member_y = 5.0f; }
    ~my_class() {}

    void method_z() { member_x++; member_y++; }
};

int main(int argc, char **argv)
{
    my_class instance;

    std::cout << instance.member_x << "\n";

    return 0;
}
[code]

There are no occurrences of "my_class" or "member_x" or any of the other names anywhere in the executable.

>>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 iostream is 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;
};

void construct_my_class(struct my_class *this)
 { this->member_x = 5; this->member_y = 5.0f; }

void method_z_my_class(struct my_class *this)
 { this->member_x++; this->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.

>>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.

>>50
Either way, if it ain't Lisp, it's crap.

>>50
Have you heard of ASN.1?

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.

>>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.

Have you heard of ASN.1?
nope. What is it?

>>53
It means anus no. 1

>>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.

>>55
why the fuck would you even use classes in c?
its really awkward and doesn't make sense

>>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

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.

>>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").

>>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.

>>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.

>>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.

>>62
Yep. The OO Kay had in mind was not the OO implemented in C++.

>>27
So why not apply this procedure to the assembly output from the compiler? Now you have safe C.

See how flawed your logic is?

>>61
It is more about event/message/intention-driven and distributed computing

wat
there's nothing inherently OO about those things

>>65
there's nothing inherently OO about those things
Yeah, you're right. You have been trolled.

OO is shit

OO A SHIT

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.

ᠧᐴᕉЂ唩၂祩䠡鞘脇ᄷؔ㘓杄ᒔ䢓ᕧ捂荣ㅱ䦀吁☇錣呈ɒ㉄晈椨鈓蕩荐▕夀̘╠蜰梙瀆喀扨㉀㕐መ蜥堐牰鄙⌀䥰㠉䂗霦蜙顲ᘴ祀⁄荥眳"灙圦噂禄㐶偷萧鞂⡘昱⌵甅㜵䤣ᥐ框္ᕴ邂⥵錢挗Ն椠㘥㤤夑┅䥙塄熖〰恰剉⎇搨聨䙉䠷(ᡠ梁ѩ摣ݰ瑰耖萉砃㉓昙㢐椣㄰㔰杵ጘ頉摆扑➀やၴ唉茔ᚈ䘥扖颃餱噙䆆⡶刧Ș处䡠㌑楄げ倓㘲錓鑶㜢冁戵健㔓᠖᤹≦㡹抄㕉鑴螐錣蔱☙⤣蝴᠗⍶ᘦ扄ㅶ耴䘓煑㙓攣栃噠䅗顧悉扂䌨㌢✀⡐ܔ蝖̱琠蒁頔聲瘹鄠睂艡頣ɩ呕⑐蕂堀ၥ恨㒃ņɅ䜡䅧钉㖒䝀卣捣䔇䠑葰墀爲慉銒茕唰☐璑ㄥ㐳啷腕䠄⦂抇㦉㤄犄煒鈄㝔☹鍔ژ݉猩䁓⑂砷慒猆㜡ⅲ莁ܢ艙㕓⢅⡄⦇璕頂椐ȣ嚀䍒鉹荕㍕逗ٙ ᘠ⦕ᝧ煨攄蘑执酡㉶ጆᐠ霙椃䍤⑓怳㎒ࡩ蝩瘷㡴遈褲鎃镓虂᥁ㅙ儶匂瀩ᢔ

锳蕵倗挹敦ᡇ蔂呷鐖၀㘣荤鑘塈ख़斓栅㙖扉≅ॶ概墁睡蒁䌡锄焹Ѣ䅗፣ㆁ脤偂⑐ᄆ䤢䉣砇當阦蕤؇㡈瘥㉡㡕搕᎕㆖舷䄣ᔓ摓ទ䥘▄鉴興憓者钉㥑〥脧█㉦․ፒ煒鑕▓ᅓ䝓䑥蔳呄䅑甃Γ♀ܳ刄噸艄愸掑⤢呁褴瑅Ҁ覗捩璀蜣䜅ဩㅘࠃ否ॅāኃ桧閈ޅᝉ疅陖榒扨茄琗锥ゕ啤⌑朦聘嚁錳㜹鍘̃艅䢔灣霉靀榈ᤧₒ慰Д∴㒙䞕持䌗聂圶舳ᐩ長艳⡨ᡦ頓瘙᐀㕒ɘ愵घ錖卢爹㜦坷猧Ր䥲甦ᆙဆ䥤牔鈀數襦ፓ҇䁰㜁ĥ晀ܔ夒挖ݔᔂ舄剄䂃吂甴䜘İ鐡犘❓ↆ䈈皔㐥ᝡ䅈酶玖鈡䦑隅陦蔨〉䦐瑢ঈݡ䑘ᢆ榅圤撅艃ԁ萦⒃杩摰撕萣靁鈒ֈ䡴℔砇衐㍃瘷䌕啵䁇扥ᕠ楤㍵堧ا֐蚅⤤鍸敓݉㠠煄᎐㒄䚇肓䞃椔ふ⍦ㄒᚖ遈ܑ瑵᠕†怄昕茣坓逥✹蠨春॰ܕڈㄐᙰܘ኉塈㝈㔓⊐䕲㔲蔐睳㖄琡㍹抂堰杹ᕄ衁䎓②㥡š鄧

⠥Գ䅣睖朣銖⊘㜅餖唠院悅⥷吤ݵ㔧Ч匣⦑፲榘ㅣ☕䝷吴⊗蒁䁹❦灇ᄑ荀ቹȃ鞂栶镖♀茆虈䔈Ѓ袗虒霢䍗㚄䀓̆㌥荱⥹腃斂द嚁掄䚓ᐥ熘㉘顈ᐑ☹⑵獴䍨爵⥀䞔᠙吵咑圢⡷䕆ւ葅Ԕ蔩䉥ܕ处䡙䡵ࡵ頳嘣茸Ġږ襩硄⦀焸倱㚉㥥疆❶े②舳霢ቂ〥蠄癧⊒؁⒉榓䘶ɉ芈䜃蒃⒗䍡䚄坄㑆褧ㄈݕ呤䂕腲㜂戔䡔遁᠆椂㜶牶鑃ɖ䘴田薆霅Ęᢒ邀陇愔䤩茁؂艢〷♐យࠒጙ獴❂葉ㆆɄ处祦㍧⑘‐典ぱݓቅ聤䄁ࠢ⥵Գ䀶舁Ţሳ甀✆f唄莈艦餱遑偸ᥲ癉肈✉ᙩ熀锰餹唹 ㅩ┨瑳ㄡҕ虄ᤕ暆摐ᑳ鍂蔂噢草瘆ၳ癲啇☷閉㔲䘦剴耳䞉愓䜡茅芉䅶虴ᜳ堉Ж劇䈡焈灵̳⢀咉儂✣᝕祣♃䁕遶梗祦ı霗嚘锖楲剓爷ᑈ畗⍈び垗呶ᖉŒᢃ⚗䝘ᅱᖔ儕ᅶ兒⥂䝠㉇扶霗㝹␠㠦偙♴㐕〕鄙癃ށҖ饖斅䖙蔵昔健熔♲腴肆䍃ш碕

呉蝓䥙癀噗䙸ȹ”⅃焄䒒到祆ᐂᘑ 圄㑕ɦ噐脨耴吕䉓⑹艗舀р鐒鈰煐䄧垃刁倶Ѣࡸ馁㊄膐倨艇頔́㡁鞖蚕ㄣ镰嘒㘔枉⡰ॕ猔㉵䤰䑸摑㝐薃ᘣ扅皘Օ圈瞗䝁鑥灙ܙբㅔ牲阤脂╗味疆䄐成眲䔒䘙ᄂ祸䈷葐ᡩݵ硄䥢癗蝉劗❘գ冖萠螂煷䁗褲ࡢ㠵瑒Ɉ㑓頉⦃呃䅩䍶㠒ٴ挘࢐㞄襳爕爠硸晃䤱㕰㒀會ጢ␧憅嚘㈨熖Զ蕡䠴錤皑霑睹悂覗䂓䡔⍰噡㕔咁ᒑ喒腸㊆葷䘡梄ࠓ肙㥢▂瀵芅㞘饡䦇癔熄⒘杶圀उ玃❨杩̡鉤栶ᜆሸ愈℠圖∣吤恦⢙鑇啁愖慦璀覃䁇㥈鉣脕ဧ➅㠳Ŷ脹恧聵㜐腃ƃ䤂㉳匦襈阢蜓礷爈㕑儖†ă䉕朦唅ᆔቤ锐⢉憅攤险℧蕩煡࢕倥阩ॵ璀ᤵ甡ባ典炒℁憓☁攡䜤ࡔば楹ႁ脳鑧遶領嘙㐙聤㘳၀钘墕ळᆘᥧ␡舱☹襥䍓慕ᠦ圢钗唉砉䕇吂攰⁉褘ę䜑眲ㅤ⑁䔖ܡक㜘ࡄ倡锂匳杲夂奵صЂ爲䡘

唓元獶戤匠ᕙ椧ळƆ㝴ᙈ腤錖老恠᥁暈邁偑鈑撁鄢镂琓癐ᐡ戱蘕逶祐䉨ࡃ䦑㦉瀐葹摕蘇聅ړ鉈ᐓថ肉䈈慖ᒄ㢅奄冀ና刑挢䙶䜹ш啂㍇晁㆕畁㉦颅፴цၐ熄‚㜲䢗牃襤♦癤陵捷疉琤甒㉵䄖鎓硥♤ᅵ醃鉩إሃ餔牂㔕㈣鑑䄤⁴䖓利Ʉ荖∷㑘儉Ű锕䉶ቹ瞖杔蔖倄⊀鈘癐䎃Є衘場墖怀妑蠘᝷✦䜄〰䜶霉গ倆抑瘦兤̅⍰Ԕ㕀瞐獤昤炈㉗礱䉑地ᦃ撒㥠皑蔉≥瞄眣敆瀘饰ԵѢ荴㥃⒆灩朷㑈⡳䑷㘕䞕㍲悆腧և蠸摹ᑤ䅥膈榉䙹镅ᠧ噷┐ˆ晴栃᎑ऄ興猆焴ⅳ怆Ťق聦ँᙥ睂䕸΄ࠒ桓癩杗ᅡ刲⎀䅕煔ᘗ甑劁㜶摆㕄茩鈆朂蜷茳䍱茆ᡰ靸♁醈䍹唴䔖✐椗鄲傀灃桢聩᜗䈣楴捈ݙ䙉➂砠䡃蒇䁘鞐嚀项؂瑲靐砀地頰䥓ᅠ预頔䤠锨ᑂ顇獩戥剗ᅰ攸⚉ᄣࠡ蝶焷♡栃锓ġЖ䊆♳銓̣夢̴敓Œ枓䂆䤁✗〈吩悖咇㠲炈㜂攱

䙘単厔灂薄愔遳䐲瘐䒕ᑷ慷敇鐄瘕慔錃≂銕❖邓用ፑ㍑䑖瘳愃犒琦ひ➖〦悄ԙ鑐䜐牳嚃桠搗褳ㅇ㜦茙煈袓鈣❄戗Ͷሶ⌄䅄獓႔⤘≨玙ᒈ灦扥㍶♦厗蠧ሃ牁匐䅣療ᔒ蘉ᕐဂ䅑刦扒畕➅田錦㔣捧܆蠃⊀ࠉᐹ易طĔঙ•收䤳袄ፕ醇∸┐朶٤瘨耵鄴䥦鄹䦓收䄕噗ه≗⁀奱ᤶᑙ煷熓蕄荩眗ᐗ䈵阕⠶攨艙栙䈀昃㠗夵餤ᤦ猃阢ᖙܦ楂錒树顄刐砱荐␇ز✤ؗѓ酱┈㈐肘ᠦ᠑蔆馂鍃墉垁ݢ刡❔硳䢕蜡✓隔塒聁瀄̨爹㊈饖ၓ耆眈䀆煣荖፲昦儖ʄ陨ʗɡ癑᜘ᦗስ㘳䉕㌡酣䌐ጰ頂❀Ҕኗ➃舄荩➅ф㌷䁢怃ᘒ覔鑘戸ቑゔ兙₂ᕧ㑴璈㥱暂∵ㅱ⠡ぢI䡁袂芁䙐㝣䤣〢㍧畁唸畢㉖打ᡉ鍕㌰≳ɵ☂耳䑁虈⎅颁瑄搁晩桧鈸࢒┗祀ȱ瑸炑ᤉ䈠蠂㙨猅領䑸ㄓᅐ栁ᜧ杂㑦剨䤄䤲呁茷㑁脆ȅ选㘓䡖ᥙ嘧儈皆眉妁荴ᅑℰ䊖䜱

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.

ITT: C++ is good because C is bad.

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.

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."

>>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.