visual-foxpro
연산자

비고

숫자 연산자

숫자 연산자는 다른 언어와 마찬가지로 가장 쉽고 거의 동일합니다.

• +, -, * 및 /. 더하기, 빼기, 곱하기 및 나누기 연산자 (VFP에는 정수 나누기가 없으므로 INT (), CEILING () 및 FLOOR ()) 함수를 사용하여 결과를 정수로 변환 할 수 있습니다.
• % 모듈러스 연산자.
• ^ 및 **. 운영자의 힘. 둘 다 똑같은 일을합니다.
• (). 그룹화 운영자.
• 연산자가 우선합니다. 순서는 다음과 같습니다.

   ( )
   ^ (or **) 
   / and *
   - and +

    ? 10 / 5 + 2 && Outputs 4
    ? 2 + 10 / 5 && Outputs 4 as well. Division has precedence.
     
    * Both multiplication and division have same precedence
    * They would be interpreted from left to right.
    ? 4 * 5 / 2 + 5 && Outputs 15
    * Use parentheses whenever you are in doubt or want to be explicit
    ? ( (4 * 5) / 2 ) + 5 && Outputs 15. Explicit grouping of operations

    ? 4 * 5^2 && ^ has precedence, this is same as 4 * (5^2) = 100.
    ? (4 + 5)^2 && Using parentheses we say add 5 to 4 (9) and then square = 81. 

논리 연산자

우선 순위에 따라 VFP의 논리 연산자는 다음과 같습니다.

역사적으로 NOT, AND, OR은 .NOT., .AND., .OR로 작성됩니다. 원할 경우 계속 사용할 수 있지만 AND, OR NOT은 더 간단하고 깨끗합니다.

거짓과 참이면 .F를 사용해야합니다. 및 .T. 리터럴 각각. 대신 F와 T를 사용할 수 없습니다.

* Some logical variables
local llOld, llEmail  && any variable declaration implicitly initializes the variable as .F. - false
? m.llOld, m.llEmail && Prints .F. .F.

llOld   = .T.
llEmail = .F.

if ( m.llOld AND m.llEmail )
   ? 'Old AND should be emailed to'
endif
if ( m.llOld OR m.llEmail )
   ? 'Old OR should be emailed to'
endif
if ( m.llOld AND !m.llEmail ) && Same as (m.llOld AND NOT m.llEmail)
   ? 'Old BUT should NOT be emailed to'
endif

* Above code outputs
Old OR should be emailed to
Old BUT should NOT be emailed to

VFP에서 논리적 표현은 바로 가기 방식으로 평가됩니다. 즉, 수표의 첫 번째 부분이 전체 결과를 만족하면 나머지 표현식은 해석 되지 않습니다 . 샘플은 다음과 같습니다.

? 1 = '2' && An obvious error. It would complain operator/operand type mismatch.

* However we could use such an expression in an if and get no error
* because it is not interpreted at all 
* (VFP is dynamic and there is no compile time check)

local llProcess
llProcess = .T.

if (m.llProcess OR (1='2'))
   ? 'Should do processing'
endif

* Would output

Should do processing

* without any error because m.llProcess true means
* the whole expression would be true, thus the expression after OR 
* is not interpreted at all.

초보자를 잡는 한 가지 함정은 AND, OR 연산자와 연결된 SQL 쿼리에서 여러 번 확인해야 할 때가 있습니다. 그것들이 많을 때, 연산자가 우선 순위 (순서 (), NOT, AND, OR)를 가지고 있으며 해석이 체인에서 왼쪽에서 오른쪽으로 수행된다고 생각할 수도 있습니다. 샘플을 고려해보십시오.

select * from myTable where !isCustomer AND debit > 5000 OR discount > 5

이 쿼리의 의도는 무엇입니까? 그룹 괄호를 사용하여 명시 적으로 지정하면 다음과 같이 표시됩니다.

((NOT isCustomer) AND debit > 5000) OR discount > 5

"firstExpression"OR (할인> 5)처럼 단순화되었습니다. 의도가 무엇이든간에이 OR 때문에 다음을 선택할 수 있습니다.

(할인> 5) 행과 5,000 이체가있는 고객이 있습니다.

아마 그 의도는 "고객이 아니고 (직불 카드가 5000 또는 5,000을 초과하는 카드가 5 이상인 카드를 내게 제공하십시오)"였을 것입니다. 처음부터 괄호를 사용했다면 분명합니다.

select * from myTable where !isCustomer AND (debit > 5000 OR discount > 5)

첫 번째 NOT 연산자에 대해 괄호를 사용할 수는 있지만 가치는 없습니다. 피연산자가 하나의 표현식 인 경우! isCustomer는 (isCustomer가 아닌) 명확하게 읽혀집니다.

문자 연산자

우선 순위에 따라 4 개의 문자 연산자 만 있습니다.

+는 가장 단순하며 다른 많은 언어로 문자열을 연결하는데도 사용됩니다.

local firstName, lastName
firstName = "John"
lastName  = "Smith"

? m.firstName + " " + m.lastName

출력 : John Smith

- 조금 까다 롭고 널리 알려져 있지 않습니다. 왼쪽 문자열에서 후행 공백을 사용하고 오른쪽 공백을 해당 문자열에 추가합니다. 이름과 성을 가진 테이블이 있고 각각 20 자라고 가정하십시오. 우리는 전체 이름을 만들기 위해 이름과 성을 연결하려면, 우리는 또한 그 결과 크기 (이 경우 20 + 20 + 1 개 공간 = 41) 고정합니다. 중간 이름 열을 만들자. 전체 이름이 "lastName, firstName middleName_______"처럼 보이기를 원합니다. - 연산자를 사용하는 것이 가장 쉽지만 그룹화를 위해 여기에 괄호를 사용하는 방법에 유의해야합니다. 그러면 원하는 것을 정확히 얻을 수 있습니다.

* Create a cursor for our sample and fill in a few names
Create Cursor Names (firstName c(20), midName c(20), lastName c(20))

Insert Into Names (firstName, midName, lastName) Values ('Cetin','', 'Basoz')
Insert Into Names (firstName, midName, lastName) Values ('John', 'M', 'Smith')
Insert Into Names (firstName, midName, lastName) Values ('John', 'F', 'Kennedy')
Insert Into Names (firstName, midName, lastName) Values ('Tom', '', 'Hanks')

* Select with tricky - operator
Select *, ;
    lastName - (', '+firstName-(' '+midName)) As FullName ;
    from Names ;
    INTO Cursor crsNames ;
    nofilter

Browse

그리고 출력은 다음과 같습니다.

fullName 열에서 모든 후행 공백이 끝까지 멋지게 푸시됩니다. 구조를 확인하면 fullName 열은 63 자 (3 * 20 + 3 자)를 추가합니다.

괄호를 그룹화하는 중요성에 유의하십시오 (괄호를 제거하거나 다른 방식으로 정렬 해보십시오).

이런 경우에는 오퍼레이터가 유혹을 느낄지라도 동전의 다른면이 있습니다. 이 연산자는 VFP에 고유하므로 SQL을 이식 할 수 없습니다. 대신이 ANSI 호환 SQL을 사용하여 동일한 결과를 얻을 수 있습니다.

Select *, ;
    CAST(RTRIM(lastName) +', '+ RTRIM(firstName) +' '+ midName as char(63)) As FullName ;
    from Names ;
    INTO Cursor crsNames ;
    nofilter

마지막 연산자는 $입니다. 왼쪽 문자열이 오른쪽 문자열의 일부인지 단순히 확인합니다.

local upcased, digits, hexDigits
upcased = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
digits  = '0123456789'
hexDigits  = m.digits + 'ABCDEF'

? 'A' $ m.upcased && .T.
? 'a' $ m.upcased && .F.
? '1' $ m.digits && .T.
? 'F' $ m.digits && .F.
? 'F' $ m.hexDigits && .T.

중요 : VFP에서는 대문자, 소문자 또는 소문자로 코드를 작성할 수 있지만 문자열은 항상 대 / 소문자를 구분합니다. 예 : "Smith"와 "smith"는 두 가지 고유 한 값입니다. 또는 표에 국가 열이 있으면 '미국'으로 검색하면 '미국'을 찾을 수 없습니다. $ 연산자와 동일합니다. "GE"$ ""Germany "는 거짓입니다.

개인 메모 : 단순함으로 인해 $를 좋아할 지 모르지만 Microsoft 소스 코드에서 자주 사용되는 것을 알 수 있지만 IMHO는별로 가치가 없습니다. 통신 사업자에서 작성한 많은 수천 개의 라인에 대해 생각해 보면, 필자는 자신의 코드에서이 라인이 거의 발견되지 않을 것이라고 생각합니다. 거의 항상 더 나은 대안이 있습니다 (특히 왼쪽 피연산자가 단일 문자가 아니거나 대소 문자 구분이 중요하지 않은 경우).

날짜 및 시간 연산자

기본적으로 datetime 값에는 두 개의 연산자가 있습니다. +와 -는 날짜 / 날짜 시간 계산을 수행하기 위해 오버로드됩니다 (아마도 C 용어).

+가 더 쉽습니다. 두 개의 피연산자가 있는데, 하나는 날짜 또는 datetime 값이고 다른 하나는 숫자입니다 (숫자를 사용할 수도 있지만 모든 실제 목적을 위해 정수입니다).

피연산자 중 하나가 날짜 인 경우 숫자 피연산자는 "day"로 간주됩니다.

? Date() + 10 && Get the date 10 days later
* VFP is leap year aware when doing date math
? Date(2016, 2, 28) + 1 && Add 1 day to Feb 28, 2016. Returns Feb 29, 2016.
? Date(2017, 2, 28) + 1 && Add 1 day to Feb 28, 2017. Returns Mar 1, 2017.

피연산자 중 하나가 datetime이면 숫자 피연산자는 "second"로 간주됩니다.

하루에 24 * 60 * 60 = 86400 초가 있습니다.

? Datetime() + 86400 && Add 1 day to current datetime. 

1 월 1 일, 2016 2:20에 4 시간 15 분 추가

? Datetime(2016, 1, 1, 14, 20, 0) + (4 * 3600 + 15 * 60) 

2016 년 1 월 1 일 금요일, 오후 6시 35 분.

?를 사용하여 간단한 인쇄를하면 화면에 나타나는 내용이 날짜 설정에 따라 다릅니다. 예를 들어, 아무 것도 변경하지 않은 경우 날짜 설정은 미국식 (MDY), 12 시간 형식 (AM / PM) 및 세기는 마지막 2 자리 숫자로만 표시됩니다.

date와 datetime에 대한 특수 기호는 문자열을 '엄격하게'yyyy / MM / dd [HH : mm : ss | hh : mm : ss tt] 형식으로 해석하도록 강요합니다. 따라서 ^는 날짜 / 날짜 시간 연산자로 간주 될 수 있습니다. 예를 들어, 일부 데이터는 소스에서 201610082230 (yyyyMMddHHmm)과 같은 형식으로 들어오는 것으로 간주됩니다. 해당 값을 유효한 Datetime으로 가져 오려면 다음을 수행하십시오.

Local cSample, tSample
cSample = '201610082230'
tSample = Ctot(Transform(m.cSample, '@R ^9999/99/99 99:99'))
? Transform(m.tSample, '@YL')

출력 (시스템의 긴 날짜 설정에 따라 다름) :

2016 년 10 월 8 일 토요일, 오후 10:30:00

- 빼기에 사용됩니다. 해당 피연산자는 날짜 / datetime 값이거나 날짜 / datetime 및 숫자입니다.

먼저 더 간단한 날짜 / datetime 및 숫자 연산자 (+ 연산자와 같이)부터 시작합시다.

피연산자 중 하나가 날짜 인 경우 숫자 피연산자는 "day"로 간주됩니다.

? Date() - 10 && What was the date 10 days ago?
? Date(2016, 3, 1) - 1 && Returns Feb 29, 2016.
? Date(2017, 3, 1) - 1 && Returns Feb 28, 2017.

피연산자 중 하나가 datetime이면 숫자 피연산자는 "second"로 간주됩니다.

? Datetime() - 86400 && Go back exactly one day

"now"에서 1 시간 그리고 30 분 전에 얻으세요 :

? Datetime() - (1 * 3600 + 30 * 60) 

두 번째 형식은 두 날짜 / datetime 값의 차이를 얻는 것입니다. 피연산자는 날짜 또는 datetime 모두이며 날짜와 datetime을 동시에 사용할 수 없습니다 (필요에 따라 유형 변환을 수행하면 VFP가 대신하지 않습니다). 규칙은 +와 -와 같고, 피연산자는 날짜, 차이는 일 , 피연산자는 datetime, 그 차이는 초 입니다.

섣달 그믐 날까지 며칠입니까? (2016 년)?

? Date(2016, 12, 31) - Date()

자정까지 남은 시간은 몇 초입니까?

? Dtot(Date()+1) - Datetime()

마지막 샘플에서는 내일 자정 값을 얻기 위해 Date / Datetime 함수, DTOT - DateToTime을 사용했습니다. 유용한 날짜 / 날짜 시간 함수가 많이 있지만, 기술적으로 연산자로 간주되지 않기 때문에 모두 건너 뜁니다. (날짜 / 시간에 작동하지만 :) 다른 연산자에서도 마찬가지입니다.

날짜 / 날짜 시간 빼기가 서명 됩니다. 즉, 더 작은 날짜 / datetime을 첫 번째 피연산자로 사용하면 결과는 음수가됩니다. date / datetimes의 순서에 관계없이 긍정적 인 결과를 얻을 필요가있는 경우 abs () 함수를 사용할 수 있습니다.

관계 연산자

모든 연산자 중에서, 관계 연산자는 가장 복잡한 연산자이므로, 결국 우리는이를 끝까지 남겨 두었습니다.

관계 연산자는 비교 연산자라고도하며, 물건을 비교하는 데 사용됩니다.

비교 결과는 부울 false 또는 true입니다.

흥미롭게도 VFP 도움말에서 확인하면 짧은 목록 작업과 몇 가지 선이 마치 해당 운영자에 관한 것 인 것처럼 보입니다.

글쎄, 복잡성은 숫자, 날짜, 날짜 / 시간, 논리 또는 문자열, 심지어는 객체와 같은 모든 유형에서 작동한다는 사실에서 비롯됩니다. 또한, 행동이 어색하게 보일 수 있습니다. 결과에 어떤 영향을 미치는지 알지 못하면 기대하는 것을 얻지 못합니다.

관계 연산자 목록부터 시작해 보겠습니다.

이들을 모든 데이터 유형에 사용할 수 있지만 피연산자간에 유형 호환성이 있어야합니다. 예를 들어 Date를 Integer와 비교하려고하면 오류가 발생합니다.

날짜와 날짜를 비교할 수 있습니다. 유형은 다르지만 VFP는 변환을 암시 적으로 수행합니다.

? Date() > DateTime() && .F. 
? Date() <= DateTime() && .T. 
? Date() < DateTime() && .T. if it is not midnight

피연산자가 숫자 인 경우이 모든 연산자는 간단하고 직선적이며 수학 표현식에서와 같이 작동합니다.

논리적 피연산자로, .F. .T보다 작은 것으로 간주됩니다.

우리가 비교하고있는 것들을 가지고있는 객체는 메모리에있는 객체의 참조입니다. 따라서 가장 많이 사용되는 비교는 두 객체 변수가 같은 객체를 가리키는 지 확인하는 것입니다. 즉 :

local o1, o2
o1 = createobject('Label')
o2 = createobject('Label')
? m.o1 = m.o2 && is o1 and o2 the same object?
? m.o1 > m.o2 && this would work too but likely you would never use

* remember we are comparing their references in memory
* 
* They are different objects, but do they have any difference in their properties?
? CompObj(m.o1, m.o2) && .T. They are identical properties wise

문자 데이터 형식의 비교, 일명 문자열 비교는 VFP에서 가장 혼란스러운 형식입니다. 다른 언어 및 / 또는 데이터베이스 에서처럼 VFP (및 어쩌면 다른 xBase 언어)에서만 작동합니다.

몇 년 전만하더라도 지역 사회에서 실제로 VFP에서이 연산자가 어떻게 작동하는지 알지 못하는 일부 고급 회원을 보았습니다. 그래서 약간의 미묘한 차이로 인해 초보자를 쉽게 혼란스럽게 할 수도 있습니다.

비교는 기본적으로 평등한지 아닌지에 대한 것입니다. 그것들이 동일하지 않다면 우리는 연산자>, <,> =, <=, 맞습니까? 문자열의 경우 두 문자열이 같은 것으로 간주 될 때 혼란 스럽습니다.

중요 : VFP 문자열은 대 / 소문자를 구분합니다. 'A'와 'a'는 두 개의 별개의 문자열입니다. 대다수의 데이터베이스에서 대 / 소문자를 구분하지 않는 데이터 정렬을 사용하는 경우가 아닙니다. 예를 들어 postgreSQL 또는 MS SQL Server에서 대소 문자를 구분하지 않고 (CI) 데이터 정렬로 만든 테이블의 경우 :

select * from myTable where Country = 'TURKEY'

select * from myTable where Country = 'Turkey'

동일한 결과를 얻을 것이다. VFP에서는 대소 문자가 일치하는 항목 만 가져옵니다. 그러나 VFP to는 일부 데이터 정렬을 지원하며 대소 문자를 구분하지 않습니다. (신뢰하지 말고 아래 참조)

• 두 개의 문자열이 같지 않은 경우, 지금까지는 아무런 기본값도 변경하지 않았다면 ASCII 값에 따라 비교 됩니다 .

  ? 'Basoz' < 'Cetin' && is true.
  ? 'basoz' < 'Cetin' && is false.
  ? 'Cetin' < 'David' && is true.
  ? 'Çetin' < 'David' && is false.
  

데이터 정렬의 기본값은 'machine'이며 이것이 사용자가 얻는 것입니다. 데이터 정렬을 다른 것으로 변경하면 해당 데이터 정렬 순서에 따라 비교가 수행됩니다. 기본 컴퓨터가 아닌 다른 데이터 정렬 설정을 사용하면 비교에 대소 문자를 구분하지 않을 수도 있습니다 (평등에 대해 신뢰하지 마십시오).

  set collate to 'GENERAL'
  ? 'Basoz' < 'Cetin'
  ? 'basoz' < 'Cetin'
  ? 'Cetin' < 'David'
  ? 'Çetin' < 'David'

이제이 모든 표현식은 TRUE입니다.

개인적 조언 : VFP의 데이터 정렬은 결코 신뢰할 만합니다. 데이터 정렬을 사용하지 말고 기본 'MACHINE'을 사용하는 것이 좋습니다. 데이터 정렬을 사용하는 경우 문자 데이터와 관련하여 예기치 않은 것을 경험할 때 데이터 정렬을 먼저 확인해야합니다. 나는 그것이 많은 경우에 실패한 것을 보았고 시연했지만, VFP9 이전 버전을 사용하기를 그만 두었습니다. 일관성이있을 수도 있습니다. 사실 모르겠습니다.

우리가 문자열로 불평등 사례를 다뤘다는 것을 고려할 때, 까다로운 것은 평등 케이스입니다. VFP에서는 기본적으로 두 가지 설정이 비교에 영향을줍니다.

1. SET EXACT (기본값은 OFF이고 일반 비교 결과 - SQL 제외)
2. SET ANSI (기본값은 OFF이고 SQL에서는 효과 비교 만 수행합니다 .SET EXACT 는 SQL 쿼리 내 비교에 영향 을 미치지 않습니다 .

SET EXACT를 OFF로 설정하면 "왼쪽에서 문자열로 오른쪽에서 문자열 시작"으로 비교를 읽습니다. 문자열의 길이와 비교됩니다.

? "Bobby" = "B" && Bobby starts with B, so TRUE
? "Bobby" = "Bob" && Bobby starts with Bob, so TRUE
? "Bobby" = "Bob " && Bobby starts with Bob but there is a trailing space there, FALSE
? "Bobby" = "bob" && would be true with collation set to GENERAL

정기적 인 비교에서 "Bobby"= "B"는 TRUE이지만 "B"= "Bobby"는 FALSE입니다. 즉, 피연산자의 위치가 중요합니다.

SET EXACT ON을 사용하면 문자열은 완전히 일치해야하지만 후행 공백은 무시됩니다 (여기서는 대 / 소문자 구분을 수행하지 않습니다).

? "BOBBY" = "BOB" && FALSE 
? "BOBBY" = "BOBBY" && TRUE
? "BOBBY" = "BOBBY     " && TRUE 
? "BOBBY     " = "BOBBY" && TRUE

이제 SQL 명령을 사용하면 SET EXACT는 아무 효과가 없으며 SET EXACT OFF처럼 작동합니다.

Select * from Customers where Country = 'U'

'U'로 시작하는 모든 국가에서 미국, 영국 고객을 선택합니다.

그러나 SQL에서 정의에 따라 피연산자의 순서를 변경하면 동일한 결과가 나타납니다. 그러므로:

Select * from Customers where 'U' = Country

또한 같은 방식으로 작동합니다 (비 SQL 명령과의 차이점에 유의하십시오).

정확히 일치하는 것을 암시하고 싶다면 ANSI를 켜는 것이 좋습니다.

SET ANSI ON
Select * from Customers where Country = 'USA'

미국에서 온 모든 고객을 반환합니다. 오른쪽 표현식에서 국가 필드 OR의 뒤 공백은 무시됩니다. 당신이 가지고있는 어느쪽에 얼마나 많은 후행이 있든 상관 없습니다. 마치 RTRIM (국가) = RTRIM ( '미국')과 같이 비교 된 것처럼 비교할 수 있습니다.

VFP의 연산자에는 언급되어 있지 않지만 SQL 연산자 는 LIKE입니다. LIKE를 사용하면 SET ANSI 설정에 관계없이 정확한 일치 비교를 얻습니다 (LIKE 강제 및 암시 적 ANSI ON 사용 - 결국 ANSI 연산자 임). 그러나 행동에 약간의 차이가 있음을 유의하십시오. 예고편의 전체 크기가 필드 크기보다 작거나 같지 않으면 후행 공백을 무시하지 않습니다. 예를 들어, Country 필드가 C (10)이면 Country = 'USA'또는 Country = 'USA__'는 작동하지만 Country = 'USA _________'는 실패합니다 ( 밑줄 은 공백을 나타내며 마지막 것은 공백이 7 개 더 있음).

마지막으로 우리는 마지막 연산자 인 ==을 사용합니다. 이는 정확히 똑같고 문자열을 사용한다는 것을 의미합니다. 한 가지 장점은 ==를 사용하면 SET EXACT 또는 SET ANSI 설정에 관계없이 항상 정확히 일치하는 것을 의미한다는 것입니다. 그러나 SQL 명령 또는 nonSQL 일반 명령 인 경우 동작이 다릅니다.

SQL 사용 :

Select * from Customers where Country == 'USA'

ANSI와 EXACT 설정이 무엇이든 , 우리는 모든 고객을 미국에서만 원합니다. 양쪽에있는 뒤 공백은 무시됩니다.

비 SQL 사용 :

? m.lcString1 == m.lcString2

그것들이 대소 문자와 길이에 관해서 정확히 같은 경우에만 참이 될 것이다 (후미 공백은 무시되지 않는다). SET ANSI, EXACT 또는 COLLATE 설정에는 영향을주지 않습니다.