Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

shrughes: Oct 11, 2008; (call/cc call/cc)

That Turkey Story posted:

This is what programming plebes actually believe.

No, this is what is actually true. Or rather, it is the theory that most accurately fits the facts. Pick any boost library. For example... *picks at random* the boost uuid library. It defines a struct that contains a 16-byte char array and has a few functions for creating UUIDs. It somehow uses or includes something that uses MPL.

Let's pick another ... *picks at random* the boost spirit library, probably the archetypal example. We implemented a bunch of spirit parsers and it's clearly overengineered garbage. Infinitely slow to compile, not fast or optimizable to run. It's always simpler, more debuggable, and more editable by coworkers, to pound out your own recursive descent parser, or to use some other method of building a parser.

Let's pick another ... *picks something "safe"* scoped_ptr. It has an implicit conversion operator. (And of course that's implemented by putting the line

code:

#include <boost/smart_ptr/detail/operator_bool.hpp>

in the middle of the class.)

Let's pick... shared_ptr: it is all mixed up with weak_ptr, to make it easier to make your code unnecessarily complicated.

Let's pick... boost serialization. "Oh, you want to serialize stuff? Sorry, you're using some slow library that wants to keep track of pointer graphs [and iirc, uses RTTI]."

The best example of making poo poo complicated for complete vanity is this binary conversion utility. It has a billion preprocessor expansions when you can just use a hexadecimal or octal constant, or convert at run time, or glue different field width sections together with a macro, or run an octal constant through some bitshifting...

code:

#define OCTAL_BINARY(x) (((((((((x) * 21ULL) & 0x9c0e070381c0e070ULL) * 0x1041) \
    & 0xff80001ff0000ULL) * 0x40001) >> 34) & 0x3ffff) | ((((x) * 1ULL) >> 42) \
    & (1 << 21)) | ((((x) * 21ULL) >> 40) & (7 << 18)))

That Turkey Story posted:

Boost isn't perfect, but it's generally as complicated as it needs to be and no more. Libraries go through peer review before being accepted. If you think something specific can be simplified without sacrificing functionality then post to the mailing list and someone will either listen to you and make changes or they will kindly explain existing rationale. If you have patches, you'll be all the more welcome.

It's very easy to create a "rationale" for any feature: you need it to do X. The argument against making things complicated is less tangible -- it is a sense learned by experience and not derivable through software philosophy.

# ? Sep 11, 2012 05:21

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 15:08

Workaday Wizard: Oct 23, 2009; by Pragmatica

Inexperienced opinion here:
The thing I hate the most about C++ is the polluted namespace. Can't include anything without having gazillion macros in the namespace.
Why can't macros be namespace or file local? :argh:

Is there any alternative that fills C++ niche? That is, is there any alternative language that has OOP, compiles to native code, and portable? If not, why not? Enlighten me, dear pros.

# ? Sep 11, 2012 06:09

hobbesmaster: Jan 28, 2008

Shinku ABOOKEN posted:

Inexperienced opinion here:
The thing I hate the most about C++ is the polluted namespace. Can't include anything without having gazillion macros in the namespace.
Why can't macros be namespace or file local?

windows.h is the best argument against windows

# ? Sep 11, 2012 06:17

Outer Science: Dec 21, 2008; Daisangen

Shinku ABOOKEN posted:

Is there any alternative that fills C++ niche? That is, is there any alternative language that has OOP, compiles to native code, and portable? If not, why not? Enlighten me, dear pros.

Gonna pimp Go here, as it was designed because C++ was too frustrating.

# ? Sep 11, 2012 06:22

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Shinku ABOOKEN posted:

Is there any alternative that fills C++ niche? That is, is there any alternative language that has OOP, compiles to native code, and portable? If not, why not? Enlighten me, dear pros.

# ? Sep 11, 2012 06:36

Workaday Wizard: Oct 23, 2009; by Pragmatica

Suspicious Dish posted:

C

Hmm... yes. No namespaces and no non-hack OOP. Excellent!

# ? Sep 11, 2012 06:43

taqueso: Mar 8, 2004

Possibly Rust

# ? Sep 11, 2012 06:44

That Turkey Story: Mar 30, 2003

I realize you're likely trolling but I'm going to respond anyway because that's what I do.

shrughes posted:

No, this is what is actually true. Or rather, it is the theory that most accurately fits the facts. Pick any boost library. For example... *picks at random* the boost uuid library. It defines a struct that contains a 16-byte char array and has a few functions for creating UUIDs. It somehow uses or includes something that uses MPL.

It's almost as if MPL is a useful, generic library that lots of other libraries depend on. Imagine that! It must be terrible! I can't believe that one Boost library would depend on another one from Boost!

shrughes posted:

Let's pick another ... *picks at random* the boost spirit library, probably the archetypal example. We implemented a bunch of spirit parsers and it's clearly overengineered garbage. Infinitely slow to compile, not fast or optimizable to run. It's always simpler, more debuggable, and more editable by coworkers, to pound out your own recursive descent parser, or to use some other method of building a parser.

If you really believe that then go right ahead and do so, though I highly doubt your claim that rolling your own recursive descent parser is easier for anything even remotely non-trivial. Of course, using Spirit would require actually learning Spirit without just whining like a baby and deciding that it'd be better to write everything from scratch. Clearly it's so much better to reinvent the wheel than it is to work with a well-designed, well-tested, and heavily used library. Plus, if you used Spirit, people would be able to look at the Spirit documentation as a means to understand your parser, rather than having to study your code to figure out some ad-hoc, likely buggy implementation. And we certainly can't have that.

Boost.Spirit exists for people who want an EDSL for parsing and output generation without the tedium and chance to introduce bugs that comes about from hand-rolling parsers from scratch. You are obviously not one of those people, so don't use it. That's fine, but if you really don't see the advantages of it then you're just completely oblivious.

shrughes posted:

Let's pick another ... *picks something "safe"* scoped_ptr. It has an implicit conversion operator.

That's called the convertible-to-bool idiom, and it's both good practice in C++03 and not specific to Boost. It's explicitly implemented in a manner that gets around the drawbacks of implicit conversion operators. The idea is you want to be able to do if( my_pointer ) just like you can with pointers but without having implicit conversion to bool (you don't want implicit conversion to bool because bools can be promoted to integers due to integer promotion rules). Instead, you convert to a type that can be used in a boolean context but that's not a bool itself and so it doesn't suffer from the integral promotion problem.

The real point here is that probably 90% of programmers don't know this and don't have to know this. Thousands of people use the library without ever having to think about it or even look at the implementation because there is no reason for them to, as is the case with most well-designed, well-tested code.

But of course, it's much easier to just criticize code you don't understand than actually ask someone about it or look into the rationale yourself. Certainly you can do it better, so just make your own -- oh wait, don't tell me, you've done so already. Have fun maintaining that while everyone else uses a more reliable library that the community in general is already familiar with.

shrughes posted:

Let's pick... shared_ptr: it is all mixed up with weak_ptr, to make it easier to make your code unnecessarily complicated.

What do you even mean here by calling them "mixed up?" weak_ptr and shared_ptr are two sides of the same coin. You use weak_ptr to have a non-owning reference to the object that a shared_ptr references. weak_ptr's implementation depends heavily on that of shared_ptr. Clearly those crazy Boosters were onto something since shared_ptr and weak_ptr are standard in C++11. Man, what were they thinking!

shrughes posted:

Let's pick... boost serialization. "Oh, you want to serialize stuff? Sorry, you're using some slow library that wants to keep track of pointer graphs [and iirc, uses RTTI]."

Yeah, if you want to "serialize" pointers, then that's the automatic way to do it. If you don't want that functionality then you don't have to use it. God forbid a library has a feature that you personally don't use -- that must mean it's over-engineered nonsense! It must have just been put in there because the guy wanted to look smart, not because he, you know, had a use-case for it (believe it or not, a lot of people use that feature, though I personally do not).

shrughes posted:

The best example of making poo poo complicated for complete vanity is this binary conversion utility. It has a billion preprocessor expansions when you can just use a hexadecimal or octal constant, or convert at run time, or glue different field width sections together with a macro, or run an octal constant through some bitshifting...

Har har, yeah, I made that, which I'm sure you already knew, and actually it owns. I know this may surprise you, but converting at run-time is often not an option, for obvious reasons, and the whole point in writing a value directly in binary is because you are often trying to represent something that is most clearly expressed... in binary (I.E. bitmasks). Writing your constant in hex or octal often does not show your intent whereas writing it in binary does. If you don't see the advantage of being able to write a literal in binary, then do you at least see the advantage of writing literals in octal or hex, or are those useless to you as well? After all, why not just write everything in decimal all of the time? Those people who use hex and octal must just be trying to look smart!

Anyway, if you really think it's for complete vanity, it's not. The reason that the macro exists is because other people wanted it -- I wasn't even the original one to propose it. In fact, I didn't even write it until a review for someone else's implementation was already underway (which first requires agreement that such a utility is useful to begin with). People show desire for a facility, there is a request for consideration of an implementation, it goes through peer review, and then it is accepted or denied (and a lot does get denied). It's not just a bunch of know-it-all programmers throwing in whatever they want.

shrughes posted:

It's very easy to create a "rationale" for any feature: you need it to do X. The argument against making things complicated is less tangible -- it is a sense learned by experience and not derivable through software philosophy.

What you refer to as "complexity" is what other people call "features." The functionality that exists in Boost is there because it is what people want or need. If you can implement that same functionality but in a simpler manner, then go right ahead and do so, and post to the mailing list about it. People will gladly listen and possibly use your code. If, on the other hand, all you do is complain about a library having a feature that you personally don't use or about techniques that you don't understand, then you're going to be rightfully laughed at -- not because those people are trying to be smart, but because you are being stupid.

# ? Sep 11, 2012 07:35

That Turkey Story: Mar 30, 2003

Shinku ABOOKEN posted:

Inexperienced opinion here:
The thing I hate the most about C++ is the polluted namespace. Can't include anything without having gazillion macros in the namespace.
Why can't macros be namespace or file local?

Macro scopes were proposed for C++11 but ended up being postponed.

# ? Sep 11, 2012 07:37

Edison was a dick: Apr 3, 2010; direct current only

Shinku ABOOKEN posted:

Is there any alternative that fills C++ niche? That is, is there any alternative language that has OOP, compiles to native code, and portable? If not, why not? Enlighten me, dear pros.

There's Vala, which has C# like syntax.
I've not tried using it on Windows, but it can compile to C, so it's theoretically
portable to Windows.

# ? Sep 11, 2012 07:50

shrughes: Oct 11, 2008; (call/cc call/cc)

That Turkey Story posted:

I realize you're likely trolling but I'm going to respond anyway because that's what I do.

I am not trolling, and you should be reminded that assuming I don't know what I'm talking about is a bad strategy for being right.

- No, it's not reasonable for UUID to use MPL. The fact that you think it's reasonable is an example of why Boost is such a horrible set of libraries: you don't care about quality, and you don't understand the benefits of keeping code simple with a constrained set of dependencies.

- You think I don't understand how Spirit works. I have used Spirit for parsing and used other people's uses of Spirit for parsing big and little things. We're no longer using it.

Y'know, when somebody says that they used to think X but then experience made them change their mind to Y, while you still hold the opinion X, it means you should reconsider X.

- Saying that people "want" Spirit does not mean it's a good idea. I don't know why you'd think it means it's a good idea. It's a plausible implementation of a bad idea.

- I know about the convertible-to-bool idiom, I've written it myself, and then removed it, and I just included reliable evidence that I looked at the code in my previous post, so why are you acting like I don't know how it works? Here's a conclusive example where even you should recognize that you were wrong about something. Given this new self-knowledge, you should probably trust your opinion about other matters less than you do. The convertable-to-bool idiom is another example of the X -> Y movement where you're still at X and I've moved on to Y.

- Writing OCTAL_BINARY(01101011100) (or heh, just using hex) does indeed show your intent. How can you say otherwise? The fact that people want a library for something doesn't mean it should be done. For example, see the Boost Spirit library. According to you, some people want that sort of thing.

- Yes, I have written smart pointer classes that did use the convertable-to-bool idiom and now don't. And guess what: they're reliable and don't require "maintenance." (Why the hell would you expect a smart pointer type to be hard to maintain? I know, maybe it's because you like to introduce unneeded dependencies to other libraries.)

# ? Sep 11, 2012 09:00

shrughes: Oct 11, 2008; (call/cc call/cc)

Shinku ABOOKEN posted:

Inexperienced opinion here:
The thing I hate the most about C++ is the polluted namespace. Can't include anything without having gazillion macros in the namespace.
Why can't macros be namespace or file local?

Incidentally, I've not really had a problem with that. Well, except for assert.h (my coworkers thought to define their own assert macro and it worked for several months until something included a system header that included assert.h) on Unix and and of course the windows.h.

# ? Sep 11, 2012 09:30

seiken: Feb 7, 2005; hah ha ha

I love a lot of the boost libraries, but it can be pretty hit-or-miss. I would never even consider using Spirit over something like YACC.

# ? Sep 11, 2012 10:02

Vanadium: Jan 8, 2005

Do I need to post on the boost mailing list to get bugs looked at anyway

Vanadium fucked around with this message at 20:36 on Sep 11, 2012

# ? Sep 11, 2012 11:54

PrBacterio: Jul 19, 2000

Shinku ABOOKEN posted:

Inexperienced opinion here:
The thing I hate the most about C++ is the polluted namespace. Can't include anything without having gazillion macros in the namespace.
Why can't macros be namespace or file local?

Is there any alternative that fills C++ niche? That is, is there any alternative language that has OOP, compiles to native code, and portable? If not, why not? Enlighten me, dear pros.

There are lots of imperative systems programming languages with comparable feature sets to C++, if that's what you mean; in fact it's probably because there are so many of them that C++ became the de-facto standard one to use in its particular niche solely due to inertia inherited from C. Many of these languages even predate C++ itself, while many others were invented later on but none ever caught on to become really mainstream popular in the same way that C++ has. In fact, new ones are still being invented on a regular basis. To name just a few: Ada used to be quite popular in certain circles due to a government mandate; in a similar vein, Object Pascal used to be popular in a restriced set of use cases as the language underlying Delphi. The Modula languages (Modula-2 and 3, as well as Oberon) are some of those that predate C++. Digital Mars' D is one that used to enjoy some small amount of popularity a little while ago, I believe; and then, of course, nowadays, there's Go.

# ? Sep 11, 2012 14:36

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Hard NOP Life posted:

It can even be done easily in Java using the handy @Delegate function that you showed me tef

Every time I look at Lombok I feel both interest and a strange internal terror. Stuff like @Delegate seems fine, while the SneakyThrows hack is ridiculous. (it lets you throw a checked exception without declaring or catching it by modifying javac's AST during compilation, IIRC)

# ? Sep 11, 2012 14:59

Amarkov: Jun 21, 2010

I now have four HTTP session attributes and three HTTP request attributes which attempt to name themselves "id". This is good, because rather than billing my time for something which would require actual thought, I simply have to dump junk in all of those places and determine which value ${id} is actually taking.

# ? Sep 11, 2012 15:11

ToxicFrog: Apr 26, 2008

Shinku ABOOKEN posted:

Is there any alternative that fills C++ niche? That is, is there any alternative language that has OOP, compiles to native code, and portable? If not, why not? Enlighten me, dear pros.

For systems programming, you want something that can cleanly interface with the existing system, which these days typically means C or C++. It's also fundamentally at odds with the "portable" requirement - if you're working at the systems level you aren't portable across OSes (and since it compiles to native code you need a seperate build for each architecture, at least).

For applications programming, no-one gives a poo poo about compiling directly to native code these days anyways! JITs and fast interpreters are good enough that it's better to just write your program in a high-level language that runs on the JVM or CLR and then deploy using some appropriate wrapper.

The upshot of this is that there is a lot of effort going into making better interpreters and JIT compilers, and better languages to run on them, and relatively little into making better ahead-of-time-compiled languages.

That said, there are some alternatives to C and C++. Objective C has seen a resurgence in popularity due to its use on OSX and iOS. Vala compiles to C (with a libgobject dependency) and thus works anywhere C does, and there are other Vala-based languages like Genie.

The comedy option is Digital Mars's D; intended to be a modern replacement for C++, it is actually a cautionary tale about how no-one will use your language, no matter how good it is, if the tools for it are poo poo.

If you're willing to move away from C++-style OOP, there's Go; if you're willing to move much further away, there are several Lisps that compile to native code, including everyone's favourite lisp-1 Scheme, as well as the functional languages Erlang, Ocaml, and Haskell. There are undoubtedly many others that I'm unfamiliar with.

# ? Sep 11, 2012 15:46

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Shinku ABOOKEN posted:

Hmm... yes. No namespaces and no non-hack OOP. Excellent!

It was a non-serious reply, of course, but I don't see what's hacky about GObject-style OOP, other than "it's not a language feature". And to be honest, it's very rare that I've actually encountered OOP as a useful tool when working in C. It's Not That Bad to just use structures and some form of prefixing namespacing. It's terrible, but nowhere near as bad as some of my horrors when working with C++. Actually, let's rephrase the question: what features of OOP (because there are a lot of them, because it's a thing, and C++ doesn't provide nearly half of them) do you want in C? Inheritance? Virtual functions? Something else entirely?

Tell me what you want, and I'll give you something clean in plain C. C99 (or even C11), of course.

a bunch of awesome people posted:

dick waving about boost and C++

To chime in with my own anecdotal experience, a simple boost::spirit parser for us took around three or four minutes just to compile, and it was unbearably slow at runtime. That's all good, and it's probably our fault, but the issue is "what now?". Since it's all this template gobbledy gook magic, there's no good entry point of "how do I make this faster"? Which documentation did I fail to read?

# ? Sep 11, 2012 16:36

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

That Turkey Story posted:

It's almost as if MPL is a useful, generic library that lots of other libraries depend on. Imagine that! It must be terrible! I can't believe that one Boost library would depend on another one from Boost!

A dependency the size of MPL is not something to throw in to simply some already simple code unless your primary goal is to ensure that the only way to use boost is to depend on all of it, rather than to create a useful library.

I think I would be less annoyed by boost if it admitted it was a monolithic blob with some optional components rather than pretending that it's actually modular. I don't really get why bcp even exists, as I've never seen it output something reasonable to distribute along with the application source.

# ? Sep 11, 2012 17:05

Zorro KingOfEngland: May 7, 2008

I just had to explain to a developer with 20+ years of experience why we should hash passwords rather than store them in plaintext.

Then I had to explain to him why we should hash them and not just encrypt them.

The guy is really brilliant, just doesn't understand security I guess.

# ? Sep 11, 2012 18:58

shrughes: Oct 11, 2008; (call/cc call/cc)

Zorro KingOfEngland posted:

I just had to explain to a developer with 20+ years of experience why we should hash passwords rather than store them in plaintext.

What kind of hashing did you suggest?

Just making sure you're not also a source of coding horror.

# ? Sep 11, 2012 19:00

Zorro KingOfEngland: May 7, 2008

Bcrypt. I don't pretend to be an expert either, so if there's a better solution I'd like to know.

# ? Sep 11, 2012 19:03

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

MD2, of course. It's so obscure nobody would think to try it!

e: my lovely joke was beaten by the real answer, gently caress

# ? Sep 11, 2012 19:03

hobbesmaster: Jan 28, 2008

Shinku ABOOKEN posted:

Hmm... yes. No namespaces and no non-hack OOP. Excellent!

C has support for everything, you just have to find the right way to abuse the preprocessor. :smug:

# ? Sep 11, 2012 19:09

shrughes: Oct 11, 2008; (call/cc call/cc)

Zorro KingOfEngland posted:

Bcrypt. I don't pretend to be an expert either, so if there's a better solution I'd like to know.

Just making sure you weren't using SHA-1 or something

# ? Sep 11, 2012 19:22

That Turkey Story: Mar 30, 2003

shrughes posted:

- No, it's not reasonable for UUID to use MPL.

Why? Because you say so? What if it included the C++11 <type_traits> header instead of MPL and used std::conditional instead of boost::mpl::if_? You seem to have this unnatural fear of MPL. People aren't going to arbitrarily avoid using MPL if one of its facilities is useful to them. It's not like including one little fart in MPL pulls in the entire thing. Maybe you don't want to pull all of Boost into your company's project. Fine, although that's rarely a worthwhile concern, especially given that the vast majority of boost is header only and you likely aren't going to be frequently altering it once it's in your project.

shrughes posted:

The fact that you think it's reasonable is an example of why Boost is such a horrible set of libraries: you don't care about quality, and you don't understand the benefits of keeping code simple with a constrained set of dependencies.

So because I don't care that UUID indirectly uses a part of MPL, I all of a sudden don't care about quality or having a constrained set of dependencies? Explain to me how you've come to this conclusion and how your life is so horribly impacted because UUID indirectly relies on MPL. Did MPL kill your parents or something? MPL is a toolset of very general and very useful compile-time utilities. Programmers don't just use it to be cool or to pull in dependencies.

shrughes posted:

- You think I don't understand how Spirit works. I have used Spirit for parsing and used other people's uses of Spirit for parsing big and little things. We're no longer using it.

Your personal opinions on an individual library are not greatly affecting my, and other people's opinion on it because we have our own experience to rely on. Yeah, it often takes long to compile parsers generated by Spirit, knowing Spirit is a hurdle to understanding Spirit code, and you generally need to be comfortable with expression templates to be able to work with it. You've weighed your options and decided that for your project you do not want to use it. Fine, but using that as a reason to say that the library is of poor design is foolish and ignorant. Different people have different projects with different requirements and people working on code often have different skill sets. Spirit is not the end-all be-all of everything related to parsing that everyone will use for every project. That doesn't imply that it is poorly designed and it doesn't imply that everyone should hand-roll their recursive descent parsers from scratch as you have personally decided to do. Is there some specific implementation flaw that you'd like to criticize or do you just think parser generators in general are useless and a waste of time?

shrughes posted:

Y'know, when somebody says that they used to think X but then experience made them change their mind to Y, while you still hold the opinion X, it means you should reconsider X.

Believe it or not, I too form my own opinions based on experience and rational thought, not because shrughes says so. If you have something worthwhile and objective to say, I'll actually listen. If, on the other hand, you have some arbitrary philosophical criticisms about one Boost library including part of another Boost library or some personal anecdote, then I really don't care at all.

shrughes posted:

- Saying that people "want" Spirit does not mean it's a good idea. I don't know why you'd think it means it's a good idea. It's a plausible implementation of a bad idea.

I didn't say that's why it's a good idea, just that it's not some arbitrary library thrown down the public's throats. It exists as one very powerful option to filling a common need. You have yet to explain why Spirit is objectively a bad idea. I understand that in shrughes's personal opinion, it's garbage and you've decided not to use it for your project, but you've failed to explain to me why it's not good design or why it's not good at what it does.

Do you think that Spirit is useless for everyone or just you? If just you, then how does that imply overall poor design? If everyone, you'd better make a pretty strong case and an alternative approach that doesn't involve writing everything from scratch all of the time, which you haven't.

shrughes posted:

- I know about the convertible-to-bool idiom, I've written it myself, and then removed it, and I just included reliable evidence that I looked at the code in my previous post, so why are you acting like I don't know how it works?

Because you talk about it as if you don't know how it works. Yeah, it's a weird idiom, but it is effective... so what exactly is your point? That if some random person sees the code they might be confused for all of a few seconds? If you're really that uncomfortable with it, write a little comment rather than deciding to sacrifice the functionality it provides.

A lot of smart pointers do this and people don't whine about it because there's nothing there to whine about. Like I said, in the real world nobody cares what's going on when they do if( my_pointer ), nor should they have to. It works, it's correct, it's efficient, and perhaps best, they didn't have to write it. What's more is they're probably not ever going to look at the source, just like they'll rarely look at their standard library's source. If I took two smart pointer types, showed their usage to a programmer, pointing out that one allows you to do if( my_pointer ) and the other makes you do something along the lines of if( my_pointer.is_valid() ) or if( my_pointer.get() ) do you honestly think that they give a poo poo that one uses an idiom that they may or may not be aware of underneath the hood and that it will somehow negatively impact their ability to write code or use the library? Further the interface difference is unbelievably superficial. Would I really care if I had to do if( my_pointer.is_valid() ) all of the time? No, but if there's a more concise way of writing it, I might as well take advantage of it.

shrughes posted:

Here's a conclusive example where even you should recognize that you were wrong about something. Given this new self-knowledge, you should probably trust your opinion about other matters less than you do. The convertable-to-bool idiom is another example of the X -> Y movement where you're still at X and I've moved on to Y.

shrughes posted:

- Writing OCTAL_BINARY(01101011100) (or heh, just using hex) does indeed show your intent.

First off, your macro doesn't work for large binary values, which believe it or not, is exactly the primary use-case for writing in binary (again, bitmasks). It also is very easy to misuse by simply forgetting to have a leading 0, in which case you won't get a compile error, you will just get the wrong result and a very subtle bug. There are also other features of the macro as it exists in boosts that yours does not have, such as suffixes and groupings, but I'm sure this is just entirely pointless to you and so therefore must be poor design. Finally, that macro doesn't do a lot of preprocessor metaprogramming, but it's not exactly easy to figure out what's going on there or that it even works for the full range of values (again, it doesn't).

Also, just using hex generally does not directly show your intent when working with bitmasks. First off, when writing a bitmask you have a bit pattern in mind -- that's why it's a bitmask. If you have to write the value in hex or octal, you're going to have to appropriately, and manually, convert it. Similarly, for a reader, the first thing you're going to do to figure out what the bitmask corresponds to is convert the hex or octal digits to binary in your head. Writing the value, you know, actually in binary directly, removes both of these unnecessary steps, and in doing so removes some of the chance for human error. I understand that you have the correspondence between every nibble and every hex digit memorized, but plenty of people don't, nor should they have to to quickly and easily write out something as trivial as a bitmask.

shrughes posted:

- Yes, I have written smart pointer classes that did use the convertable-to-bool idiom and now don't. And guess what: they're reliable and don't require "maintenance." (Why the hell would you expect a smart pointer type to be hard to maintain? I know, maybe it's because you like to introduce unneeded dependencies to other libraries.)

All libraries require maintenance, shrughes. You're telling me you literally poo poo out gold that was completely bug-free from the start, manifested by God, complete with tests that have been run on dozens of setups, all in the time it takes to write #include <some_library_header>? Forgive me, I wasn't aware that I was in the presence of the programming messiah.

Go ahead, write all your trivial bits of code from scratch because you have some arbitrary philosophical gripe with already written, heavily-tested code that does exactly the same thing and that thousands of other programmers are already familiar with. I personally love working on projects where some supposedly hot-poo poo programmer likes to write everything on his own, including trivial smart pointers, rather than use existing solutions to problems solved a decade ago. I know, it must be fun to write or learn yet another smart pointer for a given project that has no actual benefit over something in the C++ standard or in Boost. That's really a great approach to programming. There is no possible way that that time would have been better spent writing code specific to whatever domain you are actually dealing with.

Plorkyeran posted:

A dependency the size of MPL is not something to throw in to simply some already simple code unless your primary goal is to ensure that the only way to use boost is to depend on all of it, rather than to create a useful library.

You make it sound as if you use a part of MPL you are using all of MPL. Many MPL headers are very tiny and don't include a lot of other stuff. The library is also header-only. It's not like when you #include <boost/mpl/bool.hpp> you are pulling in <windows.h> or something. The headers are properly fine-grained and the only thing that generally makes things larger are workarounds for compilers you may not need to personally support. Things like boost::mpl::if_ are extremely useful for many libraries, and is why it made it's way into the C++ standard. It's no wonder that a lot of libraries use it. Of course, I wouldn't imagine you'd throw a hissy fit if someone wrote #include <type_traits> to get std::conditional, but in actuality that pulls in more unused code than #include <boost/mpl/if.hpp> does just to get the equivalent functionality of boost::mpl::if_c.

Plorkyeran posted:

I think I would be less annoyed by boost if it admitted it was a monolithic blob with some optional components rather than pretending that it's actually modular. I don't really get why bcp even exists, as I've never seen it output something reasonable to distribute along with the application source.

I wasn't aware that Boost pretended to be anything but monolithic. It is inteded for a user to download all of boost and drop it into a project without hassle. BCP is tool for very specific cases and is not intended for general use.

# ? Sep 11, 2012 19:40

shrughes: Oct 11, 2008; (call/cc call/cc)

That Turkey Story posted:

You're telling me you literally poo poo out gold that was completely bug-free from the start, manifested by God

For simple stuff like smart pointer types and uuids? Yes. And they are manifested He who created the world and and through His programmers brings C++ code into this world.

Also I had my code blessed by Victor.

# ? Sep 11, 2012 19:47

raminasi: Jan 25, 2005; a last drink with no ice

ToxicFrog posted:

The comedy option is Digital Mars's D; intended to be a modern replacement for C++, it is actually a cautionary tale about how no-one will use your language, no matter how good it is, if the tools for it are poo poo.

This is the succinct description of D that I've been looking for. I'm still disappointed about D.

# ? Sep 11, 2012 20:10

Hibame: Feb 20, 2008

In the core of all the applications here there is a shared C# lib that contains a StringUtil class, which has plenty of head scratchers. There is one method that piece de resistance

code:

public static bool IsNullOrEmpty(string value)
{
        return (value == null) ? true : String.IsNullOrEmpty(value.Trim());
}

# ? Sep 11, 2012 20:11

raminasi: Jan 25, 2005; a last drink with no ice

When did String.IsNullOrWhitespace get added to .NET? Because that's all that is.

# ? Sep 11, 2012 20:12

hobbesmaster: Jan 28, 2008

GrumpyDoctor posted:

When did String.IsNullOrWhitespace get added to .NET? Because that's all that is.

.net 4 or April 2010

# ? Sep 11, 2012 20:26

Vanadium: Jan 8, 2005

I'm still so bitter about random cosmetic D features, and since we're in this thread...

Their ~Universal Function Call Syntax~ allows you to call a free function as if it was a method of its first argument, making for a rather half-assed implementation of C#'s extension methods.

I thought it was dumb and resolved to not use it in my code if I could help it, and then went on to write something like stderr.writeln("Totally helpful error message") and got nothing in stderr but something confusing before my error message somewhere later when stdout got around to being flushed, until I realized the member function was called writeLine and I was inadvertently calling writeln(stderr, "blah"), silently writing the stream object to stdout. :stare:

The way they're doing properties is also kinda confusing, you basically get to call methods without arguments without the () and methods with one argument like methodname = argument. They were going to require a @property tag which changes the type of the function for that eventually but I don't know if they got around to that yet.

Also they just had to change the way const works so that to get what in C is called const char*, you have to write const(char)* to prevent the pointer part from being const too.

# ? Sep 11, 2012 20:32

Dicky B: Mar 23, 2004

Vanadium posted:

Also they just had to change the way const works so that to get what in C is called const char*, you have to write const(char)* to prevent the pointer part from being const too.

Why is that worse? Beats spending brain cycles trying to deduce the difference between const char *, char const *, char * const and const char * const.

I just want D's scope statement in C++, and the built-in unit testing. Everything else I can do without.

# ? Sep 11, 2012 20:47

Vanadium: Jan 8, 2005

Mostly because it's going to trip up people who assume it's the same as in C, and I don't really see the advantage. I'd rather leave const as it already worked in C and require the const(rest of type here) form for everything-is-const.

# ? Sep 11, 2012 20:50

Vanadium: Jan 8, 2005

Also D's alias oldname newname is clearly inferior to C++'s using newname = oldname syntax as a typedef replacement once you start listing three or four attributes next to the type like in alias ref int @property function() Fp; and get confusing errors because it should be alias ref int function() @property Fp; obviously.

# ? Sep 11, 2012 20:58

Vanadium: Jan 8, 2005

Also D lets you assign non-static member functions to function pointers without a cast or anything, and the function pointers will segfault when called while this doesn't happen to have the right type in the lexical context of the call. :stare:

# ? Sep 11, 2012 21:08

Zamujasa: Oct 27, 2010; Bread Liar

Hibame posted:

code:

public static bool IsNullOrEmpty(string value)
{
        return (value == null) ? true : String.IsNullOrEmpty(value.Trim());
}

GrumpyDoctor posted:

When did String.IsNullOrWhitespace get added to .NET? Because that's all that is.

I might be misreading this, but it looks like an infinite recursion, since if you give it a value of "EXAMPLE" it will try to return the result of IsNullOrEmpty("EXAMPLE".Trim()) (essentially, the same function call), which will call itself again and so on and so forth.

The only case that looks like it would work properly is if value == null.

(I am not an expert in C# so this may be wrong)

# ? Sep 11, 2012 21:13

Opinion Haver: Apr 9, 2007

Vanadium posted:

Also D lets you assign non-static member functions to function pointers without a cast or anything, and the function pointers will segfault when called while this doesn't happen to have the right type in the lexical context of the call.

Hahahah oh my god.

# ? Sep 11, 2012 21:13

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 15:08

npe: Oct 15, 2004

Zamujasa posted:

I might be misreading this, but it looks like an infinite recursion, since if you give it a value of "EXAMPLE" it will try to return the result of IsNullOrEmpty("EXAMPLE".Trim()) (essentially, the same function call), which will call itself again and so on and so forth.

The only case that looks like it would work properly is if value == null.

(I am not an expert in C# so this may be wrong)

No because I assume the class is named something like StringUtil, so it will resolve to the right call (String.IsNullOrEmpty() vs StringUtil.IsNullOrEmpty()).

That's a perfectly useful utility function for 3.5, and don't assume that everyone was able to port their 3.5 codebase to 4.0 the day it was released. At worst, it was written in 4.0 by someone who wasn't aware of the new addition of IsNullOrWhitespace().

# ? Sep 11, 2012 21:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »