Author Topic: Windows - Command line and Dialog driven command  (Read 26401 times)

0 Members and 1 Guest are viewing this topic.

TonyT

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #60 on: October 06, 2008, 12:43:38 PM »
...and Dan's disassembly shows, that in this case, using 'Compare' would be a more expensive operation than just using the overloaded operator >, as it just compares the internal long values...

Hi Glenn. 

I've learned the hard way, that Reflector's disassembly doesn't always tell the true story.

It quite often generates code that's deliberately verbose and seemingly inefficient, mainly for the sake of readability. The most common example is generating code that uses IEnumerable directly, where the original source code may have used foreach(). Hence, it can also often involve using variables where the original source may not have, and is actually more efficient.

I suppose that since we can look at much of the framework source code now, that might offer a more definitive answer.



Hey Tony,

I realise that reflector can be verbose, but not that verbose. In future I'll treat it with a grain of salt I suppose. Nice reminder about the framework source - I will have to investigate it further.

Cheers,
Glenn.

I've also found that as part of optimization, the runtime is free to eliminate local variables.


TonyT

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #61 on: October 06, 2008, 07:37:21 PM »
...and Dan's disassembly shows, that in this case, using 'Compare' would be a more expensive operation than just using the overloaded operator >, as it just compares the internal long values...

Oops..

Sorry. Compare() and the > operator are not equvialents so that isn't Reflector mucking things up.

Obviously, Compare() answers two questions, while > only answers one question.

That also brings up the issue in the other branch of this thread, where my advice that one should always use operators if available was called into question.

For DateTime, there is no method that does the equivalent of the > operator.


MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Windows - Command line and Dialog driven command
« Reply #62 on: October 06, 2008, 09:34:35 PM »
I'm thinking some here are confusing back ups with version control, these are two different subjects all together, a back up is a 'copy' of the master so if you want to back up your master file, whether it's not the master in your project or not say is irrelevant here, comparing time stamps is surely good enough. If your updating your source for version control that's different.

Regardless of language, if you want any operator to work as expected you need to overload it for 'your' type else your stuck with the basic virtual method/s of the base class. You probably can use the operator without any trouble in most oop languages but don't always except it work how you'd expect!

As I mentioned before, it's only syntactical sugar and should be treated as such, if you are creating your own types and you want the end user to 'feel at home' using the best concepts that oop offers you really need to do the extra work and overload all the operators that make sense for the type.

OOP saves time when using re-useable libraries (automation for example) but writing the lib's for proper re-use is a lot more work and takes the 'easy' part out of oop.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: Windows - Command line and Dialog driven command
« Reply #63 on: October 06, 2008, 09:41:11 PM »
Regardless of language, if you want any operator to work as expected you need to overload it for 'your' type else your stuck with the basic virtual method/s of the base class. You probably can use the operator without any trouble in most oop languages but don't always except it work how you'd expect!

As I mentioned before, it's only syntactical sugar and should be treated as such, if you are creating your own types and you want the end user to 'feel at home' using the best concepts that oop offers you really need to do the extra work and overload all the operators that make sense for the type.
Which I never argued otherwise.

T. Willey:  As for having a command line & GUI version, you should be able to implement each with the same code in the rest of your project.  There should actually only be a different UI module, both should be able to implement the rest of your code.

TonyT

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #64 on: October 07, 2008, 02:45:44 AM »
.. In most cases in OOP languages, using == to compare two Strings is absolutely wrong...

This is not correct, in OOP, an object should know how to compare itself to another object of the same type AND provide an operator to do so
I.e  the operator == in .NET, System.String just calls a method Equals




  In Java, == tests whether the two strings point at the same object.  You may want to tell Sun that Java isn't OOP :wink:


Perhaps you didn't know that Java does not support overloading of operators?

No, in my book that's not modern oop.

Perhaps the fact that Java is missing such an important feature that even Python has, also has something to do with the fact that Java applications have one of the highest failure rates amongst most higher-level languages, and when considering all languages, is bested only by C++ and Fortan.

    http://onthethought.blogspot.com/2004/11/java-and-operator-overloading.html

Gotta confess, I had a really good laugh when I realized you were citing an example from a programming languauge that does not even support operator overloading, in support of an argument that a compiler does *not* need to throw an error if an operator is not overloaded for a given type.

:lmao:

I think you've just been 'outted' friend.  


« Last Edit: October 07, 2008, 02:53:18 AM by TonyT »

tjr

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #65 on: October 07, 2008, 10:31:53 AM »
I'm thinking some here are confusing back ups with version control, these are two different subjects all together, a back up is a 'copy' of the master so if you want to back up your master file, whether it's not the master in your project or not say is irrelevant here, comparing time stamps is surely good enough. If your updating your source for version control that's different.

Mick:

Comparing time stamps for backups is not good enough for anything because as I've stated before comparing time stamps allows for the "backup" file to be a newer, but wrong, version of a file. This has nothing to do with version control.

To prove my point create two folders somewhere on your computer named "master" and "backup". Drop some files in the "master" directory and run Tim's routine to backup the files from "master" to "backup", which should work quite well. Now go in the "backup" directory, open a file, erase something, save it and go run Tim's program again. How well does that work out? Not well I'm going to assume as his program is only checking if the file in the "master" directory is newer than of that in the "backup" directory, which is 100% the wrong way to do it as I've just proven.

If you think to yourself "well that's stupid because no one will ever be able to access my backup folder other than me so they won't be able to change the file". This again is the wrong assumption. To prove my point open a file in a text editor, even if it's binary, and add "q" somewhere in the file. This would be a representation of a corrupt file in which the backup method would fail.

This is not a version control method but a method of verifying file integrity. Ensuring that your backup is exactly that, a backup, not just the most recently edited version of a file. Tim's code may work flawlessly until the end of time, but one day he may go reaching for a backup file and find out he's screwed.

This is the exact reason that a lot of open source software offers a checksum along with their downloads, so you can verify that the file you obtained is exactly what they intended to provide as a download. Open Source is not all hippies and beards, there  are a lot of smart people hacking away at different things and a lot can be learned from observing them.

Note: The last paragraph was not directed at you as I know you follow a lot of open source stuff, it was merely a general statement directed towards those who live in their own little coding world without doing some exploration.

Glenn R

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #66 on: October 07, 2008, 10:38:07 AM »
So Tim, are you saying Mick is not smart or not a hippie with a beard? :evil:

tjr

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #67 on: October 07, 2008, 10:45:39 AM »
No, that's why I included the note at the end.  :)

I'd consider Mick one the sharper people I've come across in my days. Much sharper than I.

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8662
  • AKA Daniel
Re: Windows - Command line and Dialog driven command
« Reply #68 on: October 07, 2008, 11:16:14 AM »
I just don’t believe it… Mick post a pick of yourself  :lol:

T.Willey

  • Needs a day job
  • Posts: 5251
Re: Windows - Command line and Dialog driven command
« Reply #69 on: October 07, 2008, 11:27:43 AM »
T. Willey:  As for having a command line & GUI version, you should be able to implement each with the same code in the rest of your project.  There should actually only be a different UI module, both should be able to implement the rest of your code.
I did get it to work with the same code, just calling it in different ways.  I check to see if they are any arguments, and if so, do the command line ( I need to get used to saying console, instead of command line when not talking about Acad code ) version, if not do the dialog version.
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

Glenn R

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #70 on: October 07, 2008, 11:31:43 AM »
I just don’t believe it… Mick post a pick of yourself  :lol:

Yeah, I always thought he was pretty blunt myself ;)

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
Re: Windows - Command line and Dialog driven command
« Reply #71 on: October 07, 2008, 04:49:05 PM »
Ok, at the risk of getting further off topic, to myself at least a back up is just somewhere to store temp/permanent copies of something you're working on in case of some disaster, like a .bak file in autocad, you never use it as a rule unless something goes wrong, it's that simple. Why would you use a back up file if you have the original which is the one you're working on anyway?
Is this is a problem there are some serious issues in the production process in that office, its' not that hard to lay down some basic rules, if the worker involved doesn't comply it's adios!

hmmm, I may have some hippy tendencies but that's probably due to my 'biker' history (you know, wild and free (and often anebriated :roll:)), I do at times sport a goatee but that's about it :)
Cheers.
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien