• I dunno LOL ¯\(°_o)/¯ (unregistered) 
    enum TDWTFCommentType 
{
  [helpstring("Unknown comment type.")] UnknownCommentType = 0, 
  [helpstring("Frist comment.")] FristComment = 1,
  [helpstring("Second comment.")] SecondComment = 2,
};
  • (nodebb)

    Networks are complex beasts, and as they grow, they get more complicated.

    That's for sure. Back when, my own network was two Windows 9x PCs linked by a four-port 10-base-T hub, with two humans using those PCs. Now it's one human (Mrs Cynic has been the late Mrs Cynic since 2015...), three fixed PCs, one laptop linked by 1000-base-T to the rest, one WiFi access point, one laptop linked to the access point's WiFi, one UTM firewall, two five port gigE switches, two Raspberry Pi 3B+ (one being an Active Directory Domain Controller), several iThings, a printer, a Wii U, and a routerbox provided by my ISP.

    In the case of IniTech’s product, the lowest level of data acquisition is frequently sampled voltage measurements over time. And it’s a lot of samples- depending on the protocol in question, it might need samples on the order of nanoseconds.

    Hundreds, maybe tens, of picoseconds, more likely. Measuring voltages (of the network itself) on a multi-nanosecond basis in gigabit networks is mostly futile.

  • Prime Mover (unregistered)

    I don't really see a WTF here. It's a tiny bit of leftover cruft from a fairly prudent and sensible design decision made when the initial design was shaping up. If I were reviewing the code, I'd leave it as it is as a matter of course. Nothing here is broken, nothing needs to be fixed.

  • akozakie (unregistered)

    Definitely a candidate for cleanup in case of a serious refactoring campaign, but not really a wtf. We've done worse in early stages of design of systems we didn't fully understand until they went at least partially live.

  • p (unregistered)

    Hmm. I just did the same thing yesterday in my app.

    The thing is, sometimes you need to create a field or variable of the enum type and set the value later. And unless you have nullable enums, it will be initialized to the default value. If you then (because bugs) fail to actually set the real value correctly as you intended, it will remain at the default value – and it's much better to have the default value be a clearly invalid (detectable) value than a valid but undetectably wrong value.

    Am I wrong about this? What should you do instead?

  • MiserableOldGit (unregistered)

    Surely the real WTF is that the data consuming components aren't capable of dealing with data flagged as "unknown" without crashing? Granted the OP says there is never "unknown" data in this implementation, but this is the sort of case else scenario I routinely add with a line to log, or raise an error or whatever is appropriate if we find ourselves in that branch. It's a rare thing that the functional spec accurate describes what will actually be flung in and out of the program once it's running, they just got lucky. Maybe it could be deleted from what gets shipped but, honestly, if that's the biggest thing they have to worry about then they really are lucky.

    Well, and they forgot

    helpstring("FileNotFound data")] FileNotFoundData = 3
  • Brian (unregistered)

    Unnecessarily complex event systems aside, I'd have a hard time classifying this as a WTF. For an enum that's likely to grow over time, as one might expect of an event system, it's certainly not out of the ordinary to have a default "invalid" value. And having that default be 0 is a sensible choice, whether you're dealing with a language that auto-initializes object properties or you're using memset in C++ to do the same thing.

  • (nodebb)

    No WTF to kme... The enum has been well explained (especially unitialized). The dual events allow for options not possible with a single event. As a potential example, there may be some preliminary processing that can be done on the "primary" before being combined with the "secondary. These could even be happening on different threads.

  • Foo AKA Fooo (unregistered) in reply to Brian

    Using memset in (slightly modern) C++, that would be a WTF.

  • (nodebb) in reply to MiserableOldGit

    Ideally, if the components are written in the same language, the compiler should make it impossible to pass anything that is not in the enum, so they shouldn't have to be capable of handling unexpected values there. Or at least this would be true, if the enum didn't contain the "UnknownDataType" entry.

  • (nodebb) in reply to R3D3

    Most languages allow you to cast an enum to/from the corresponding primitive. Unfortunately, many programmers use this way too much - to the point of the compiler probably not picking up on many bugs.

    At the end of the day, the protection comes from "professional programmers using enums properly", not "declaring a variable of enum type".

  • Naomi (unregistered) in reply to Jaime

    Mhm! In Java at least, you can convert an enum constant to an integer by calling ordinal(), but the conversion backwards is just a little bit more involved (so you can't really do it by accident), and does bounds checking along the way. I wouldn't be surprised if it's like that in C-Pound as well.

  • (nodebb) in reply to Foo AKA Fooo

    Using memset in (slightly modern) C++, that would be a WTF.

    Using memset(this,0,sizeof(*this)) in any version of C++ which includes virtual member functions or virtual inheritance or automatic construction of member objects or automatic construction of base classes (i.e. any version of C++, even the very first) is a short route to death in a nuclear fireball.(1)

    Using memset to clear out a POD type is possible, although fraught with its own amusement potential, since doing that to the memory containing an ordinary pointer does not set it to NULL / nullptr. (On most platforms, it works by coincidence, but on AS/400, now known as iSystem, the all-zeroes bit-pattern is not NULL.)

    (1) Sadly, the pages about the DeathStation 9000 are no longer with us(2), but they featured many photos of nuclear explosions as examples of the consequences of invoking the nasal demons of Undefined Behaviour.

    (2) The closest you can get is https://web.archive.org/web/20140208152223/http://dspace.dial.pipex.com/town/green/gfd34/art/

  • WTFGuy (unregistered)

    @Naomi .Net doesn't have much in the way of guardrails for misuse of enums. An enum is much closer to a declaration of an int32 and a c-style set of named macros for some magic values. See https://docs.microsoft.com/en-us/dotnet/api/system.enum?view=netcore-3.1 for the official word

    public enum Status {Invalid, Good, Bad, Ugly}; // by default the underlying values are 0..3; they can be declared explicitly if desired
public DoSomething( int x, Status someStatus) {...}

Status myStatusValue = Status.Good ;  // sets = 2
int StatInt = (int)myStatusValue ; // sets = 2
Status bogusStatus = (Status)42 ; // sets =42 ; no compiler protection.
bool validity = Enum.IsDefined( typeof(Status), BogusStatus) ; // sets = false
DoSomething(12, myStatusValue) ; // works as expected, passes 12 & 2
DoSomething(12, bogusStatus) ; // passes 12 & 42. No compiler protection; DoSomething() needs defensive coding for unexpected values.
  • MiserableOldGit (unregistered) in reply to R3D3
    Ideally, if the components are written in the same language, the compiler should make it impossible to pass anything that is not in the enum, so they shouldn't have to be capable of handling unexpected values there. Or at least this would be true, if the enum didn't contain the "UnknownDataType" entry.

    I don't see the issue. Even if we are crossing a language barrier we are still directing the feed into an if or switch statement to determine where the data flows (throw this garbage away, primary, secondary or "oh my gawd, pants on fire"). Unless that receiving component has been very sloppily written that unknown enum, or indeed, any unexpected value in that parameter should not be causing a hard crash. The extra case allows the receiving component to distinguish between chaos the sender is OK with and some more fundamental chaos. At worst, unnecessary.

  • jeremy (unregistered)

    Am i missing something here? An event producer prouces two events to send some data. The data consumers always need both events to get the complete data Why isn't it one event? I imagine it could make life a lot easier. If the event size is a concern maybe there is more inuitive way to split the data over multiple events in a scalable way

  • enum WTF { Unknown, Frist, FILE_NOT_FOUND } (unregistered)

    This doesn't really seem like a WTF to me - unnecessary, maybe, although having different events for primary and secondary data seems like a good idea. In fact the WTF there is the two events always being fired together, surely the primary sample data should be fired more frequently?

    Having an 'unknown' value on enums is not a bad idea, and if you're interacting with an unmanaged language where uninitialised variables are blanked to 0, having the unknown value as 0 is a good choice.

  • (nodebb) in reply to Steve_The_Cynic

    (Mrs Cynic has been the late Mrs Cynic since 2015...)

    :-(

  • Damp Old Runt (unregistered)

    Give me a login to your source control system. I'll delete the unused enum for you.

  • Faded (unregistered)

    I wrote a scheduling system a few years ago. After I got it working and brought on line I looked at what I had done. I realized that now I had finished the thing I had learned how to created a scheduling system. Based on what I learned I figured out almost everything I had done was a best inefficient and sometime just a wrong approach to the problem. I understand Leonore's predicament completely. She shows great virtue because she can admit there is a problem. The real lesson here is that we all need to be more like Leonore.

  • Ahahaha (unregistered)

    TRWTF is Remy uses FagOS (found in HTML comments)

  • (nodebb) in reply to Ahahaha

    I'm afraid you may be in the wrong forum. We don't do homophobia here.

  • (nodebb)

    I know this is probably a contentious issue, but I still stand by defining an invalid Enum value for zero (or uninitialized), as it catches cases where people don't initialize it, and stops the "default" case from being cast to something, and garbage, or all zeros from being interpreted as a valid message, struct, object, etc.

    Some people I work with like it, others hate it. What's the prevailing opinion here?

Leave a comment on “Unknown Purpose”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article