Язык программирования Си в одном посте
А зачем начинающему программисту на с/с++ нужны юнионы и битовые маски в структурах?
И вообще это по моему не учебник длятупых начинающих, а размазанный справочник. Мне бы такой временами не помешал для всяких руби, пхп, c# или там вб. Все время забываешь, как там обьявить что-то вроде массива.
И вообще это по моему не учебник для
раскрыть ветку (53)
раскрыть ветку (1)
Я обычно гуглю "%language% array" к примеру. Злой начальник увез цветной принтер в другой офис и мне лень туда ездить, чтобы напечать всю эту муру.
Ты ещё посмотри, как автор выводит строки через строки в строковой printf. Я даже не знаю, как это назвать - может, графоманством?
Да и вообще - какие, нафиг, calloc, free, указатели? Зачем это нужно начинающему? Даже не зная подобного можно писать неплохие программы, да, они не будут оптимальны, но они всё равно будут работать!
Да и вообще - какие, нафиг, calloc, free, указатели? Зачем это нужно начинающему? Даже не зная подобного можно писать неплохие программы, да, они не будут оптимальны, но они всё равно будут работать!
раскрыть ветку (50)
>Ты ещё посмотри, как автор выводит строки через строки в строковой printf. Я даже не знаю, как это назвать - может, графоманством?
Вы что, хотите сказать, что надо printf(s)?
Тогда у меня для вас плохие новости, такой вариант небезопасен, так как если s пришло от пользователя, то он сможет получить содержимое всего стека
Вы что, хотите сказать, что надо printf(s)?
Тогда у меня для вас плохие новости, такой вариант небезопасен, так как если s пришло от пользователя, то он сможет получить содержимое всего стека
Я вот только за принтфы и сканфы, я их люблю, не то, что все эти ваши потоки, тьфу.
Указатели - часть с++ в общем-то, хотя поначалу можно и без них, конечно-же.
Указатели - часть с++ в общем-то, хотя поначалу можно и без них, конечно-же.
раскрыть ветку (47)
ещё комментарии
раскрыть ветку (45)
раскрыть ветку (44)
раскрыть ветку (13)
это не умаляет того факта, что есть практическая разница между C и C++. К тому же, в посте речь идет о C
раскрыть ветку (12)
раскрыть ветку (11)
раскрыть ветку (9)
Это лишь то, что добавили в С++. Практическая разница нужна. Скажем, могу ли я сделать так?
class MyClass
{
char *str;
MyClass()
{
str = (char*)calloc(...);
}
...
}
class MyClass
{
char *str;
MyClass()
{
str = (char*)calloc(...);
}
...
}
раскрыть ветку (8)
раскрыть ветку (7)
Зато на с++ могу. Получается, что при юзании компилятора для с++ практической разницы нет?
раскрыть ветку (6)
Хмммм. Как же так, при юзании компилятора для c++ разницы нет, а при юзании компилятора для c разница есть. Вы не находите это слегка странным? Быть может, это потому, что мы рассматривали различия c и c++?
раскрыть ветку (3)
Не различия, а практическую разницу. И да, как-то странно получается: компилятор с++ ест все, а компилятор си - только не всё. Кароче. беспредметно получается) Потому что вся разница(new, Classes...) - это расширение, а основа не меняется.
раскрыть ветку (2)
да ёмаё. есть c, есть c++. в плюсах добавили классы, операторы работы с памятью, шаблоны, ссылки и т.д. Это разве на ваша "практическая" разница. Либо мы говорим о разном, либо это переливание из пустого в порожнее.
раскрыть ветку (1)
есть.
не весь сишный код будет работать на компиле с++
объявления функций, типы и работа с ними и т.д.
частая ошибка считать что с++ - это расширенный си и имеет 100% обратную совместимость.
не весь сишный код будет работать на компиле с++
объявления функций, типы и работа с ними и т.д.
частая ошибка считать что с++ - это расширенный си и имеет 100% обратную совместимость.
раскрыть ветку (1)
>>частая ошибка считать что с++ - это расширенный си
Ну это у Шилдта прочитал. А можете рассказать вкратце, что не будет из сишного работать на компиле с++?
Ну это у Шилдта прочитал. А можете рассказать вкратце, что не будет из сишного работать на компиле с++?
1. Киньте мне ссыль или название комплиятора С.
2. Какая разница в примерах в этой задаче если мы будем писать на с или на с++?
3. Ну и вообще, чего в с++ есть? Шаблоны и классы, то есть синтаксический сахар по большому-то счету.
2. Какая разница в примерах в этой задаче если мы будем писать на с или на с++?
3. Ну и вообще, чего в с++ есть? Шаблоны и классы, то есть синтаксический сахар по большому-то счету.
раскрыть ветку (29)
1. gcc
2. в примерах никакой, за исключением того, что автор изначально говорил про C
3. классы, шаблоны, исключения, пространства имен, new/delete, ссылки. и да, я не считаю шаблоны и классы синтаксическим сахаром.
2. в примерах никакой, за исключением того, что автор изначально говорил про C
3. классы, шаблоны, исключения, пространства имен, new/delete, ссылки. и да, я не считаю шаблоны и классы синтаксическим сахаром.
раскрыть ветку (22)
Это синтаксический сахар. Классы к примеру через жопу, но можно реализовать через структуры, даже гибче получится. Шаблоны - это просто офигенный, но сахар. Без него или с ним язык не преобретает новый функционал (к примеру от классов хоть немного, но преобретает), и вообще шаблоны - мощная замена для препроцессора.
раскрыть ветку (21)
раскрыть ветку (20)
Ну к примеру заводим структуру из данных + несколько указателей на функции, заменяющих собой методы класса. В функции-инициализаторе присваиваем этим полям указатели на нужные функции и получаем полиморфизм. Причем мы прямо на лету можем менять методы на другие. В ооп это реализуется через визитера или еще какие паттерны.
Наследование - просто включаем другие структуры в новую. Можно стрроить не дерево или однонаправленную сеть, как в классах и интерфейсах, а вообще практически произвольные структуры.
Инкапсуляция - синтаксический сахар, компилятор ругается на то, что что-то там приватное, иди отсюда, не дамся.
И вуаля - на структурах и указателях мы построили кривой ооп.
Наследование - просто включаем другие структуры в новую. Можно стрроить не дерево или однонаправленную сеть, как в классах и интерфейсах, а вообще практически произвольные структуры.
Инкапсуляция - синтаксический сахар, компилятор ругается на то, что что-то там приватное, иди отсюда, не дамся.
И вуаля - на структурах и указателях мы построили кривой ооп.
раскрыть ветку (19)
1. Как реализуется полиморфизм - непонятно. Например, есть классы:
class Shape { public: virtual void bar()=0; }
class Triangle: public Shape ....
class Circle: public Shape ...
foo(Shape *s) { s->bar(); }
foo(new Triangle());
foo(new Circle());
2. На что ругается компилятор?
class Shape { public: virtual void bar()=0; }
class Triangle: public Shape ....
class Circle: public Shape ...
foo(Shape *s) { s->bar(); }
foo(new Triangle());
foo(new Circle());
2. На что ругается компилятор?
раскрыть ветку (16)
Да фиг его знает, может очепятка. Теперь ооп без ооп:
Я имею в виду что-то типо того:
// Описание каллбаков для методов
typedef void (*struct_method)( non_cls *self );
typedef void (*struct_method1)( non_cls *self, int a );
// Интерфейс с данными
struct tag_non_cls
{
int data, data2;
struct_method method;
struct method1 method1;
} non_cls;
// Конструктор. В с++ это реализуется языком, а тут - самостоятельно
void init_non_cls( non_cls *p )
{
p->method = &mymethod;
p->method1 = &mymethod1;
}
// метод
void mymethod1( non_cls *self, int a )
{
self->data = a+5;
}
// Наследование
struct tag_hier
{
non_cls base; // Наследование
non_cls2 base2; // Множественное наследование (ну или скорее агрегирование)
struct_method2 method2;
} hier;
// Создание
hier *h = (hier*) malloc( sizeof(hier) );
init_hier( h ); // Внутре вызов init_non_cls и остального, в с++ это тоже часть языка.
После этого работа
h->method( h );
h->method1( h, 2 );
(Мы же все знаем, что self - это прямой параметр, передаваемый в каждый член класса при вызове, в с++ это часть языка).
Полиморфизм - в зависимости от того, какой инициализатор вызываем, он сам может править указатели на функции в базовых структурах.
Динамический полиморфизм:
if (some_cond)
h->base->method = &my_other_method
Такое умеет только е%анутый перл и мы в нашем нехитром примере нереальной кривизны.
Я имею в виду что-то типо того:
// Описание каллбаков для методов
typedef void (*struct_method)( non_cls *self );
typedef void (*struct_method1)( non_cls *self, int a );
// Интерфейс с данными
struct tag_non_cls
{
int data, data2;
struct_method method;
struct method1 method1;
} non_cls;
// Конструктор. В с++ это реализуется языком, а тут - самостоятельно
void init_non_cls( non_cls *p )
{
p->method = &mymethod;
p->method1 = &mymethod1;
}
// метод
void mymethod1( non_cls *self, int a )
{
self->data = a+5;
}
// Наследование
struct tag_hier
{
non_cls base; // Наследование
non_cls2 base2; // Множественное наследование (ну или скорее агрегирование)
struct_method2 method2;
} hier;
// Создание
hier *h = (hier*) malloc( sizeof(hier) );
init_hier( h ); // Внутре вызов init_non_cls и остального, в с++ это тоже часть языка.
После этого работа
h->method( h );
h->method1( h, 2 );
(Мы же все знаем, что self - это прямой параметр, передаваемый в каждый член класса при вызове, в с++ это часть языка).
Полиморфизм - в зависимости от того, какой инициализатор вызываем, он сам может править указатели на функции в базовых структурах.
Динамический полиморфизм:
if (some_cond)
h->base->method = &my_other_method
Такое умеет только е%анутый перл и мы в нашем нехитром примере нереальной кривизны.
раскрыть ветку (15)
Это все понятно. Я так и представлял.
h->method1( h, 2 ); будет ругаться, разве нет? у tag_heir нет method1. он есть у base, т.е. вызывать придется явно. а если мы сделаем hier_hier? Чтобы вызвать method1 самого базового класса надо сделать
hh->base->base->method1()??? и кстати, что передавать параметром? какой указатель? По идее, сюда нужно передать самый базовый:
hh->base->base->method1(hh->base->base).
Если честно, я не так себе представлял наследование. При наследование, класс-потомок расширяет функционал базового класса, а у нас тут просто агрегация.
Ну и вопрос с динамическим полиморфизмом открыт. Под динамическим полиморфизмом я до сих пор подразумевал именно то, что показал в своем примере про фигуры
h->method1( h, 2 ); будет ругаться, разве нет? у tag_heir нет method1. он есть у base, т.е. вызывать придется явно. а если мы сделаем hier_hier? Чтобы вызвать method1 самого базового класса надо сделать
hh->base->base->method1()??? и кстати, что передавать параметром? какой указатель? По идее, сюда нужно передать самый базовый:
hh->base->base->method1(hh->base->base).
Если честно, я не так себе представлял наследование. При наследование, класс-потомок расширяет функционал базового класса, а у нас тут просто агрегация.
Ну и вопрос с динамическим полиморфизмом открыт. Под динамическим полиморфизмом я до сих пор подразумевал именно то, что показал в своем примере про фигуры
раскрыть ветку (14)
Ага, явно выстраиваем иерархию. Никакого синтаксического сахара :)
Первый параметр - селф, второй и дальше - простые параметры.
Если в наследовании нужно переопределение - то меняй указатели из базового класса.
У тебя там обычный статический полиморфизм.
Нельзя сделать так
tfig *f = new circle ();
...
Не, я передумал, f->draw = &triagle->draw;
А у меня можно.
Первый параметр - селф, второй и дальше - простые параметры.
Если в наследовании нужно переопределение - то меняй указатели из базового класса.
У тебя там обычный статический полиморфизм.
Нельзя сделать так
tfig *f = new circle ();
...
Не, я передумал, f->draw = &triagle->draw;
А у меня можно.
раскрыть ветку (13)
Да не, я немного сумбурно написал вчера)) В общем, я хотел сказать, что у тебя наследование заключается в том,что ты хранишь в якобы наследнике указатель на якобы родителя. А по факту, у тебя в структуре хранится указатель на какую-то другую структуру. И все наследование заключается в том, что этот указатель называется base. Но ведь при наследовании наследник получает функционал родителя + добавляет свой. А тут такого не получается, т.к. функционал родителя хранится в отдельном поле структуры. Я вот это имел ввиду.
Как это нельзя сделать tfig *f = new circle() ???
Как это нельзя сделать tfig *f = new circle() ???
раскрыть ветку (12)
Ну и че, ты пишешь inherited->base.some_base_func
Если хочешь - напиши заглушку в inherited для вызова base и будет все клево. Это тоже сахарок :)
Да так нельзя:
tfig *f = new circle (); // f->draw хранит указатель на circle->draw ()
через некое время я передумал и попытался сделать так:
f->draw = &triangle->draw;
В ооп это низзя, у меня можно:)
Конечно, остается вопрос о том, как же треугольник будет рисоватся без данных, но мы его опустим.
Если хочешь - напиши заглушку в inherited для вызова base и будет все клево. Это тоже сахарок :)
Да так нельзя:
tfig *f = new circle (); // f->draw хранит указатель на circle->draw ()
через некое время я передумал и попытался сделать так:
f->draw = &triangle->draw;
В ооп это низзя, у меня можно:)
Конечно, остается вопрос о том, как же треугольник будет рисоватся без данных, но мы его опустим.
раскрыть ветку (11)
Ну блин, это ж не наследование, это просто агрегация :)
Конечно так нельзя в плюсах) Честно говоря, я не вижу преимуществ этой фишки, да и непонятно, к чему это)
Конечно так нельзя в плюсах) Честно говоря, я не вижу преимуществ этой фишки, да и непонятно, к чему это)
раскрыть ветку (10)
Ну блин, в чистом с нет наследования. Если бы можно было бы написать struct inherited:base, то было бы наследование, и мы бы писали h->base_func, а не h->base.base_func или там упражнялись с заглушками.
раскрыть ветку (9)
раскрыть ветку (8)
Ну дык я и не говорил, что этот сахар ненужный или там плохой. Он прекрасен и охуенен, я обожаю шаблоны, я прям тащусь от ооп, но это можно делать и без ооп-языка. Как бе я это имел в виду.
раскрыть ветку (7)
Это я уже понял. Все равно останусь при своем мнении - полноценной реализации не получится))
раскрыть ветку (6)
Дык я же показал две основне кита ооп - наследование и полиморфизм. Инкапсуляция, да, средствами чистого с не сделаешь, но этих двух вполне хватит для реализации ооп.
раскрыть ветку (5)
раскрыть ветку (4)
С чего это? Что в них нельзя сделать такого, что можно в с++?
И насчет динамического полиморфизма тоже что-нибудь скажи.
И насчет динамического полиморфизма тоже что-нибудь скажи.
раскрыть ветку (3)
Повторюсь, что агрегация это немного другое, нежели наследование. Если у тебя в структуре будет интовое поле, получается структура наследуется от инта. Но ты ен можешь сложить две структуры, ты можешь сложить только эти два инта в структурах. Тогда как наследование подразумевает получение наследником свойств базового класса.
Я только что придумал как реализовать динамический полиморфизм :) В каждую структуру добавлять чаровское или интовое поле, однозначно ассоциированное с "типом" (аналог имени класса). Тогда функция рисования будет выглядеть так:
void draw(void *shape)
{
Circle *c;
Triangle *t;
Square *s;
/* все остальные "наследники" */
int type = /* здесь надо извлечь поле type из объекта *shape */
if(type == 1)
{
c = (Circle *)shape;
c->draw(c);
} else if(type == 2)
{
t = (Triangle *)shape;
t->draw(t);
}
}
Я только что придумал как реализовать динамический полиморфизм :) В каждую структуру добавлять чаровское или интовое поле, однозначно ассоциированное с "типом" (аналог имени класса). Тогда функция рисования будет выглядеть так:
void draw(void *shape)
{
Circle *c;
Triangle *t;
Square *s;
/* все остальные "наследники" */
int type = /* здесь надо извлечь поле type из объекта *shape */
if(type == 1)
{
c = (Circle *)shape;
c->draw(c);
} else if(type == 2)
{
t = (Triangle *)shape;
t->draw(t);
}
}
раскрыть ветку (2)
Твоя функция на корню губит мысль полиморфизма :)
Как раз от этой шляпы и должен спасать полиморфизм :)
А про агрегацию и наследование - в чистом С вроде нет символа двоеточие после struct %name%, поэтому нельзя делать чистое наследование, а приходится довольствоватся агрегированием, что ведет не только к кривизне, но и к возможности мультинаследования и прочие вещи, типо 2 раза от одного класса унаследоватся :)
Кстате, погулил - текущий с++ от микрософта к примеру умеет наследовать структуры, судя по всему, ему нет разницы между структурой, интерфейсом и классом (ну кроме публичности и возможности вносить члены), то есть если не брать слово класс и делать, как я описывал, то в с++ можно получить ооп без агрегации.
Как раз от этой шляпы и должен спасать полиморфизм :)
А про агрегацию и наследование - в чистом С вроде нет символа двоеточие после struct %name%, поэтому нельзя делать чистое наследование, а приходится довольствоватся агрегированием, что ведет не только к кривизне, но и к возможности мультинаследования и прочие вещи, типо 2 раза от одного класса унаследоватся :)
Кстате, погулил - текущий с++ от микрософта к примеру умеет наследовать структуры, судя по всему, ему нет разницы между структурой, интерфейсом и классом (ну кроме публичности и возможности вносить члены), то есть если не брать слово класс и делать, как я описывал, то в с++ можно получить ооп без агрегации.
раскрыть ветку (1)
А как еще заставить функцию рисовать фигуру, о которой она не знает на этапе компиляции? ООП-подход позволяет использовать указатель на базовый класс, в котором есть вирутальная функция draw. Как сделать это со структурами - я не знаю.
Дело не двоеточии, а в самом принципе наследования. Я не спорю, что агрегирование - это гибко. Я говорю, что агрегирование не является наследованием, т.к. класс-наследник не расширяет функционал класса, а в ключает его. Тут мы и переходим к динамическому полиморфизму. Класс-наследник в какой-то мере является базовым классом, поэтому мы можем использовать указатель на базовый класс и передавать ему адрес наследника.
Да, на сколько я помню, в плюсах структуры - это те же классы, только с открытой по-умолчанию областью видимости членов. Поэтому тут в любом случает будет ООП :)
Дело не двоеточии, а в самом принципе наследования. Я не спорю, что агрегирование - это гибко. Я говорю, что агрегирование не является наследованием, т.к. класс-наследник не расширяет функционал класса, а в ключает его. Тут мы и переходим к динамическому полиморфизму. Класс-наследник в какой-то мере является базовым классом, поэтому мы можем использовать указатель на базовый класс и передавать ему адрес наследника.
Да, на сколько я помню, в плюсах структуры - это те же классы, только с открытой по-умолчанию областью видимости членов. Поэтому тут в любом случает будет ООП :)
1. Онлайн - компилятор для Си: http://www.compileonline.com/compile_c_online.php
2. В среде для С++ должны работать без проблем.
3. ООП, это очень обширная тема.
2. В среде для С++ должны работать без проблем.
3. ООП, это очень обширная тема.
раскрыть ветку (5)
1. Ема. До чего дошли. В вебе компилер на С. С ума сойти.
3. ООП это слова класс, виртуал, абстракт (=0) и приват-паблик. Больше ничего.
Шаблоны - это слово темплейт, скобачки и все.
3. ООП это слова класс, виртуал, абстракт (=0) и приват-паблик. Больше ничего.
Шаблоны - это слово темплейт, скобачки и все.
раскрыть ветку (4)
Множество сложных, эффективных и интересных подходов реализуются с ООП. Советую вникнуть :)
раскрыть ветку (1)
Ну а с синтаксической точки зрения я ничего не забыл?
Я прекрасно знаю половину паттернов гоф и даже треть активно использую, но в языке-то больше ничего от ооп нету.
Я прекрасно знаю половину паттернов гоф и даже треть активно использую, но в языке-то больше ничего от ооп нету.
раскрыть ветку (1)
Правда чтоль, а я то и не знал.
Наследование - часть слова класс. Инкапсуляция это паблик-приват и вообще уже было в структуре (с видимостью паблик), полиморфизм - виртуальные функции. И что-же я забыл-то.
Наследование - часть слова класс. Инкапсуляция это паблик-приват и вообще уже было в структуре (с видимостью паблик), полиморфизм - виртуальные функции. И что-же я забыл-то.
ещё комментарии
ещё комментарии