If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
miguel "i started c++ project, but forgot to hire c++ programmers" de icaza
miguel "scared by templates" de icaza
miguel "pathetic uneducated whiner" de icaza
So bad, actually, that Qt had to implement a meta-language complete with parser, just to get some semblance of logical GUI code.
qt's use of moc is 1) unwarranted - it's some remnant from twenty years ago(when there were no c++98 and some student programmers created what they were capable of) and 2) has nothing to do with raii. stop making fool of yourself
As someone who uses C++ for a living, all I can say to this is *bollocks*.
as someone who does not undestand what raii is, you make perfect example, why so many people hate c++: because some clueless children call themselves c++ programmers.
The STL implementations are not ABI-compatible, so your code will crash as soon as you try anything more complicated than "hello world".
stl implementations are not abi compatible because they contain different code, different class layout, etc. because they are two different libraries. it has nothing to do with c++ abi, every two random libraries in every language will be abi incompatible.
My point is still valid: RTTI is a piss-poor substitute for proper reflection.
no, it is not valid. always-on rtti has no runttime overhead, while 'proper reflection' does. adding overhead for not used features is against c++'s goals.
rtti isn't substitute for builtin reflection. in c++ you have to make your own reflection if you need(almost noone needs). you can use rtti in your implementation. there is research ongoing for adding optional reflection to c++
std::string over cstring, generally agree although I think std::string's api is lame and archaic, not matching the other std:: collection apis and is a total mismatch with utf8.
exceptions? a big gun to shoot yourself with and a way to make your code hard to trace due to call stack blowing. Too many folks treat normal bad data as exceptional. Our nicest compromise has been to have isValid() checks on important state stuff, allowing computations to go on even with bad data to be checked when convenient.
pure classes are almost always overkill, over encapsulation requiring too much boilerplate accessors. We find that allowing direct access to some data members, then checking current state with isValid() to be reasonable, reducing a bunch of boilerplate.
utf8 fits nicely in std::string, just keep in mind that elements are just bytes, not codepoints
two your uses for isValid with pathetic excuses make me cry
utf8 fits nicely in std::string, just keep in mind that elements are just bytes, not codepoints
Spoken like someone who has never used C++ professionally.
If you do what you suggest, you can no longer search, split, concatenate or use iostreams, ergo std::string + UTF8 is absolutely useless. Which is why you have QString, boost::string, vtkUnicodeString and a hundred other incompatible re-implementations.
Last edited by BlackStar; 06 January 2014, 03:05 AM.
Spoken like someone who has never used C++ professionally.
If you do what you suggest, you can no longer search, split, concatenate or use iostreams, ergo std::string + UTF8 is absolutely useless. Which is why you have QString, boost::string, vtkUnicodeString and a hundred other incompatible re-implementations.
kid, you already showed that you have no clue, no need to continue. search, concatenate and iostreams work just fine. even splitting works when you know where to split(for example after search).
advanced tools are needed when you want to change case or do some other character-level work. but for displaying, opening file, writing to file std::string will work flawlessly. and most programs need just that
Comment