|
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. Nah. Hibame said this was in a custom StringUtil class, so the stack will just go StringUtil.IsNullOrEmpty("EXAMPLE") -> String.IsNullOrEmpty("EXAMPLE".Trim()).
|
# ? Sep 11, 2012 21:17 |
|
|
# ? Jun 3, 2024 21:53 |
|
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. Wait, what? What was even the rationale for this?
|
# ? Sep 11, 2012 21:26 |
|
That Turkey Story posted:Wait, what? What was even the rationale for this? http://d.puremagic.com/issues/show_bug.cgi?id=8114 I don't entirely see what they're getting at. Edit: Here's a more elaborate example: code:
Vanadium fucked around with this message at 21:55 on Sep 11, 2012 |
# ? Sep 11, 2012 21:47 |
|
That Turkey Story posted:Wait, what? What was even the rationale for this? I hope it segfaults in the same way boost::bind segfaults if you don't pass it this as the first parameter.
|
# ? Sep 11, 2012 21:55 |
|
Thank you all for your replies. I bookmarked the docs for the languages suggested and will be reading them as soon as I get free time.Suspicious Dish posted:... ... I don't know what I really want... I am the coding horror Language design is hard. I just want some sane scoping. Content: Back when I was a student one of my classes required us to write caching web proxies in C in pairs. We didn't have source control (of course) so what my partner and I ended up doing is write a main file that #includes "myname.c" and "hisname.c" and just write our code in separate files. Coding that proxy was fun!
|
# ? Sep 11, 2012 21:58 |
|
I'd like to suggest that the D motto is "Those who cannot learn from history are doomed to repeat it" but I can't really argue against the combined Walter Bright and Andrei Alexandrescu C++ learnin'.
|
# ? Sep 11, 2012 22:08 |
|
The problem with StringUtil.IsNullOrEmpty is that it shouldn't have the same name as String.IsNullOrEmpty while having different behavior.
|
# ? Sep 11, 2012 22:16 |
|
Shinku ABOOKEN posted:I don't know what I really want... I am the coding horror When you figure it out, let me know. I'll be glad to help. Shinku ABOOKEN posted:Content: I've seen that in real code (I've done it, even). It's a poor man's form of linking, at some level. The simple example is if you have a lot of code in one file that manages two components, especially if one is a subcomponent of another, splitting it out into its own #include is one of the easiest ways to manage it. I usually put a comment at the top, saying /* this file is part of foomp.c */ or whatever.
|
# ? Sep 11, 2012 22:21 |
|
I see. I missed that detail and had assumed it would use the same method. I have to agree about having the name be different, though, since it's technically NullOrEmptyOrWhitespace...
|
# ? Sep 11, 2012 22:26 |
|
I'd just go with ConsideredUseful at that point.
|
# ? Sep 11, 2012 22:52 |
|
I want D's invariants.
|
# ? Sep 11, 2012 22:59 |
|
Hibame posted: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 Every time I see a project with one of those utility classes dealing with primitive types (or strings), they're always full of silly little methods, often one-liners anyway, and almost always re-invent the wheel instead of just using the framework. Just use ToString() with either standard or custom formatting strings, and cultures. Also, that method is nasty. If I pass a string with " " (a spaces), it is not null nor empty, but that method would return true. That's a good example of a method name not doing what it promises.
|
# ? Sep 11, 2012 23:15 |
|
GrumpyDoctor posted:This is the succinct description of D that I've been looking for. I'm still disappointed about D. I was disappointed about D, but then I found Scala and Go and forgot all about it. 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. Holy poo poo what I knew you could assign member functions to function pointers in D, but I kind of assumed that what you actually got would be a closure over the object the function was copied from.
|
# ? Sep 11, 2012 23:25 |
|
If you grab it from an object, you do, I was taking it from the class in the example I posted. I can kinda see what they wanted to use that for, but C++ actually engaged that problem with their pointers-to-member while D just throws even more type-safety away because pointers-to-member are clearly too clunky, I guess.
|
# ? Sep 12, 2012 00:13 |
|
Vanadium posted:http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft Same guy trashed linked lists in his next post. I'm a newbie regarding that but what's the general opinion of this thread, is he right? Linking directly in the object (intrusive lists) is preferred to using linked lists? EDIT: Eh, he's also trashing Boost, since we're talking about it. quote:If you read the source code, I hope you’ll find it straightforward. For a start, the entire instrusive linked-list, including the comments and MIT license, clocks in at under 500 lines. Senso fucked around with this message at 09:22 on Sep 12, 2012 |
# ? Sep 12, 2012 09:14 |
|
Senso posted:Same guy trashed linked lists in his next post. I'm a newbie regarding that but what's the general opinion of this thread, is he right? Linking directly in the object (intrusive lists) is preferred to using linked lists? He's right if you're really worried about performance. Less pointers in your data structures = better data locality = better cache performance and simpler serialization. But if you're not writing something performance-critical you don't need to worry about that.
|
# ? Sep 12, 2012 09:31 |
|
Intrusive lists are great if you want to avoid allocations while maintaining a collection. Since allocations are kind of pricy regardless of memory latency, this makes them pretty good on "slow" hardware where the memory latency is low and so the indirection matters less. As well as the obvious use case of writing the thing that manages the memory, of course.
|
# ? Sep 12, 2012 09:48 |
|
WTF. My intrusive list types generally run 50 lines.
|
# ? Sep 12, 2012 11:54 |
|
shrughes posted:WTF. My intrusive list types generally run 50 lines.
|
# ? Sep 12, 2012 13:07 |
|
omeg posted:He's right if you're really worried about performance. Less pointers in your data structures = better data locality = better cache performance and simpler serialization. But if you're not writing something performance-critical you don't need to worry about that.
|
# ? Sep 12, 2012 13:17 |
|
leper khan posted:If you're not writing something performance-critical should you be using C++? I thought that was the only reason anyone still bothered with it (outside legacy). There are different levels of performance required.
|
# ? Sep 12, 2012 13:20 |
|
C++ is also a better language than Java, C#, et al, without taking into account performance.Sagacity posted:But then, you are a programming messiah. Actually it runs around more like 80 lines. It could potentially balloon to 90 if I ever need to iterate the thing without consuming it. Mine is designed to make nodes inherit from a base class though, so it's a bit different, you'd need some ugly inheritance to get an object into two lists at once. I'll have to write a non-base-class version though to see how that works out. shrughes fucked around with this message at 13:40 on Sep 12, 2012 |
# ? Sep 12, 2012 13:29 |
|
Hibame posted: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 This code is familiar to me. Is there a BooleanFormatter class lurking in that codebase? Also, D. Man that language is annoying, I want some of its features so bad, but the language is terrible. Strings are arrays of const chars that are also ranges over unicode codepoints encoded in unicode in the array. The only way it seems possible to run the built in unit tests is to actually run your program, you can't just compile test runner binary (that I could find anyway). There's loads of mysterious poo poo in there to trip you up, the language feels like it's made of the frustrations of C++ programmers who couldn't get their ideas for the language past the committee.
|
# ? Sep 12, 2012 14:54 |
|
shrughes posted:Actually it runs around more like 80 lines. It could potentially balloon to 90 if I ever need to iterate the thing without consuming it. Can you share that or it's proprietary? I'm interested in seeing the different implementation since I'm just starting reading up on that.
|
# ? Sep 12, 2012 16:07 |
|
Senso posted:Same guy trashed linked lists in his next post. I'm a newbie regarding that but what's the general opinion of this thread, is he right? Linking directly in the object (intrusive lists) is preferred to using linked lists? Like anything else, you weigh your options. Lots of types (containers, smart pointers, etc.) may be implemented intrusively, with varying benefits. If you are dealing with value types, a std::list is often a better choice and is easier to reason about. Throwing down your fist and saying that users should always prefer intrusive over non-intrusive containers is ridiculous and at the very least forces people to intrusively alter their types simply because of the containers they may be stored in when it may not even be worthwhile, and it forces you to change your types if you simply change where/how they are stored. Also, a fair amount of what he says is not entirely true: Patrick Wyatt posted:Here is code that safely removes a person record from the linked list: Second, his comment that it forces people to write "list-removal" functions such as the one he wrote out above are completely not true. Despite deciding that std::list is universally bad, he apparently doesn't even know the STL well enough to realize that std::list has a function for removal (imagine that) and it's called, unsurprisingly, "remove." You just have to write your_list.remove( your_person ); You don't have to manually write a search as he explicitly claims and cites as a reason why his intrusive list is "better" than std::list. Third, but admittedly on somewhat of a tangent, in cases like these, very often people mistakenly choose a std::list over something like a std::vector simply because they want constant time removal from the container. There are a couple issues here. First, you can remove items from a vector in constant time, it just alters the stored order and potentially invalidates an iterator -- you do so by swapping the element you want to remove with the one in the back and then pop_back. Second, if you are dealing with something like a container of pointers (or really anything that is trivially movable), as is in the example, erasing something from the middle can generally just be a memmove on the chunk of data that appears after the removed element anyway, and will even preserve storage order. It's also important to note that neither of these operations will require a call to your allocator's deallocation function, unlike when using a std::list, since in the list case, a node has to be deleted. For small lists, it's unlikely the difference between the constant-time erasure and the erasure from the middle of a vector of trivially-movable types, such as pointers, is significant at all, and depending on a number of variables including the size of the container, how allocation/deallocation is performed, and where your list nodes happen to be in memory in relation to one another, the vector erase may end up being faster, even if you don't use the swap trick. Finally, linked lists provide constant removal, but iteration over them is potentially much slower and not cache-friendly. If you are iterating over the list frequently (I.E. every frame, or almost every frame), but are removing things from the list only on occasion (I.E. when an object moves from one sector to another, or when an item is removed from inventory or a selection list, etc.), you should probably be valuing fast iteration a lot more than fast removal (though in those cases, neither would likely be a bottleneck anyway). Anyway, the point is, you always need to weigh your options. The differences between std::list, intrusive lists (whatever implementation you choose), std::vectors, and any container are trade-offs. One is not universally better than another. Senso posted:EDIT: Eh, he's also trashing Boost, since we're talking about it. Edit: shrughes posted:Actually it runs around more like 80 lines. It could potentially balloon to 90 if I ever need to iterate the thing without consuming it. Or, you could just use a peer-reviewed, efficient, tested, open source solution that people already know instead of making your own intrusive container, apparently for at least the second time, programming messiah. *cough* That Turkey Story fucked around with this message at 22:58 on Sep 12, 2012 |
# ? Sep 12, 2012 18:15 |
|
e: you know what, never mind. Not a productive post.
raminasi fucked around with this message at 19:19 on Sep 12, 2012 |
# ? Sep 12, 2012 18:16 |
|
GrumpyDoctor posted:I know I really shouldn't bite on this, but what the gently caress Let it go. I thought the same thing, but it's not going to be a constructive discussion.
|
# ? Sep 12, 2012 18:18 |
|
Vanadium posted:I'd like to suggest that the D motto is "Those who cannot learn from history are doomed to repeat it" but I can't really argue against the combined Walter Bright and Andrei Alexandrescu C++ learnin'.
|
# ? Sep 12, 2012 23:06 |
|
Vanadium posted:I'd like to suggest that the D motto is "Those who cannot learn from history are doomed to repeat it" but I can't really argue against the combined Walter Bright and Andrei Alexandrescu C++ learnin'.
|
# ? Sep 13, 2012 02:47 |
|
Senso posted:Same guy trashed linked lists in his next post. I'm a newbie regarding that but what's the general opinion of this thread, is he right? Linking directly in the object (intrusive lists) is preferred to using linked lists? What a nonsense post. Part one was intriguing, but this is just a mess. My three favorite things about it: a) purports to explain how to avoid game crashes while concerning itself exclusively with performance; b) goes out of its way to point out that the author did not invent the concept of a linked list without seperate container objects, like, no poo poo, sherlock; and c) advocates hand-rolled code as less susceptible to bugs than standard libraries.
|
# ? Sep 13, 2012 04:50 |
|
HORATIO HORNBLOWER posted:What a nonsense post. Part one was intriguing, but this is just a mess. My three favorite things about it: a) purports to explain how to avoid game crashes while concerning itself exclusively with performance; b) goes out of its way to point out that the author did not invent the concept of a linked list without seperate container objects, like, no poo poo, sherlock; and c) advocates hand-rolled code as less susceptible to bugs than standard libraries. C) is what really gets me more than anything else and it happens with tons of programmers. How big of an ego do you have to have to think that something you write ad-hoc for a project is going to have fewer bugs, be better designed, and be less buggy than a standard or open-source solution put together by one or more people who have devoted their time explicitly to it, usually with plenty of tests and other people using it, improving it, and potentially finding bugs. This is true even, if not especially, for something trivial -- I say especially for something trivial only because there are probably fewer potential trade-offs that could actually make a difference for a project. Anyway, if the code really is so trivial that you could write it in an hour or two and be relatively convinced of its correctness, why would you spend any time making it at all, particularly with even the slightest chance that you may mess something subtle up. For something so trivial, there are probably plenty of already-written, known alternatives, that other people are aware of. What are you gaining by reinventing the wheel? Even if it just takes an hour, devote that hour to whatever specific task you are trying to accomplish, not some mundane little algorithm or datastructure.
|
# ? Sep 13, 2012 05:16 |
|
That Turkey Story posted:C) is what really gets me more than anything else and it happens with tons of programmers. How big of an ego do you have to have to think that something you write ad-hoc for a project is going to have fewer bugs, be better designed, and be less buggy than a standard or open-source solution put together by one or more people who have devoted their time explicitly to it, usually with plenty of tests and other people using it, improving it, and potentially finding bugs. This is true even, if not especially, for something trivial -- I say especially for something trivial only because there are probably fewer potential trade-offs that could actually make a difference for a project. Some individuals / organizations have an insane sense of pride that all of their software uses no third-party code. I interviewed at a place like that; they weren't amused when I suggested that they implement their own operating systems, web servers, and database servers to be truly 100% in-house.
|
# ? Sep 13, 2012 05:21 |
|
HORATIO HORNBLOWER posted:c) advocates hand-rolled code as less susceptible to bugs than standard libraries. Well, it's the use of hand-rolled code that can be less susceptible to bugs (if it has a simpler API or application-specific assertions or something). It's the hand-rolled code itself that is usually more susceptible to bugs. Especially the way that blog poster writes his code. (The hand-rolled code can be less susceptible to bugs if it's just a better written implementation, which you're not likely to see for Boost libs but you are likely to see for, well, a lot of libraries out there.)
|
# ? Sep 13, 2012 05:22 |
|
Ithaqua posted:Some individuals / organizations have an insane sense of pride that all of their software uses no third-party code. I interviewed at a place like that; they weren't amused when I suggested that they implement their own operating systems, web servers, and database servers to be truly 100% in-house.
|
# ? Sep 13, 2012 05:39 |
|
I can see someone spending days tracking a bug and finding it in e.g. some goofy embedded implementation of stl and expanding that lovely experience to decree "all implementations of stl on all compilers on all architectures are buggy pieces of poo poo". Hell, if that happens badly for ten consecutive third-party libraries you try to use I can see the general wariness of all code by others. Doesn't mean it makes any sense for productivity, happiness, or even correctness, but I can empathize.
|
# ? Sep 13, 2012 06:49 |
|
Zombywuf posted:The only way it seems possible to run the built in unit tests is to actually run your program, you can't just compile test runner binary (that I could find anyway). Replace your main() with this: code:
|
# ? Sep 13, 2012 08:17 |
|
pokeyman posted:I can see someone spending days tracking a bug and finding it in e.g. some goofy embedded implementation of stl and expanding that lovely experience to decree "all implementations of stl on all compilers on all architectures are buggy pieces of poo poo".
|
# ? Sep 13, 2012 12:23 |
|
TheSkeletonMan posted:Replace your main() with this: And that is D in a nutshell. Why can't we have nice things damnit.
|
# ? Sep 13, 2012 12:37 |
|
pokeyman posted:I can see someone spending days tracking a bug and finding it in e.g. some goofy embedded implementation of stl and expanding that lovely experience to decree "all implementations of stl on all compilers on all architectures are buggy pieces of poo poo".
|
# ? Sep 13, 2012 12:44 |
|
|
# ? Jun 3, 2024 21:53 |
|
pokeyman posted:I can see someone spending days tracking a bug and finding it in e.g. some goofy embedded implementation of stl and expanding that lovely experience to decree "all implementations of stl on all compilers on all architectures are buggy pieces of poo poo". That's why I always look for unit tests in third-party code I download. If it's not there, I write tests for at least the aspects I'm interested in using. Case in point, I found a library to generate USPS barcodes for mail tracking purposes. I converted the USPS's provided test cases to unit tests and found several bugs.
|
# ? Sep 13, 2012 14:00 |