추신 그건 그렇고, 당신이 프로그램을 개발하고 텍스트를 채우지 않는다면 변형 가능성이 중요합니다. OOP로 성경 한 권을 다시 쓰면 충분합니다. 다른 접근 방식을 사용하면 전체 프로그램을 편집해야 합니다.
OOP에서 러시아어로 작성할 수도 있습니다. 동의한다. 그러나 OOP에 대한 불만이 있습니다. 내 실습에서 이 방법의 선언된 효과는 완전히 논박되었으며 나는 이 방법이 효과가 없다고 일축했습니다. 실제로 OOP를 사용하면 프로그래밍 언어를 "인간화"할 수 있지만 기계에 전혀 필요하지 않은 불필요한 엔터티로 채워집니다. 훨씬 더 많은 것이 밝혀졌습니다. 이러한 엔터티는 사람에게별로 필요하지 않으며 그들 없이는 할 수 있습니다. 가변 범위를 말씀하시는 건가요? 전역 3D 배열에서 변수를 구성합니다. 이 배열의 각 필드를 클래스라고 부르고 필드의 각 행을 열거형이라고 가정해 보겠습니다. 각 변수의 값을 현지화하는 것은 매우 쉬우며 액세스도 마찬가지입니다...
우리는 변환에 대해 생각해야 합니다... 논리 코어와 함께 작동할 범용 소프트웨어 엔진을 만들려는 아이디어가 있습니다. 논리 체인은 커널에 작성됩니다. 커널을 통해 엔진은 인덱스로 기능에 액세스합니다. 그것을 변환하는 것은 매우 쉬울 것입니다.
Реter Konow : 고급 C++를 보십시오. 이 프로그래밍 언어는 이미 고유한 속어를 습득한 것 같습니다... 다른 언어에는 이러한 엔터티가 없을 것입니다. 연구를 수행하고 필요한 것만 남겨두면 여러 번 축소됩니다. 따라서 대다수가 더 이해하기 쉽고 접근할 수 있게 될 것입니다. 그러나 누군가가 이 언어가 모든 사람이 이해할 수 있고 접근할 수 있기를 원하지 않아 엄청나게 복잡하다는 느낌이 듭니다...
C++에는 많은 기능이 계층화되어 있습니다. 메인 시스템 언어로 남아있고 무엇이든 쓸 수 있도록 다양한 기능이 저장되어 있습니다.
토픽 스타터는 아마도 이전에 승인된 절차적 프로그래밍 방법과 대조적으로 OOP의 이점을 완전히 이해하지 못했을 것입니다. 절차적 방법 이전에도 무조건 점프 연산자를 사용하여 프로그램을 작성했습니다. 그리고 이런 식으로 작성된 프로그램은 디버그하고 작업의 논리를 추적하기가 매우 어려웠으며 심지어 "스파게티 접시"라고 불렸습니다.
Vitalii Ananev : 토픽 스타터는 아마도 이전에 승인된 절차적 프로그래밍 방법과 대조적으로 OOP의 이점을 완전히 이해하지 못했을 것입니다. 절차적 방법 이전에도 무조건 점프 연산자를 사용하여 프로그램을 작성했습니다. 그리고 이런 식으로 작성된 프로그램은 디버그하고 작업의 논리를 추적하기가 매우 어려웠으며 심지어 "스파게티 접시"라고 불렸습니다.
1. 프로그래밍 경력은 몇 년입니까?
2. 러시아어로 프로그램을 작성하기 위해 적어도 한 번(자신을 위해) 시도한 적이 있습니까?
문제는 고정 관념이 존재하고 우리가 그 인질이 아닌가 하는 것입니다.
관계 질문입니다. 나는 영어로 쓰는 것을 선호하기 때문에 모든 면에서 더 편한 것 같아요. 지원, 간결함, 오해 찾기, 커뮤니티.
나는 당신이 영어로 쓰기를 꺼리는 것은 영어를 제대로 배우기를 꺼리기 때문에 생긴 고정관념이라고 말하고 싶습니다.
외부 변수가 러시아어로 되어 있으면 기호가 나타날 수 있습니다 ???? 예를 들어 서버에 시스템에 글꼴이 없는 경우.
1C - 예, 러시아어로 좀 더 친숙합니다. 그러나 다른 언어에서는 영어만 가능합니다(90년대 말에 어떻게든 "러시아어" Visual Basic을 시도했습니다.
글쎄, 당신은 OOP에서 러시아어로 쓸 수 있습니다.
OOP를 포기했을 때 끊는 것의 본질은 무엇입니까?
OOP의 본질은 프로그래머가 직접 변수의 범위를 설정할 수 있는 기회가 주어진다는 것입니다. 이 기회를 무시함으로써 무엇을 얻습니까?
더 이상 범위를 제어할 수 없기 때문에 계속해서 새로운 카운터와 새로운 변수를 사용해야 합니다.
이름은 접미사와 접두사를 사용하여 더 길게 작성해야 합니다.
코드를 재사용 할 수 있는 능력을 잃게 됩니다(OOP의 기둥 중 하나).
물론 그게 전부는 아니지만 간단히 말해서.
어떤 접근 방식을 선호합니까?
추신 그건 그렇고, 당신이 프로그램을 개발하고 텍스트를 채우지 않는다면 변형 가능성이 중요합니다. OOP로 성경 한 권을 다시 쓰면 충분합니다. 다른 접근 방식을 사용하면 전체 프로그램을 편집해야 합니다.
OOP에서 러시아어로 작성할 수도 있습니다. 동의한다. 그러나 OOP에 대한 불만이 있습니다. 내 실습에서 이 방법의 선언된 효과는 완전히 논박되었으며 나는 이 방법이 효과가 없다고 일축했습니다. 실제로 OOP를 사용하면 프로그래밍 언어를 "인간화"할 수 있지만 기계에 전혀 필요하지 않은 불필요한 엔터티로 채워집니다. 훨씬 더 많은 것이 밝혀졌습니다. 이러한 엔터티는 사람에게별로 필요하지 않으며 그들 없이는 할 수 있습니다. 가변 범위를 말씀하시는 건가요? 전역 3D 배열에서 변수를 구성합니다. 이 배열의 각 필드를 클래스라고 부르고 필드의 각 행을 열거형이라고 가정해 보겠습니다. 각 변수의 값을 현지화하는 것은 매우 쉬우며 액세스도 마찬가지입니다...
우리는 변환에 대해 생각해야 합니다... 논리 코어와 함께 작동할 범용 소프트웨어 엔진을 만들려는 아이디어가 있습니다. 논리 체인은 커널에 작성됩니다. 커널을 통해 엔진은 인덱스로 기능에 액세스합니다. 그것을 변환하는 것은 매우 쉬울 것입니다.
고급 C++를 보십시오. 이 프로그래밍 언어는 이미 고유한 속어를 습득한 것 같습니다... 다른 언어에는 이러한 엔터티가 없을 것입니다. 연구를 수행하고 필요한 것만 남겨두면 여러 번 축소됩니다. 따라서 대다수가 더 이해하기 쉽고 접근할 수 있게 될 것입니다. 그러나 누군가가 이 언어가 모든 사람이 이해할 수 있고 접근할 수 있기를 원하지 않아 엄청나게 복잡하다는 느낌이 듭니다...
C++에는 많은 기능이 계층화되어 있습니다. 메인 시스템 언어로 남아있고 무엇이든 쓸 수 있도록 다양한 기능이 저장되어 있습니다.
ACMe에서 OpenCL 및 스레드 제어로.
C#에서 순수한 OOP Wellcom을 원함
토픽 스타터는 아마도 이전에 승인된 절차적 프로그래밍 방법과 대조적으로 OOP의 이점을 완전히 이해하지 못했을 것입니다. 절차적 방법 이전에도 무조건 점프 연산자를 사용하여 프로그램을 작성했습니다. 그리고 이런 식으로 작성된 프로그램은 디버그하고 작업의 논리를 추적하기가 매우 어려웠으며 심지어 "스파게티 접시"라고 불렸습니다.
내 접근 방식은 다음과 같습니다.
1. 우리는 프로그램 함수의 호출을 인덱싱합니다. 함수 자체를 이벤트를 확인하는 함수(논리적 함수 - 예/아니오 반환), 절차적 함수(실행), 계산된 함수로 나눕니다.
2. 글로벌 3차원 배열 형태로 논리적 코어를 생성합니다. 우리는 특정 계층 구조에서 논리적 기능의 인덱스를 규정합니다(확인하는 이벤트의 중요성에 따른 분리: 글로벌 및 로컬 이벤트). 우리는 핵 분야에서 이러한 사건으로부터 둘레를 만듭니다.
3. 우리는 논리 체인의 끝에 절차 및 계산 기능의 인덱스를 넣습니다.
4. 타이머 주파수에서 커널의 이벤트 주변을 순환하고 인덱스를 통해 필요한 기능을 호출하는 논리 엔진을 만듭니다.
5. 프로그램의 재구성은 특정 논리적 체인의 재구성 또는 새로운 구성으로만 구성됩니다.
11 유니를 포함하지 않습니다.
틀림없이.
관계 질문입니다. 나는 영어로 쓰는 것을 선호하기 때문에 모든 면에서 더 편한 것 같아요. 지원, 간결함, 오해 찾기, 커뮤니티.
나는 당신이 영어로 쓰기를 꺼리는 것은 영어를 제대로 배우기를 꺼리기 때문에 생긴 고정관념이라고 말하고 싶습니다.
나는 영어로 도스토예프스키를 읽었다. 이것은 전혀 요점이 아닙니다 ... 러시아어는 유전 적 수준에서 프로그래밍하는 데 더 편리합니다.
문제 없습니다. 47번 염색체는 힘입니다.
OOP는 가장 똑똑한 사람들, 교수들에 의해 만들어졌습니다. 수년 동안 프로그램을 작성하는 것이 가장 편리하도록 프로그래머의 요구에 맞게 변경되었습니다.
코드 사용의 안전성에 대해서도 MQ의 OOP가 완성되었습니다.
새로운 종교의 선지자가 되고 싶습니까? 문제 없습니다. 결국 당신의 시간입니다.