TheSwamp

Code Red => .NET => Topic started by: T.Willey on September 26, 2008, 12:24:07 PM

Title: Windows - Command line and Dialog driven command
Post by: T.Willey on September 26, 2008, 12:24:07 PM
What would be the best way to set up a routine that I wanted to be driven by the command line, and have a dialog version.  From what I have gathered, it looks like you have to choose one or the other, so would that mean that I would have to just write the code, and then copy the guts of it into the other style?  Thought I would get some other insight.  Thanks.

I'm off to do some more research.
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on September 26, 2008, 01:54:13 PM
More information required. For instance, when you say 'command line', are you talking AutoCAD or system?
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on September 26, 2008, 02:03:20 PM
This will be run outside of Acad.  It is a back-up routine that I'm writting.  I want to be able to call it from the command line, and be able to call it with a GUI.  I was figuring that if I can call it from the command line, then I can run it every night at work to make sure I have the current files to work from.
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on September 26, 2008, 05:33:47 PM
I wrote the code so it could be easily called either way.  I just haven't found a way to do it yet.  I don't want to have a dll that is used by two exe files.  I'm still trying to see what I can find.  Here is the, simple, code.

Code: [Select]
void Back_up ( string toPath, string fromPath ) {
   
    DirectoryInfo tempDi;
   
    if ( string.IsNullOrEmpty( toPath ) ) return;
    if ( string.IsNullOrEmpty( fromPath ) ) return;
   
    int fromDirLen = fromPath.Length;
   
    tempDi = new DirectoryInfo( toPath );
    if ( !tempDi.Exists ) return;
    tempDi = new DirectoryInfo( fromPath );
    if ( !tempDi.Exists ) return;
   
    FileInfo[] FiAr = tempDi.GetFiles(
                                        ( string.IsNullOrEmpty( SchPatTbox.Text ) ? "*.*" : SchPatTbox.Text ),
                                        SearchOption.AllDirectories
                                    );
   
    StringBuilder sb = new StringBuilder( "BackupLog v0.1" );
    sb.AppendLine( System.Environment.NewLine );
    sb.AppendLine( "Legend:" );
    sb.AppendLine( "N- : New file" );
    sb.AppendLine( "O- : Overwrote existing file" );
    sb.AppendLine( "I- : Ignored file");
    sb.AppendLine( System.Environment.NewLine );
    sb.AppendLine( "Begin report:" );
    foreach ( FileInfo fi in FiAr ) {
       
        string tempPath = fi.FullName;
        tempPath = toPath + tempPath.Substring( fromDirLen );
        FileInfo tempFi = new FileInfo( tempPath );
        tempDi = tempFi.Directory;
       
        if ( !tempDi.Exists ) {
            tempDi.Create();
            fi.CopyTo( tempPath );
            sb.AppendLine( "N- " + tempPath );
        }
        else if ( !tempFi.Exists ) {
            fi.CopyTo( tempPath );
            sb.AppendLine( "N- " + tempPath );
        }
        else if ( IsLaterThan( fi.LastWriteTime, tempFi.LastWriteTime ) ) {
            tempFi.Delete();
            fi.CopyTo( tempPath );
            sb.AppendLine( "O- " + tempPath );
        }
        else
            sb.AppendLine( "I- " + tempPath );
    }
    using ( StreamWriter sw = new StreamWriter( toPath + "\\BackUpLog.log" ) ) {
        sw.Write( sb.ToString() );
    }
}

bool IsLaterThan ( DateTime thisDate, DateTime thatDate ) {
   
    if ( !thisDate.Year.Equals( thatDate.Year ) ) {
        if ( thisDate.Year > thatDate.Year )
            return true;
        return false;
    }
   
    if ( !thisDate.Month.Equals( thatDate.Month ) ) {
        if ( thisDate.Month > thatDate.Month )
            return true;
        return false;
    }
   
    if ( !thisDate.Day.Equals( thatDate.Day ) ) {
        if ( thisDate.Day > thatDate.Day )
            return true;
        return false;
    }
   
    if ( !thisDate.Hour.Equals( thatDate.Hour ) ) {
        if ( thisDate.Hour > thatDate.Hour )
            return true;
        return false;
    }
   
    if ( !thisDate.Minute.Equals( thatDate.Minute ) ) {
        if ( thisDate.Minute > thatDate.Minute )
            return true;
        return false;
    }
   
    if ( !thisDate.Second.Equals( thatDate.Second ) ) {
        if ( thisDate.Second > thatDate.Second )
            return true;
        return false;
    }
   
    if ( !thisDate.Millisecond.Equals( thatDate.Millisecond ) ) {
        if ( thisDate.Millisecond > thatDate.Millisecond )
            return true;
        return false;
    }
   
    return false;
}
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on September 29, 2008, 02:52:12 PM
Okay; I got it to work.  I had some coding backwards, so it was coping from the 'to' directory instead of from the 'from' directory.  Here is code ( not the form code, but that could added it wanted ).

Code: [Select]
public static void Back_up ( string fromPath, string toPath, string SrchPat ) {

DirectoryInfo tempDi;

if ( string.IsNullOrEmpty( toPath ) ) return;
if ( string.IsNullOrEmpty( fromPath ) ) return;

int fromDirLen = fromPath.Length;

tempDi = new DirectoryInfo( toPath );
if ( !tempDi.Exists ) return;
tempDi = new DirectoryInfo( fromPath );
if ( !tempDi.Exists ) return;

FileInfo[] FiAr = tempDi.GetFiles( SrchPat, SearchOption.AllDirectories );

StringBuilder sb = new StringBuilder( "BackupLog v0.1" );
sb.AppendLine( System.Environment.NewLine );
sb.AppendLine( "Legend:" );
sb.AppendLine( "N- : New file" );
sb.AppendLine( "O- : Overwrote existing file" );
sb.AppendLine( "I- : Ignored file");
sb.AppendLine( System.Environment.NewLine );
sb.AppendLine( "Begin report:" );
foreach ( FileInfo fi in FiAr ) {

string tempPath = fi.FullName;
tempPath = toPath + tempPath.Substring( fromDirLen );
FileInfo tempFi = new FileInfo( tempPath );
tempDi = tempFi.Directory;

if ( !tempDi.Exists ) {
tempDi.Create();
fi.CopyTo( tempPath );
sb.AppendLine( "N- " + tempPath );
}
else if ( !tempFi.Exists ) {
fi.CopyTo( tempPath );
sb.AppendLine( "N- " + tempPath );
}
else if ( IsLaterThan( fi.LastWriteTime, tempFi.LastWriteTime ) ) {
tempFi.Delete();
fi.CopyTo( tempPath );
sb.AppendLine( "O- " + tempPath );
}
else
sb.AppendLine( "I- " + tempPath );
}
using ( StreamWriter sw = new StreamWriter( toPath + "\\BackUpLog.log" ) ) {
sw.Write( sb.ToString() );
}
}
Code: [Select]
public static bool IsLaterThan ( DateTime thisDate, DateTime thatDate ) {

if ( !thisDate.Year.Equals( thatDate.Year ) ) {
if ( thisDate.Year > thatDate.Year )
return true;
return false;
}

if ( !thisDate.Month.Equals( thatDate.Month ) ) {
if ( thisDate.Month > thatDate.Month )
return true;
return false;
}

if ( !thisDate.Day.Equals( thatDate.Day ) ) {
if ( thisDate.Day > thatDate.Day )
return true;
return false;
}

if ( !thisDate.Hour.Equals( thatDate.Hour ) ) {
if ( thisDate.Hour > thatDate.Hour )
return true;
return false;
}

if ( !thisDate.Minute.Equals( thatDate.Minute ) ) {
if ( thisDate.Minute > thatDate.Minute )
return true;
return false;
}

if ( !thisDate.Second.Equals( thatDate.Second ) ) {
if ( thisDate.Second > thatDate.Second )
return true;
return false;
}

if ( !thisDate.Millisecond.Equals( thatDate.Millisecond ) ) {
if ( thisDate.Millisecond > thatDate.Millisecond )
return true;
return false;
}

return false;
}

And how it knows what to do when its called.
Code: [Select]
switch ( args.Length ) {
case 0:
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
break;
case 2:
MainForm.Back_up( args[0], args[1], "*.*" );
break;
case 3:
MainForm.Back_up( args[0], args[1], args[2] );
break;
default:
Console.WriteLine( "Arguments: <Copy from path> <Copy to path> <Search pattern ( optional )>" );
break;
}
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on September 30, 2008, 06:20:58 PM
Ahh...Tim...what's the purpose of your IsLaterThan() function?
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on September 30, 2008, 06:38:16 PM
Also, have you thought of using xcopy, robocopy or SyncToy 2.0 (http://www.microsoft.com/Downloads/details.aspx?familyid=C26EFA36-98E0-4EE9-A7C5-98D0592D8C52&displaylang=en)?
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on September 30, 2008, 07:15:00 PM
Ahh...Tim...what's the purpose of your IsLaterThan() function?
Just to make sure that the file that is going to be copied over is later than the one that is there now.  If it isn't a newer version, then don't copy it.  This is a one way copy, not syncing.

Also, have you thought of using xcopy, robocopy or SyncToy 2.0 (http://www.microsoft.com/Downloads/details.aspx?familyid=C26EFA36-98E0-4EE9-A7C5-98D0592D8C52&displaylang=en)?
Nope.  I knew there were things out there, but I wanted to see how hard it was to code something up.  Plus I didn't know if there was a dialog version of things, as I didn't search the net for one.  :roll:  I'll have a look at these.  Thanks Glenn.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on September 30, 2008, 11:01:47 PM

Ahh...Tim...what's the purpose of your IsLaterThan() function?

Just to make sure that the file that is going to be copied over is later than the one that is there now.  If it isn't a newer version, then don't copy it.  This is a one way copy, not syncing.


Hi Tim.

I think what Glenn was getting at is, why write a function that is essentially a reinvention of the DateTime's overloaded > (is-greater-than) operator ?

Those who are new to OOP and C# often find themselves reinventing things that already exist, merely because they did not know they were there. So, when one is just starting out, they can probably avoid reinventing many things that already exist if they were to just spend some time becoming more familiar with some of the basic principles and concepts of an OOP language and C# in particular, like operators and operator overloading.

In a nutshell, operator overloading allows a class to supply the code that is used to perform comparisons when instances of the class appear on both sides of a langauge operator like >, ==, <, and so on (e.g., as in 'Today > Yesterday', where Today and Yesterday are both DateTimes).

In other words, all of that code in your IsLaterThan() method is functionally equivalent to this:

Code: [Select]

public bool IsLaterThan( DateTime thisDate, thatDate b )
{
    return thisDate > thatDate;
}


And I think a little common sense allows us to realize that a DateTime is 'later than' another DateTime, if it is greater than the other DateTime.

The > operator overload for the DateTime class simply compares its internal double (which represents the date and time) to the internal double of the other DateTime operand.

Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 01, 2008, 12:27:53 AM
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.
Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 01, 2008, 01:25:37 AM
Those who are new to OOP and C# often find themselves reinventing things that already exist, merely because they did not know they were there. So, when one is just starting out, they can probably avoid reinventing many things that already exist if they were to just spend some time becoming more familiar with some of the basic principles and concepts of an OOP language and C# in particular, like operators and operator overloading.
Logical operators are considered OOP? I submit not.
Title: Re: Windows - Command line and Dialog driven command
Post by: MickD on October 01, 2008, 03:42:23 AM
Logical operators are considered OOP? I submit not.

Not quite Tim, Tony meant that you can overload logical operators, syntactic sugar they call it in C++ world. Either way it's just compiler gymnastics.

For example, the '==' can be overloaded (I think, but it's just an example), all it does though is let you use the '==' instead of calling say a static method that compares 2 of the same objects which may be called MyClass::Compare(this, someOtherClassOfThisType).

Either way you still have to write the comparison code, it's just short hand but can be confusing to the new comer to oop languages.
Title: Re: Windows - Command line and Dialog driven command
Post by: Chuck Gabriel on October 01, 2008, 07:11:29 AM
The definition of the > operator is determined by the types that are being compared.  Why wouldn't you call that OOP?
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 01, 2008, 07:18:50 AM
An example might be Vector2d operator *

Code: [Select]
public static Vector2d operator *(Matrix2d a, Vector2d b)
public static Vector2d operator *(Vector2d a, double factor)
public static Vector2d operator *(double factor, Vector2d a)
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 01, 2008, 10:58:03 AM
Thanks everybody.  I will look into this more when my brain is ready to digest it.
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on October 01, 2008, 02:01:44 PM

Ahh...Tim...what's the purpose of your IsLaterThan() function?

Just to make sure that the file that is going to be copied over is later than the one that is there now.  If it isn't a newer version, then don't copy it.  This is a one way copy, not syncing.


Hi Tim.

I think what Glenn was getting at is, why write a function that is essentially a reinvention of the DateTime's overloaded > (is-greater-than) operator ?


Code: [Select]

public bool IsLaterThan( DateTime thisDate, thatDate b )
{
    return thisDate > thatDate;
}



That's where I was going Tony - thanks. the overloading of operators or overloading in general is definately part of the OOP world.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 01, 2008, 07:21:24 PM
Those who are new to OOP and C# often find themselves reinventing things that already exist, merely because they did not know they were there. So, when one is just starting out, they can probably avoid reinventing many things that already exist if they were to just spend some time becoming more familiar with some of the basic principles and concepts of an OOP language and C# in particular, like operators and operator overloading.
Logical operators are considered OOP? I submit not.

You seem to have relational and logical operators confused, but regardless of that, it isn't operators that are 'oop', it is the ability of a type to overload/override the default operators, that is 'oop', and that's what we're talking about - overloading operators, not operators in general.

Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 01, 2008, 07:26:47 PM
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?

Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 01, 2008, 09:25:13 PM
Those who are new to OOP and C# often find themselves reinventing things that already exist, merely because they did not know they were there. So, when one is just starting out, they can probably avoid reinventing many things that already exist if they were to just spend some time becoming more familiar with some of the basic principles and concepts of an OOP language and C# in particular, like operators and operator overloading.
Logical operators are considered OOP? I submit not.

You seem to have relational and logical operators confused, but regardless of that, it isn't operators that are 'oop', it is the ability of a type to overload/override the default operators, that is 'oop', and that's what we're talking about - overloading operators, not operators in general.
I'll admit I was confused. you are correct. statement retracted.
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 02, 2008, 03:25:35 PM
I had some time to look into 'operator overload', but I didn't how one would know that the class DateTime does overload an operator?  I did notice that DateTime has a Compare method that I should have used.  Is it just common sense ( to a seasoned programming ) that the operator will be overloaded by default when comparing two like objects?

Off to see if my Inet searches will return better results than before for this topic.  Thanks again.  I really do appreciate it.

Edit:  All searches so far have shown how to make an overload for a custom class, not how to tell if a class has one.  That is the problem with my searching so far.
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 02, 2008, 03:43:26 PM
Have you looked at DateTime through reflector? It might shed some light on whats available for you to party on.

Code: [Select]
   public static int Compare(DateTime t1, DateTime t2)
    {
        long internalTicks = t1.InternalTicks;
        long num2 = t2.InternalTicks;
        if (internalTicks > num2)
        {
            return 1;
        }
        if (internalTicks < num2)
        {
            return -1;
        }
        return 0;
    }

    public int CompareTo(DateTime value)
    {
        long internalTicks = value.InternalTicks;
        long num2 = this.InternalTicks;
        if (num2 > internalTicks)
        {
            return 1;
        }
        if (num2 < internalTicks)
        {
            return -1;
        }
        return 0;
    }

    public int CompareTo(object value)
    {
        if (value == null)
        {
            return 1;
        }
        if (!(value is DateTime))
        {
            throw new ArgumentException(Environment.GetResourceString("Arg_MustBeDateTime"));
        }
        DateTime time = (DateTime) value;
        long internalTicks = time.InternalTicks;
        long num2 = this.InternalTicks;
        if (num2 > internalTicks)
        {
            return 1;
        }
        if (num2 < internalTicks)
        {
            return -1;
        }
        return 0;
    }


Code: [Select]
public static bool operator ==(DateTime d1, DateTime d2)
    {
        return (d1.InternalTicks == d2.InternalTicks);
    }

    public static bool operator >(DateTime t1, DateTime t2)
    {
        return (t1.InternalTicks > t2.InternalTicks);
    }

    public static bool operator >=(DateTime t1, DateTime t2)
    {
        return (t1.InternalTicks >= t2.InternalTicks);
    }

    public static bool operator !=(DateTime d1, DateTime d2)
    {
        return (d1.InternalTicks != d2.InternalTicks);
    }

    public static bool operator <(DateTime t1, DateTime t2)
    {
        return (t1.InternalTicks < t2.InternalTicks);
    }

    public static bool operator <=(DateTime t1, DateTime t2)
    {
        return (t1.InternalTicks <= t2.InternalTicks);
    }

Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on October 02, 2008, 03:49:07 PM
Placing your cursor in the word/type definition 'DateTime' in Visual Studio and hitting F1 will take you to the help for a given object. When I do this, it takes me to MSDN and it gives Constructors, Methods, Fields, Properties and Overloads for the the type in question.

I guess, at the end of the day, even though you know there is a DateTime class/struct (struct in this case), it's up to you to investigate...or get several good books.
It's all part of the learning process Tim - keep at it, but keep at it. :D
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on October 02, 2008, 03:52:34 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...
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 02, 2008, 03:57:15 PM
Have you looked at DateTime through reflector? It might shed some light on whats available for you to party on.

<snip>
Didn't think of that Daniel.  Thanks for the idea.

Placing your cursor in the word/type definition 'DateTime' in Visual Studio and hitting F1 will take you to the help for a given object. When I do this, it takes me to MSDN and it gives Constructors, Methods, Fields, Properties and Overloads for the the type in question.

I guess, at the end of the day, even though you know there is a DateTime class/struct (struct in this case), it's up to you to investigate...or get several good books.
It's all part of the learning process Tim - keep at it, but keep at it. :D
Didn't know about the 'F1' taking you to MSDN.  That is a good tip, and it even works in SharpDevelop.  I don't see the 'Overloads' though on the page that pops up for me.  Can you post a link Glenn?  Maybe I can see why I wasn't sent to that page.
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 02, 2008, 04:16:35 PM
... I don't see the 'Overloads' though ...

It seems those operators are not overloaded
Title: Re: Windows - Command line and Dialog driven command
Post by: Spike Wilbury on October 02, 2008, 04:31:18 PM
I don't see the 'Overloads' though on the page that pops up for me.  Can you post a link Glenn?  Maybe I can see why I wasn't sent to that page.

I am in a mac world now... but I guess Glenn was refering to the already overloaded list, if you open the DateTime structure it will show all the ones available.

maybe?
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 02, 2008, 04:54:38 PM
I don't see the 'Overloads' though on the page that pops up for me.  Can you post a link Glenn?  Maybe I can see why I wasn't sent to that page.

I am in a mac world now... but I guess Glenn was refering to the already overloaded list, if you open the DateTime structure it will show all the ones available.

maybe?
I see that some methods and properties have been overload'ed, but I didn't see anything about operators.  Maybe the disassembly is the way to go for that.  I learned something new.   :-)
Title: Re: Windows - Command line and Dialog driven command
Post by: Spike Wilbury on October 02, 2008, 04:58:55 PM
I see that some methods and properties have been overload'ed, but I didn't see anything about operators.  Maybe the disassembly is the way to go for that.  I learned something new.   :-)

I see, sorry did not read the whole thread.... next time - slap on my face -
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on October 02, 2008, 05:58:51 PM
Look at the operators (http://msdn.microsoft.com/en-us/library/system.datetime_members.aspx) section.
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 02, 2008, 06:08:51 PM
Look at the operators (http://msdn.microsoft.com/en-us/library/system.datetime_members.aspx) section.

That is the same page I get, but when I changed it the .Net2.0 language it doesn't show the operators anymore.
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on October 03, 2008, 02:51:21 AM
You do, there're just named differently and in the public methods section.
Look for 'op_*' as the name ie op_GreaterThan
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 03, 2008, 11:09:33 AM
You do, there're just named differently and in the public methods section.
Look for 'op_*' as the name ie op_GreaterThan
Thanks for that Glenn.  I wonder how many times I have just passed over those in other classes, and not known what it was.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 03, 2008, 01:58:41 PM

I had some time to look into 'operator overload', but I didn't how one would know that the class DateTime does overload an operator? 


In an OOP langauge, if a type does not overload an operator, you can't use the operator with instances of the type, and attempting to do so results in a compiler error.

It's more about understanding the fundamental concepts of OOP that allows one to understand that operators must be overloaded by every type they should work with, and that if an operator works for a given type (e.g., no compiler error occurs), then it can and should be used.

Quote

I did notice that DateTime has a Compare method that I should have used. 


Well, you really shouldn't use the Compare method, just as you also shouldn't use string.Equals() where you should be using the == operator.

Using operators makes code more readable. In a development vacume where no other programmer has to look at or work with your code, that may be ok. Otherwise, most seasoned coders will be reluctant to go near code that's poorly written and difficult to read or follow.

Quote

Edit:  All searches so far have shown how to make an overload for a custom class, not how to tell if a class has one.  That is the problem with my searching so far.


As I mentioned above, if a class does not provide an overload for an operator, you can't use it, and a compiler error is generated. So, finding out if a type overloads an operator is as simple as trying to use the operator with an instance of the type, and seeing if an error occurs.

Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey on October 03, 2008, 02:05:34 PM
Thanks for the information Tony.  It is very helpful to me.
Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 03, 2008, 08:13:11 PM
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?
I must have missed this one.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.
Title: Re: Windows - Command line and Dialog driven command
Post by: Kerry on October 03, 2008, 08:18:53 PM
For anyone following along, this may be a good place to start reading ;
Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni on October 05, 2008, 12:29:40 AM
In an OOP langauge, if a type does not overload an operator, you can't use the operator with instances of the type, and attempting to do so results in a compiler error.

It's more about understanding the fundamental concepts of OOP that allows one to understand that operators must be overloaded by every type they should work with, and that if an operator works for a given type (e.g., no compiler error occurs), then it can and should be used.
you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

Well, you really shouldn't use the Compare method, just as you also shouldn't use string.Equals() where you should be using the == operator.
And why not use it?  In most cases in OOP languages, using == to compare two Strings is absolutely wrong... in that case you are comparing whether two objects are physically the same object, not whether the two string values are the same things.  Sometimes that may return the correct (read: expected) value, but most of the time you really shouldn't do it.  While that case may not hold true in C#, it is a fallacy to say "In OOP"

Using operators makes code more readable. In a development vacume where no other programmer has to look at or work with your code, that may be ok. Otherwise, most seasoned coders will be reluctant to go near code that's poorly written and difficult to read or follow.
Ouch... maybe you should overload all methods to merely using operators? Or maybe you should learn a language which gets rid of unsightly, difficult to read methods (http://en.wikipedia.org/wiki/Brainfuck)?

As I mentioned above, if a class does not provide an overload for an operator, you can't use it, and a compiler error is generated. So, finding out if a type overloads an operator is as simple as trying to use the operator with an instance of the type, and seeing if an error occurs.
ThisDate > ThatDate doesn't always work in every OOP language, but won't upset the compiler because you are doing a valid comparison.... only not of the values as you would think, but of the objects.

But what would I know? :)
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 05, 2008, 12:45:20 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

Code: [Select]
public static bool operator ==(string a, string b)
{
    return Equals(a, b);
}
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 05, 2008, 12:48:47 AM
Code: [Select]
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

 :-D
Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni on October 05, 2008, 12:51:26 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

Code: [Select]
public static bool operator ==(string a, string b)
{
    return Equals(a, b);
}

In Java, == tests whether the two strings point at the same object.  You may want to tell Sun that Java isn't OOP :wink:
Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 05, 2008, 01:04:33 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

Code: [Select]
public static bool operator ==(string a, string b)
{
    return Equals(a, b);
}

In Java, == tests whether the two strings point at the same object.  You may want to tell Sun that Java isn't OOP :wink:
Same with Python:
Code: [Select]
In [1]: class test(object):
   ...:     def __init__(self, num):
   ...:         self.num = num
   ...:         
   ...:         

In [2]: i = test(2)

In [3]: j = test(2)

In [4]: i == j
Out[4]: False

In [5]: i.num == j.num
Out[5]: True
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 01:07:43 AM
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?
I must have missed this one.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.

Hate to disagree. 

Comparing the contents of two files does not tell you which was modified more recently.  The only thing a content based comparison tells you is if the contents of the two files are different, and nothing else.

Keeping in mind that the file's timestamp is meaningful, even if the file's contents are the same, the file that was changed more recently should still be used, so IMHO, there is no point to a content comparison of the files.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 01:14:53 AM
you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

In every OOP langauge, there are intrinsic types and user-defined types. Intrinsic types (like numeric types, boolean, and so on) are types the compiler knows about, and knows how to generate code to perform whatever operation a given operator requires.

For user-defined types that are not derived from intrinsic types, or derived from types that provide a virtual member that corresponds to an operator, the compiler *cannot* generate code for a given operator, so it has no choice but to throw an exception.

In the CLR, The == and != operators are the *only* operators that can be used on any type, and that is because all types are derived from System.Object, which provides a virtual Equals() method (overriden by System.ValueType(), System.String, and many others), and that is what the == and != operators delegate to.

In CLR, with == and !=, what happens depends on whether the type being compared is a reference type or a value type. For reference types, the Equals() member of System.Object() returns true if the operands both refer to the same object. 

For value types, System.ValueType() overloads Equals() to perform a byte-by-byte comparison of each object's data.

Hence, in the CLR, == and != are implemented for every object, but any other operator must be overloaded for a given type (or one of its base types), or a compiler error will be generated.

And that's why the compiler must throw an error - because it must generate code for the operator, and if it doesn't know what code to generate (e.g., it doesn't know how to compare the operands), then how can there not be an error?

Quote
And why not use it?  In most cases in OOP languages, using == to compare two Strings is absolutely wrong... in that case you are comparing whether two objects are physically the same object, not whether the two string values are the same things.  Sometimes that may return the correct (read: expected) value, but most of the time you really shouldn't do it.  While that case may not hold true in C#, it is a fallacy to say "In OOP"

The reason why one should use operators rather than explicit member functions is quite simple.

There are tens of thousands of classes, and each of them are free to implement functions that correspond to what operators do. The reason why you should use operators is quite simply because you don't have to remember what member function provides the implementation for each and every type. That's the purpose of overloading operators. It allows the programmer to not have to be intimately familiar with a type, and remember what the name of the method that compares two instances for equality, or a relational function like is-greater-than, and so on.

So, for example, you have two types written by two different people and each of them decides that the member function that tells if one instance is greater than another instance, will have two completely different names.

Code: [Select]

public class DumbWidget
{
   public static bool IsLargerThan( DumbWidget first, DumbWidget second )
   {
      // compare instances
   }
  
   public static bool IsSmallerThan( DumbWidget first, DumbWidget second )
   {
      // compare instances
   }
}

public class DumbGadget
{
   public static bool IsTallerThan( DumbGadget first, DumbGadget second )
   {
      // compare instances
   }
  
   public static bool IsShorterThan( DumbGadget first, DumbGadget second )
   {
      // compare instances
   }
}


Notice that the two classes were designed by different people, and each had their own idea about what the relational comparison member functions should be called. There's no protocol for that, there's no requirement or rule that states you must use a certain name, so it's pot luck as to what name will be used.

And this is why you should use overloaded operators:

Code: [Select]

public class SmarterWidget
{
   public static bool IsLargerThan( SmarterWidget first, SmarterWidget second )
   {
      // compare instances
   }
  
   public static bool IsSmallerThan( SmarterWidget first, SmarterWidget second )
   {
      // compare instances
   }
  
   public static bool operator >( SmarterWidget left, SmarterWidget right )
   {
      return IsLargerThan( left, right );
   }
  
   public static bool operator <( SmarterWidget left, SmarterWidget right )
   {
      return IsSmallerThan( left, right );
   }
}


In SmarterWidget, you don't have to remember what the names of the member functions are. You don't need to use intellisense... you only need to use your basic instincts.

It really shouldn't be that difficult to understand that, when types provide overloaded operators that call corresponding member functions (whose name is not the same for every type), the programmer is not required to remember what each type's respective member function is called.

With operators, they don't have to remember anything! They just use the damn operator, and that's that!

Quote

ThisDate > ThatDate doesn't always work in every OOP language, but won't upset the compiler because you are doing a valid comparison.... only not of the values as you would think, but of the objects.


That's the point... That's not a valid comparison. The class defines the concept of what 'is-greater-than means, not the compiler.

The fact that you believe that the C++ mentality (where '==' generally means "are these two pointers pointing at the same memory address?), should apply to higher-level languages and higher level class abstractions is wrong.

Java's == is also wrong for strings, because the need to tell if two strings refer to the same physical object is rare, in contrast to the need to compare their values lexically. 

Operators should perform the most common comparison, the one that most people would expect it to, and unfortunately that is not what you seem to think most would expect == to do.

Java was written by a C++ programmer, and designed to be friendly to C++ programmers. That was the mistake.

Think of C# as Java with the many of the mistakes corrected.
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 05, 2008, 01:15:40 AM
Ok, I’m kind of wrong here. Value types (structs) should provide an operator for testing equality. Reference type should provide an operator for testing the instance. In .Net a string behaves like a value type
Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni on October 05, 2008, 01:24:38 AM
you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

If the compiler doesn't know how to compare the types, the compiler *will* throw a fit.

What kind of compiler would let you use an operator on a type, if the compiler doesn't know what code it must generate to perform the comparison ?????

Why do you think the compiler throws the error?  It does that because it must generate code for the operation, and if it doesn't know what code to generate (e.g., it doesn't know how to compare the operands), then how can there not be an error?

You must be kidding, right?

Sorry.... I think that alone makes any further discussion pointless.

<CADaver>Go back and read what I said</CADaver>

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.  It seems you couldn't be bothered to read the next line where I said that, so I quote it here for you:

And why not use it?  In most cases in OOP languages, using == to compare two Strings is absolutely wrong... in that case you are comparing whether two objects are physically the same object, not whether the two string values are the same things.  Sometimes that may return the correct (read: expected) value, but most of the time you really shouldn't do it.  While that case may not hold true in C#, it is a fallacy to say "In OOP"

 ...

ThisDate > ThatDate doesn't always work in every OOP language, but won't upset the compiler because you are doing a valid comparison.... only not of the values as you would think, but of the objects.

If you're going to basically tell me to shut up, please at least read what I said before... er... re-iterating it to prove I'm wrong? :|
Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 05, 2008, 01:29:56 AM
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?
I must have missed this one.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.

Hate to disagree. 

Comparing the contents of two files does not tell you which was modified more recently.  The only thing a content based comparison tells you is if the contents of the two files are different, and nothing else.

Keeping in mind that the file's timestamp is meaningful, even if the file's contents are the same, the file that was changed more recently should still be used, so IMHO, there is no point to a content comparison of the files.
You have every right to disagree but you are 100% wrong, especially in the situation Tim's code represents. For a simple backup system local file is master and remote file is slave, there is no deviating from this. If for some reason the remote file has a datetime stamp that is greater than that of the local file the code FAILS, plain and simple. Heck even if they have the same datetime stamp the remote file could have completely different content than the local "master" file. If you don't think it's possible do a google search (http://www.google.com/search?q=windows+change+modified+date+of+a+file&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a) and you will see that I'm right.

This is very basic computer science stuff and comparing file content is the standard method for almost every modern backup utility and version control system out there.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 02:02:08 AM

If for some reason the remote file has a datetime stamp that is greater than that of the local file the code FAILS, plain and simple.

Thanks for making my point.

What you say above just about sums it up. There's no need to compare the contents of the files, because if the comparison of their timestamps indicates that the local file is newer than the backup, the backup proceeds, and otherwise it does not.

The only thing a content comparison can do, is check to see if the files are identical, which eliminates the need to back up the file. Since the chances that two files with different time stamps are identical are so small, there is nothing saved by comparing their contents, and doing that only serves to require the backup to take much longer.

Quote
Heck even if they have the same datetime stamp the remote file could have completely different content

Sorry, but what you say above seems to confiirm that you're confused.

A simple backup process is just that: Simple.  If the existing backup is older than the local file, the backup proceeds, and otherwise it does not. Whether the files are different, or not isn't important, only that the local file is newer than the backup.

Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 05, 2008, 02:19:01 AM

If for some reason the remote file has a datetime stamp that is greater than that of the local file the code FAILS, plain and simple.

Thanks for making my point.

What you say above just about sums it up. There's no need to compare the contents of the files, because if the comparison of their timestamps indicates that the local file is newer than the backup, the backup proceeds, and otherwise it does not.

The only thing a content comparison can do, is check to see if the files are identical, which eliminates the need to back up the file. Since the chances that two files with different time stamps are identical are so small, there is nothing saved by comparing their contents, and doing that only serves to require the backup to take much longer.
Quote
Heck even if they have the same datetime stamp the remote file could have completely different content

Sorry, but what you say above seems to confiirm that you're confused.

A simple backup process is just that: Simple.  If the existing backup is older than the local file, the backup proceeds, and otherwise it does not. Whether the files are different, or not isn't important, only that the local file is newer than the backup.
If this simple concept escapes you then god help you with the rest of your software writing. I've mentioned it several times yet you seem to be unable to grasp the concept that there is the possibility that a "backup file" has a timestamp which shows a newer timestamp than a "master file" nor the concept that a remote file can contain the same timestamp yet contain different content.

This is common sense stuff, we aren't "hacking the gibson" here.

over and out,
Tim "Zero Cool" Riley
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 03:59:35 AM
Quote

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.


I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 04:07:42 AM

If this simple concept escapes you then god help you with the rest of your software writing. I've mentioned it several times........


No, you haven't mentioned it several times.. you're just making it up as you go along.

You originally asserted that a hash of the files must be done.

Now you're saying "what if the existing backup is newer than the file to be backed up"., as if doing hash of the files is going to tell that.....

You're basically making things up as you go along to save face, which is fine, but I've got more interesting things to do.

Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni on October 05, 2008, 07:41:40 AM
Quote
What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.
That entirely depends on your definition of "correct".

Will the following compile?

Code: [Select]
if (x > y) ;
        y++;

Yes it will.  Is it correct?  I would say not.  What does it do?  Almost certainly not what you wanted it to.  However, the code is perfectly VALID.

So will the compiler compile incorrect code?  Well, it will only compile code which it knows can be executed.... that doesn't mean that the code is correct and works as expected by the programmer.

If you don't believe me, why do programs like FxCop exist, and why does it warn you about certain code practises which will happily go through a compiler?
Title: Re: Windows - Command line and Dialog driven command
Post by: tjr on October 05, 2008, 12:04:17 PM
If this simple concept escapes you then god help you with the rest of your software writing. I've mentioned it several times........

No, you haven't mentioned it several times.. you're just making it up as you go along.

You originally asserted that a hash of the files must be done.

Now you're saying "what if the existing backup is newer than the file to be backed up"., as if doing hash of the files is going to tell that.....

You're basically making things up as you go along to save face, which is fine, but I've got more interesting things to do.
Like I said, I've said it several time.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 05:26:43 PM
Quote
What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".


You're getting off the main point, which is that for *any* type, a compiler cannot infer what 'is greater than', or 'is less than' means, and if the compiler cannot infer what that means and the type is not based on an intrinsic type for which the compiler *can* infer a meaning, the compiler should not compile code that uses > or < on a type that does not provide overloads for them.

A compiler for example, doesn't know what a 3d vector is, so it can't generate code that returns a bool indicating if one 3d vector 'is greater than' another.

It's just that plain and simple. 

Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni on October 05, 2008, 05:29:53 PM
Quote
What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".


You're getting off the main point, which is that for *any* type, a compiler cannot infer what 'is greater than', or 'is less than' means, and if the compiler cannot infer what that means and the type is not based on an intrinsic type for which the compiler *can* infer a meaning, the compiler should not compile code that uses > or < on a type that does not provide overloads for them.

A compiler for example, doesn't know what a 3d vector is, so it can't generate code that returns a bool indicating if one 3d vector 'is greater than' another.

It's just that plain and simple. 
I'm not getting off the point, you were telling me that == is a valid way in OOP languages to compare two strings for equality of value.  That is fundamentally incorrect.  You also said that if an operator doesn't cause the compiler to bug out, it's valid to be used (and in fact SHOULD be used) in that case.  Also incorrect.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 06:11:11 PM
Quote
What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".


You're getting off the main point, which is that for *any* type, a compiler cannot infer what 'is greater than', or 'is less than' means, and if the compiler cannot infer what that means and the type is not based on an intrinsic type for which the compiler *can* infer a meaning, the compiler should not compile code that uses > or < on a type that does not provide overloads for them.

A compiler for example, doesn't know what a 3d vector is, so it can't generate code that returns a bool indicating if one 3d vector 'is greater than' another.

It's just that plain and simple. 

I'm not getting off the point, you were telling me that == is a valid way in OOP languages to compare two strings for equality of value.  That is fundamentally incorrect.  You also said that if an operator doesn't cause the compiler to bug out, it's valid to be used (and in fact SHOULD be used) in that case.  Also incorrect.


Sorry, I don't want to get into it with nit-pickers with nothing better to do than mince words to try to find flaws in them.
 
In most well-designed OOP programming languages, both of those assertions are true. Java isn't a well-designed programming language, in my opinion.

Since there are many "oop languages", some obscure, half-baked, and rarely used, One can also say that there is nothing at all that *all* of them have in common, nor is there any rule or principle that every one of them supports, which means, that you're not really saying much of anything by asserting that what I've said about operators is not true for "*any*" oop language.

It is true for most well-designed ones.

So, what you're up to here is making an issue out of my use of one word: "any" as in "any oop language".

Well sorry, I'm not interesting in feeding cheap, opportunistic, pot-shots based on relatively meaningless minutae and nit-picking of words.

Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 06:23:03 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.

Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni on October 05, 2008, 06:24:42 PM
I like how you went back and HEAVILY edited your post a page back!  See, if you had responded like that in the first place, I would have been more inclined to treat you as someone able to communicate on that level.  When you get to the stage of "NO U" I will talk back to you as such.  

For anyone who comes across this in future, the post I was responding to (which has since been changed to actually be something worthwhile) was:

you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

If the compiler doesn't know how to compare the types, the compiler *will* throw a fit.

What kind of compiler would let you use an operator on a type, if the compiler doesn't know what code it must generate to perform the comparison ?????

Why do you think the compiler throws the error?  It does that because it must generate code for the operation, and if it doesn't know what code to generate (e.g., it doesn't know how to compare the operands), then how can there not be an error?

You must be kidding, right?

Sorry.... I think that alone makes any further discussion pointless.
This is why people quote posts when they respond to them.
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 05, 2008, 07:02:18 PM
*sigh*
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT on October 05, 2008, 08:52:15 PM

I like how you went back and HEAVILY edited your post a page back!  


I like how you troll for opportinties to nit-pick other people's words.

Shame you don't have anything better to do with your time.
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R on October 06, 2008, 06:12:19 AM
...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.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT 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.

Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT 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.

Title: Re: Windows - Command line and Dialog driven command
Post by: MickD 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.
Title: Re: Windows - Command line and Dialog driven command
Post by: Tuoni 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.
Title: Re: Windows - Command line and Dialog driven command
Post by: TonyT 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.  


Title: Re: Windows - Command line and Dialog driven command
Post by: tjr 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.
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R 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:
Title: Re: Windows - Command line and Dialog driven command
Post by: tjr 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.
Title: Re: Windows - Command line and Dialog driven command
Post by: It's Alive! on October 07, 2008, 11:16:14 AM
I just don’t believe it… Mick post a pick of yourself  :lol:
Title: Re: Windows - Command line and Dialog driven command
Post by: T.Willey 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.
Title: Re: Windows - Command line and Dialog driven command
Post by: Glenn R 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 ;)
Title: Re: Windows - Command line and Dialog driven command
Post by: MickD 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.