Поздоровляю Вас — Ви зробили, мабуть, найкращій вибір. Серйозна людина — серйозні цілі.

А тепер - перше завдання квесту.

Вам дано конкретну задачу з аналітичної геометрії. Насправді завдання звучить так: "Написати для бібліотеки Geometry фунцію метод певного об'єкту, конструктор тощо, залежно від конкретної задачі (надалі - модуль), яка буде розв'язувати БУДЬ-ЯКУ задачу такого типу, незалежно від конкретних чисел, що стоять в умові задачі для прикладу.

Рішення Geometry, у розробці якого Вам запропонували тримати участь, містить дві версії бібліотеки, практично ідентичні.

Проект GeomLib — це реалізація бібліотеки на C#. З нею можна працювати, створивши свій проект як на C#, так і на C++.

GeomDemo — програма на C#, яка використовує ВСІ класи і їхні методи з GeomLib, тестуючи коректність їхньої роботи на простеньких прикладах.

CppUsingCsDemo — програма на C++, яка використовує саме бібліотеку GeomLib, написану на C#!

Попри багатомовність, декларовану розробниками технології .NET з компанії дрібном'яких, розроблено також бібліотеку Geometry мовою C++. Це проект GeomCpp.

Повний тест бібліотеки — це проект CppDemo.

Кінець-кінцем, проект CppExample — приклад розв'язання конкретної задачі. Так, як, власне, Вам і слід зробити.

Категоричними умовами, яких треба дотримуватися, є таке. У бібліотеці, яку ми всі пишемо, вже прийнято певні рішення щодо програмної реалізації основних понять геометрії у вигляді певних структур даних (class мови C# або C++). Це означає, що Ваш модуль повинен приймати вхідну інформацію і повертати результат у термінах цих типів даних. Тобто, якщо Ваше завдання звучить так: "Записати рівняння прямої лінії (площини, конуса тощо), яка (який)...", то Ви маєте написати конструктор відповідного класу, що отримує вхідні параметри -- змінні типу об'єктів, що відповідають певним поняттям геометрії. Якщо сказано "Записати рівняння прямої лінії, яка проходить через таку-то точку та такі-то пряму та площину", то Вашою задачею є написання конструктора змінної-нащадка прямої типу tLine, вхідними даними якого КАТЕГОРИЧНО мають бути саме змінні типу CPoint^, CLine^ та CPlane^ (C++) або СPoint, СLine та СPlane (C#).

На етапі проектування псувати саму бібліотеку Geometry не варто. Для завдання типу "Записати рівняння прямої лінії, яка проходить через таку-то точку та такі-то пряму та площину" Ви маєте утворити окремий БАГАТОфайловий проект.

#include <iostream>

using namespace System;
using namespace GeomLib; // або GeomCpp

/* Тут мають бути директиви включення всіх 
   файлів того варіанту бібліотеки, 
   що Ви її обрали за базовий. */
...

// Спадкуємо клас СMyLine від СLine
class СMyLine: public СLine  
{
  private:
    ...
  public:
    СMyLine(СPlane *p, СPoint *M, int &RC); 

};

СMyLine::СMyLine(СPlane *p, СPoint *M, int &RC)
{
  ...
}

#include <fstream>
#include "geometry.h"
#include "MyLine.h"

int main() 
{
  СPlane *p;
  СPoint *M; 
  СLine *L2;
  int RC; // Ретурн коде! :)

  СMyLine *L;
  
  // СMyLine for Geometry. V1.0 (C) Ipsayenko Vovchyk, 2011
  cout << "СMyLine for Geometry. V1.0 (C) Ipsayenko Vovchyk, 2011" << endl;

  //   Тут треба задати початкові значення для вхідних величин
  
  L = gcnew СMyLine(p, M, L2, RC);
  if ((L == NULL) || (RC != 0))
     ... // все пропало... 
  else {
         // нє, ще не все!
     ...
     delete L;
  }
  
}

Ретельна перевірка коректності вхідних даних - ще одна хороша думка, що прийшла була колись в голову бігбосу на етапі розробки специфікацій. Який мануал не пиши, а дурний користувач обов'язково спроможеться передати до Вашого модуля некоректні дані. Коректна реакція на некоректні дані користувача - це гречно, шляхетно та кошерно. А якщо програма на помилкові вхідні дані реагує "злітанням" та "вивалюванням" в операційну систему, це просто ознака непрофесійності авторів розробки. Випишіть всі варіанти некоректностей, що можуть трапитися через фантазії користувача. А може, й через ляпи ваших колег, що працюють поруч. Всі ці перевірки треба буде реалізувати у вашому модулі.

Чи є у Вашої задачі варіанти наборів коректних вхідних даних, що їх доведеться обробляти за різними алгоритмами? Чи не забули Ви реалізувати їх всі? А реалізувавши, чи відтестували?

Головна програма Вашого проекту пишеться лише з метою продемонструвати роботу Вашої функції або процедури. Тому до інтерфейсу (діалогу з користувачем) вимог аж ніяких. Зате є жорстка вимога щодо ВІДСУТНОСТІ виведення куди-небудь усередені тієї процедури, що її Вам замовлено. Спілкуватися "зі світом широким" Ваш конструктор має через список параметрів, а не засобами введення-виведення, які є різними у різних середовищах та у різних користувачів, а ми тут пишемо пакет з претензією на універсальність.

Ось це все бігбос Тарас і висловив нашому герою, розвалившись у своєму фотелі, закинувши ноги на приставний столик, явно копіюючи своїх американських замовників, і потягуючи каву з горнятка.

За другим разом Вовчик все зробив як слід, роботу здав. Випробувальний термін минув, і тепер він - у штаті.

А Ви?