pokeyman posted:

Found this in the PHP manual. It's like the guy knew he wanted some kind of conditional execution, but forgot about the "if" keyword.

code:

switch (TRUE)
{
 case ($phlen < 7):
   $ext = $ph;
   break;
 case ($phlen == 7):
   sscanf($ph, "%3s%4s", $pfx, $exc);
   break;
 case ($phlen > 7 AND $phlen < 10):
   sscanf($ph, "%3s%4s%s", $pfx, $exc, $ext);
   break;
 case ($phlen == 10):
   sscanf($ph, "%3s%3s%4s", $area, $pfx, $exc);
   break;
 case ($phlen == 11):
   sscanf($ph, "%1s%3s%3s%4s", $cty, $area, $pfx, $exc);
   break;
 case ($phlen > 11):
   sscanf($ph, "%1s%3s%3s%4s%s", $cty, $area, $pfx, $exc, $ext);
   break;
}

tef posted:

If we're going into unicode territory how about something like ∀ x ∈ l : print x; perhaps?

Kidane posted:

While I am paid to write Perl, I am by no means an expert. However, I'm of the opinion that there is nothing inherent to Perl which requires overly-concise code.

more falafel please posted:

It's better than

code:

if(something){
  DoWork();
^^ TWO loving SPACES EVEN THOUGH THE REST OF THE PROJECT USES TABS
}else{
  DoOtherWork();
}

more falafel please posted:

That's the problem -- I'm stuck doing that (well, gg=G, but same difference). This code is five years old, and full of crap like this -- defining log macros badly so they need double parentheses, bizarro mixes of Systems Hungarian, CamelCase, camelCase, and under_score_words, depending on this guy's mood that month, static members called m_ivpFoo (instance variable). And of course design problems -- the initializer list for one class's ctor is 124 lines long.

quote:

The problem of course is that there's never time -- it's always crunch.

dwazegek posted:

No, extension methods are pretty much just syntactic sugar for a call to a method in a referenced static class.

code:

public static class SomeClass
{
  public static bool IsNullOrEmpty(this string s)
  {
    return string.IsNullOrEmpty(s);
  }
}

//these two calls are the same:
s.IsStringNullOrEmpty();
SomeClass.IsNullOrEmpty(s);

Since you're not actually calling an instance method of "s", but actually passing it as the first parameter to an extension method, it doesn't matter if it's null or not.

rotor posted:

I don't understand how this is supposed to be especially awful for what is, I assume, supposed to be an in-class example or something.

narbsy posted:

if you're doing an in-class example and want to make sure everyone knows what you're doing... then this is better than a for loop due to clarity, at least in my opinion.

atomic johnson posted:

Christ... everybody knows the way to do this is to make them all prime numbers so that you can just factor the resulting number to get the options that were selected.

chocojosh posted:

Wouldn't the correct solution be to use a bitmask? Define each enum value to 2^i (i = 0,1,2,...,n) and then just check if the relevant is set?

Flobbster posted:

And to stroke my e-penis a little, code like what I just wrote above pisses me off. It should be

code:

for(size_t i = 0; i < str.length(); i++)

TSDK posted:

It seems to me then that there were 3 WTFs:

1) Relying on specific, non-guaranteed behaviour from uninitialised memory.
2) Knowing that you get specific warnings about sections of code and failing to comment them appropriately.
3) Making a change to some code you don't fully understand without getting in touch with either the original author, or someone who could explain why it's doing what it is.

If you ask me, then the original OpenSSL devs are just as much to blame for that clusterfuck as the guy who put in an incorrect 'fix' for the problem.

tef posted:

Perl had the nice thing of goto &function which was occasionally useful, and also allowed you to label loops so you could do break LOOP_NAME

Tetrad posted:

He was literally getting an int out of this class where the address of an int would be in some other class.

quote:

Also a header for a function I wrote when I was in my "templates and boost are awesome" phase (which I'm still in).

code:

template< typename VALUE_TYPE >
void AddValue( const std::string& key, VALUE_TYPE* value, boost::function< bool( typename boost::call_traits< VALUE_TYPE >::param_type ) > validationFunc, bool isRequired );

_aaron posted:

No, see, this is great, because then you can do things like:

code:

string boolString = BooleanFormatter.Format(true, "false", "true");
MessageBox.Show(true.ToString() + " is " + boolString);

You don't see the utility here!? Not to mention the deep philosophical implications of subjectively defining "true" and "false"...

Munkeymon posted:

Actually, if this:

code:

IF WS-OPT = 'P' OR 'L'

does what it looks like it does, then that's kind of nice, actually. Explicitly writing out things like if(something == A || something == F) always kind of bugged me for some reason.

Habnabit posted:

But except: pass makes me want to strangle people.

Habnabit posted:

Sure, let's go ahead and swallow SystemExit, MemoryError, and KeyboardInterrupt.

Scaevolus posted:

But it makes sense to handle trapped signals as exceptions-- would you rather there was a different language construct specifically for those sorts of interrupts?

tef posted:

If you do this in our codebase I will nail your hands to the toilet.

If you don't care if it fails, you should be explicit in the failures to ignore.

Habnabit posted:

My whole point is you never, ever want to ignore everything. Again, what if a MemoryError is raised? You really want to ignore when there's no memory available, when something higher up the stack could free some memory?

quote:

When a signal comes in, python interrupts the currently executing stack frame and pushes a new stack frame with the python signal handler function. This function is passed the interrupted stack frame as well. If you have a better idea of how to do this in an interpreted language, I'd love to hear it.

Habnabit posted:

However, a C extension or python itself can deal with it.

quote:

I don't think you understand how exceptions work. The exception is not the error; the exception is a signal of an error condition. Discarding the exception does not make the error itself go away. If you can't deal with the error condition, don't pretend you can.

quote:

I have no idea what "escape signal handlers" means here. And, again, I urge you to explain how this could be dealt with in a cleaner way.

quote:

Same thing here. How else would you do this? Python is not php; these things have been thought out carefully, and this was found to be the optimal solution. You seem to think these things were slapped together without any forethought, but you also don't seem to have any suggestions on how it could be better implemented.

zootm posted:

Why not? It creates the correct behaviour in the default case in a transparent and understandable way. And if you have some special handler, you can override the default behaviour simply. Sounds like the best of both worlds.

Janin posted:

"Out of memory" conditions.

Python docs posted:

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C's malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

quote:

That would make Python signal handlers pretty useless, since they wouldn't be able to manipulate the execution state except through global C variables.

quote:

What would get_next() do when there's no more data to be retrieved, if not raise an exception? In a case like this:

code:

while (mygen.has_more()) { do_stuff(mygen.get_next()); }
mygen.get_next();

Charles Babbage posted:

On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

quote:

e: Also, it's impossible to implement has_more() for a function-based generator.

quote:

To handle other signals, the programmer just needs to install a signal handler. That handler can do whatever it wants, including raising an exception.

Habnabit posted:

No, I never said that. You seem to be so adamant that this not the best way to do it, without considering that there might be a reason why it is that way or providing an alternate implementation.

quote:

For something like using SIGHUP to reload config files, you can take advantage of the suspended state of the program and update the configuration from within the signal handler. Of course, you'd have to write your code in a way to prevent reloading from a signal handler from interfering with things while you're in the middle of getting information from the configuration, but you'd have to do the same in C anyway. You could even just set a flag that the main loop would acknowledge, or post an event, or something.

tef posted:

Janin posted:

If generators do their work in has_next(), then what should happen when they raise an exception? Does it appear from the has_next() call? That's awfully awkward.

The generator is not "making a mess". Many generators have side effects, and it's important that the side effects happen at the prescribed time. I inserted the sys.exit() to prevent arguments about pre-caching results; often, the results themselves are unimportant and it's the side-effects of the generator that matter.

quote:

The issue with using a has_next()/get_next() style is that it's not as general as the current system. Any loop implemented with has/get_next() can be wrapped in a generator, but the converse is not true because the behavior of a generator allows unpredictable results.

Janin posted:

If you want a language with carefully-managed side effect handling, use Haskell. The imperative nature of Python precludes stateless generators.

quote:

You are also ignoring that sys.exit() is just an example of a side effect; it could be anything else. Here's a simple coroutine example;

quote:

how would you implement this using has/get_next()? has_next() wouldn't be able to advance beyond the current point, because the generator requires a value from the yield statement to work.

quote:

Shouldn't that code just use for..in?

quote:

I don't understand what you mean, here. If you mean custom iterables, that's easy to do. If you mean actual custom generator classes, why on earth would you want to?

Vanadium posted:

It worked for lisp

Lone_Strider posted:

code:

--------------------------------------------------------------------------
--Notes:Everytime u run this it will give u a new id so it can be used anywhere to
--get a unique ID for you Inserts,....
--Changes on:  Change Flag:
---------------------------------------------------------------------------------
ALTER  PROCEDURE [dbo].[spSelect_NextID]
as

SET NOCOUNT ON
 
begin 
 select NextID from dbo.tblNextID
 
 update dbo.tblNextID
 set NextID = NextID + 1 
end 
Return

Auto increment? @@IDENTITY? gently caress outta here with those, we got a key generating table

rjmccall posted:

Language interpreters regularly end up like this, although "large functions" tends to be the least of the craziness. But if you're worried at all about interpreter performance, you really can't afford to make a function call per instruction or AST node.

rjmccall posted:

This is excellent advice for general programming, but it's not so hot for core interpreter loops.

floWenoL posted:

Oh, how cute, it's someone who hasn't ever needed to program for performance!