data Format = Number Format
            | Str Format
            | Ch Format
            | Float Format
            | Lit String Format
            | End


PrintfType : Format -> Type
PrintfType (Number fmt) = (i : Int) -> PrintfType fmt
PrintfType (Str fmt) = (str : String) -> PrintfType fmt
PrintfType (Ch fmt) = (char : Char) -> PrintfType fmt
PrintfType (Float fmt) = (float : Double) -> PrintfType fmt
PrintfType (Lit str fmt) = PrintfType fmt
PrintfType End = String


printfFmt : (fmt : Format) -> (acc : String) -> PrintfType fmt
printfFmt (Number fmt) acc = \i => printfFmt fmt (acc ++ show i)
printfFmt (Str fmt) acc = \str => printfFmt fmt (acc ++ str)
printfFmt (Ch fmt) acc = \c => printfFmt fmt (acc ++ show c)
printfFmt (Float fmt) acc = \f => printfFmt fmt (acc ++ show f)
printfFmt (Lit lit fmt) acc = printfFmt fmt (acc ++ lit)
printfFmt End acc = acc


toFormat : (xs : List Char) -> Format
toFormat [] = End
toFormat ('%' :: 'd' :: chars) = Number (toFormat chars)
toFormat ('%' :: 's' :: chars) = Str (toFormat chars)
toFormat ('%' :: 'c' :: chars) = Ch (toFormat chars)
toFormat ('%' :: 'f' :: chars) = Float (toFormat chars)
toFormat ('%' :: chars) = Lit "%" (toFormat chars)
toFormat (c :: chars) = case toFormat chars of
                             Lit lit chars' => Lit (strCons c lit) chars'
                             fmt => Lit (strCons c "") fmt


printf : (fmt : String) -> PrintfType (toFormat (unpack fmt))
printf fmt = printfFmt _ ""

λΠ> :t printf "%c %f %d %s"
printf "%c %f %d %s" : Char -> Double -> Int -> String -> String

λΠ> printf "%c %f %d %s" 'A' 1.234 1 "LOR"
"'A' 1.234 1 LOR" : String

λΠ> printf "%c %f %d %s" 'A' 1.234 1.0 "LOR"
builtin:Type mismatch between
        Double (Type of 1.0)
and
        Int (Expected type)

Еще есть ЯП общего назначения, которые так могут (ну кроме лиспов с макрами, где и то если типы параметров printf известны в compile-time), при этом разработчику не нужно патчить компилятор на каждый чих?

Всем привет, ну начну с того что некоторое время назад решил писать своё поделие, ну вроде сервис в основе которого kore.io и в процессе появились потребности, система тестирования, HTML шаблонизатор, обработка utf-8 под мои потребности ну и то-ли NIH синдром то-ли спортивный интерес (не так важно) пишется всё самостоятельно (не без вашей помощи, за что спасибо), но в процессе так же задумался над переносимостью и... ребят я даже немного потерялся.

Порядок байт. Ну начнём с того что например для обработки utf-8 по всем фронтам побитовые сдвиги и чтение отдельных битов, ну вроде ладно чё, в чём проблема, а проблема например в том что порядок байт разный и что мне определять сначала что у меня sparc64 или i386 а потом уже с учётом этого читать байты с конца или с начала?

Атомарность. Ну хорошо 32bit умирает, но мне пофигу если я пишу библиотеку то я хочу что бы она работала везде, ладно у меня может не быть uint64_t и знание того что где то long 64bit, а где то 32bit и я могу смело (да?) писать unsigned long long и быть уверенным что в 64 битной системе это 64 а в 32 битной это тоже 64 но эмулируется через два 32битных инта и вот тут как бы уже нет гарантий что операции записи переменной или чтения отработают.

Вернусь к типам. Мне нравиться что у меня богатый выбор типов на все случаи жизни и конструкции для создания своих типов, а также смешанные типы (union). ладно я могу «впереди планеты всей» и иметь целевую платформу x86_64, а на остальных... ну ломается логика и х** с ними, но что будет когда придёт x86_128, не ржите я серьёзно если я использую (вынужден) в случае utf-8 использовать битовые операции каков вариант что снова придётся что-то менять. Ах да, касаемо тонны zise_t ptrdiff_t u/int8/16/32/64_t fast хераст и прочих что являются typedef от фундаментальных char/short/int/long/long long/ + signed/unsigned, я правильно понимаю что нет никакой разницы пишу ли я uint64_t или unsigned long long int ?

libc Эмм, с89/с99/с11 где то напрямую отказываются от поддержки стандарта msvc не хочет с99 реализовывать в полной мере, тоесть уже нет гарантий, ладно на дворе почти 2018 надо с11, но и тут glibc не имеет <threads.h> а musl имеет, как при этом всём гарантированно быть уверенным что у меня есть гарантия реализации стандарта. Как жить :D И да в случае если на какой либо системе нет <stdint.h> и я намеренно пишу unsigned long long int подразумевая (на данный момент) uint64_t это нормально?

Ну больше писать не буду хотя есть что, я не профессиональный программист да и просто программистом себя назвать не могу в полной мере, мне нравится «С» и вроде как получается писать что-то что работает на моей машине.Но прихожу к выводу что я не знаю как на нём писать нормальный и переносимый код.

Дайте советы если есть желание или почитать что что-бы просвятиться. У меня есть желание писать железный код, но чем больше я закапываюсь во всём этом тем меньше понимания как собственно его писать железно.

Выдыхаю ::) Ну и по традиции cast сишников i-rinat, beastie, ncrmnt, Iron_Bug, peregrine, xpahos, anonymous_incognito, ncrmnt, DELIRIUM.

Товарищи, есть ли для perl какая-либо штатная, либо XS-ная реализация open, которая возвращает значением собственно файловый дескриптор?

Просто странно, что это одна из самых косячных функций штатного рантайма, возвращающих результат через переданный её параметр - и неужели никто её не заменил на что-то более адекватное?

Понятно, что перловой функцией делается в три буквы:

my %modeName2modeCryptoSymbols=(
 'read' => '<',
 'write' => '>',
 'append' => '>>',
 'edit' => '+<'
...
);
sub fopen ($$) { open my $fh, $modeName2modeCryptoSymbols{$_[1]}, $_[0]; $fh }

Но нет ли сишной готовой реализации? Просто встроенный оператор open в традиционном перловом виде - это какое-то «привет BASIC'у образца 80-х», потому что современный BASIC уже давно так не делает...

Добрый день,

В первую очередь хотел бы задать вопрос к ckotinko и i-rinat. Вас я считаю весьма адекватными и опытными и прошу вашего совета. Но не откажусь от совета кого-либо другого.

Заранее извиняюсь если кастанул не по адресу. В общем ситуация такова:

Я знаю что оба работали/работаете с С, с чистым С. Возможно ли человеку без реального опыта работы каким-либо образом прокачать в этой сфере настолько хорошо, что можно будет найти работу где-нибудь в Европе? Ситуация у меня такая, что живу в Минске и контора, которым нужен разработчик С, единственная, и туда я точно не пойду.

Возможно ли взять и присоединиться к какому-нибудь опенсорсному проекту на С и в перспективе получить оффер в Европу? Может быть нужно реализовать свой проект для этого, и если да, то какой?

Если это возможно, то смогу ли я это сделать занимаясь этим часа по 2 каждый день?

Не подумайте что я какой-нибудь тракторист, просто мне в самом деле нравится С, я бы и для линуксового Ядра что-нибудь писал и драйверы бы пилил. Но меня останавливает то, что там где живу работы такой нет, и даже если я потрачу туда пару-тройку лет, то это может закончиться ничем. В конечном итоге все чего я хочу - это работать на фулл тайм с С.

Образования у меня именно по железу нет, все изучаю сам по книгам, по физике то же самое, знания на уровне пятого класса школы. Я готов все это выучить, но не знаю получится ли что-то в перспективе.

Ну или может быть нет никакого смысла в этом всем и мне лучше продолжать работу с С++ и Qt?

Я кастовал ckotinko еще по одной причине. Я знаю что ты работал в AMD, так вот зная как оно там, могут ли взять такого самоучку туда или просто посмеются надо мной?

Перемещено leave из development

Доброго дня комрады! Настраиваю связку nginx+gunicorn+memcached+postgre На данный момент уперся в использование 2х БД по принципу: Если одна не доступна использовать вторую. в setting.py

DATABASES = {
    'default': {},
        'users1': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'gunicorn',
        'USER': 'gunicorn',
        'PASSWORD': 'gunicorn',
        'HOST': '10.230.40.194',
        'PORT': '5432',
    },
        'users': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'gunicorn',
        'USER': 'gunicorn',
        'PASSWORD': 'gunicorn',
        'HOST': '10.230.40.195',
        'PORT': '5432',
        }
}
DATABASE_ROUTERS = ["db_router.ProjectDbRouter"]

Далее в корне проекта нужно создать project_db_router.py Но как его правильно заполнить для моей задачи я не знаю, ибо в программировании нуб, что печально. Вот вырезка с оф сайта

class AuthRouter(object):
    """
    A router to control all database operations on models in the
    auth application.
    """
    def db_for_read(self, model, **hints):
        """
        Attempts to read auth models go to auth_db.
        """
        if model._meta.app_label == 'auth':
            return 'auth_db'
        return None

    def db_for_write(self, model, **hints):
        """
        Attempts to write auth models go to auth_db.
        """
        if model._meta.app_label == 'auth':
            return 'auth_db'
        return None

    def allow_relation(self, obj1, obj2, **hints):
        """
        Allow relations if a model in the auth app is involved.
        """
        if obj1._meta.app_label == 'auth' or \
           obj2._meta.app_label == 'auth':
           return True
        return None

    def allow_syncdb(self, db, model):
        """
        Make sure the auth app only appears in the 'auth_db'
        database.
        """
        if db == 'auth_db':
            return model._meta.app_label == 'auth'
        elif model._meta.app_label == 'auth':
            return False
        return None

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        'LOCATION': ['10.230.40.192:11211', '10.230.40.193:11211',]
       'OPTIONS': {
            'MAX_ENTRIES': 1000,
               'TIMEOUT': 60,
        }
    }
}

Вот и прошел примерно год с момента установки Void Linux. В целом впечатления от дистрибутива крайне положительные, ничего не ломалось за год и все обновления проходили безболезненно. Здешний runit пусть и выглядит довольно тривиальным на фоне OpenRC/systemd, но я его один раз настроил и забыл. Навевает атмосферу того самого старого Arch, которым он был до определенных изменений. :)

За прошлый год я перебрался сначала с vim на neovim в январе, а затем осенью пересел на Emacs с evil'ом примерно в то время, когда свет увидел vim 8 версии.
Ориентироваться в экосистеме Эмакса изначально было довольно трудно (у вимеров и эмаксеров, как оказалось, совершенно разное представление о документации), но на выходе я получил более монолитную, более функциональную и настраиваемую среду, в которую оставалось добавить только редактор. В vim'e мне довольно сильно досаждала лапша среди языков для расширений и слабая интеграция самих плагинов между собой.
Скорость? В боевом варианте nvim с автокомплитом и filetype плагином не намного быстрее настроенного Emacs'a, как оказалось. Да, vim быстр и удобен в консоли для правки конфигов или написания скриптов, но для более нетривиальных задач приходилось делать много лишних телодвижений. Я не агитирую бросать vim под предлогом «это плохой редактор» — нет, это действительно годный редактор для определенных задач и пользователей, но если вы ощущаете дискомфорт при разработке, то можете попробовать Emacs.

Скриншот с окнами: Thunar, termite с запущенным ncmpcpp и viewnior

Основной скриншот в png

На скриншотах:

• Void Linux с i3
• Polybar с практически дефолтным конфигом
• Emacs с собственной недопиленной темой и telephone line
• GTK: Ashes
• Icons: Arc
• Шрифты: Noto Sans в gtk, Roboto Mono в терминале и Emacs'e, Roboto для панели
• Тема termite: Base16 Plateau
• ncmpcpp: чуть переделанный конфиг отсюда
• Wallpaper: тык, тык

Мои конфиги пока не готовы к выпуску в свет.

>>> Просмотр (1920x1080, 375 Kb)

Написал тривиальную заглушку:

#!/usr/bin/python
# -*- coding: utf-8 -*-

import falcon

class Api:
        def on_get(self, req, resp):
                resp.body = ""

app = falcon.API()
app.add_route("/",Api())

gunicorn -w 25 -b 127.0.0.1:8000 test:app

Проверил с помощью apache2-utils:

ab -n20000 -c20 http://127.0.0.1:8000/

Выдало 3000 req/s, 6,7 ms/req.

Если сделать подобное на Flask:

#!/usr/bin/python
# -*- coding: utf-8 -*-

from flask import Flask

app = Flask(__name__)

@app.route('/', methods=["GET"])
def index():
  return ""

from werkzeug.contrib.fixers import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app)

if __name__ == "__main__":
  app.run(host = "127.0.0.1", port = 5500)

gunicorn -w 25 -b 127.0.0.1:5500 test:app

ab -n20000 -c20 http://127.0.0.1:5500/

Откуда официальный бенчмарк с CPython даёт 37 тыс req/s? https://falconframework.org/
и рост производителности Flask -> Falcon в 10 раз. У меня получился рост числа запросов в полтора раза.

(Дня всем)

(Вопрос «Есть ли что-нибудь интересное и стоящее на эту тему?»)

(Ремарка «Близкие по духу тоже катят, но все же хочется про смайликовые языки»)

(PS «Можно [не] тыкать в корявость лиспопоста»)

Хочу вот перевести свою поделку на uvloop, но столкнулся с такой вот проблемой.

Код:

import asyncio

import uvloop


async def test(loop):
    transport, protocol = await loop.create_datagram_endpoint(
        asyncio.DatagramProtocol, remote_addr=('45.76.92.79', 26000))
    print(type(transport), transport.get_extra_info('sockname'))

loop = asyncio.new_event_loop()
loop.run_until_complete(test(loop))
asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())
loop = asyncio.new_event_loop()
loop.run_until_complete(test(loop))

Вывод:

<class 'asyncio.selector_events._SelectorDatagramTransport'> ('45.76.92.79', 38734)
<class 'uvloop.loop.UDPTransport'> ('0.0.0.0', 50589)

Почитав сорцы uvloop'а я заметил, что если не указан локальный адрес в аргументах у create_datagram_endpoint, тогда uvloop вызывает socket.bind('0.0.0.0'). Но мне как бы очень нужен локальный айпи, и очень не хочется указывать его в конфиге.

Собственно вопроса два - зачем вызывать бинд на 0.0.0.0, и можно ли как-то автоматически задетектить локальный айпи адрес перед вызовом create_datagram_endpoint?

Какова правильная идеология обработки сигналов?

Правильно ли я понимаю, что должна быть внешняя «перебиралка» всех запушенных в стек обработчиков, которая будет безопасно один за другим их вызывать в изолированном окружении (иначе один обработчик может повлиять на другой, что не предусмотрено в коде самого обработчика).

Просто я смотрю на чужой perl'овый код - и вижу, как там $SIG{'HUP'}=sub {} - и мне плакать хочется. И это далеко не только в каких-то примитивных приложениях, в достаточно серьёзных тоже. Особенно напрягает то, что я-то могу сигналы правильно обрабатывать и честно пушить в $sigHndl{'HUP'} обработчики HUP'а. Но в один непрекрасный момент я могу не заметить, как некий чужой модуль возьмёт и сделает $SIG{'HUP'}=... Да, после этого я найду email чувака и насру ему в почту тонну говна, и не успокоюсь, пока не пойму, что чувак понял, насколько он идиот. Но.. Хотелось бы себя обезопасить как-то от таких вещей.

Поэтому номер раз:

Правильно ли я понимаю, что можно запретить модификацию %SIG'а или как-то иначе заблокировать назначение новых обработчиков?

А ещё все мы знаем, что чудес не бывает, хоть они изредка и мироточат, но в целом к чудесам мы относимся с некоторой настороженностью. Так и с обработчиками сигналов: весьма похоже на то, что обработчик сигнала в лучшем случае может быть прерван другим обработчиком (на самом деле нет). А это, в случае использования идеологии «запихни мне обработчиков в стек» - may lead to навсегда зависшее в самом неожиданном месте приложение. Ну, оно же просто обрабатывало... Соответственно,

Номер два:

А верно ли я мыслю, то обработчики сигнала после срабатывания такового сигнала должны:

1) Обрабатываться в асинхронном цикле: поскольку все обработчики в стеке обязаны быть независимы, нас порядок их запуска вообще не колышет;

2) Реальный код каждого обработчика из стека должен тем или иным способом заворачиваться в «блок, который не может выполняться дольше $nTimeout микросекунд» - это ж, небось, про SIG{ALRM}...

Иначе - ну хорошо конечно, когда всё хорошо, но если уж плохо - то совсем плохо, ибо всё стоит колом и никуда не едет.

Ну и последний вопрос: мне вообще стоит писать микро-фреймворк для запуска стека обработчиков при срабатывании сигналов или кто-то уже делал такое - и только я ещё плоды сего архиполезного труда не нагуглил.

Всем заблаговременной гигантской признательности!

P.S. Я слышал про AnyEvent и даже Mojolicious пользуюсь активно. Вопрос в том, что обработчики сигнала там назначаются по принципу «1 сигнал - 1 обработчик». Соответственно, если в действительности в общем случае нужно ~100500 обработчиков, то их нужно вызывать из того одного обработчика, а в этом-то и загвоздка: что именно должен делать он для более-менее гарантированно стабильной работы приложения?

Юзкейс: К основной программе на Go линкуется сишная разделяемая библиотека, которая будет вызывать колбэк реализованный в Go. Как реализовать сабж?

main.go:

package main

/*
#cgo CFLAGS: -I.
#cgo LDFLAGS: -L. mylib.so

void mylib_init(void *log_f);
void mylib_shutdown();
*/
import "C"

import (
        "log"
        "time"
	"unsafe"
)

func main() {
	C.mylib_init((*C.void)(unsafe.Pointer(logMessage)))
	{
		log.Debug("Serving...")

		time.Sleep(5 * time.Second)
	}
	C.mylib_shutdown()
}

// export logMessage
func logMessage(level C.int, message *C.char) {
	switch level {
	case 0:
		log.Error(C.GoString(message))
		break
	case 1:
		log.Warn(C.GoString(message))
		break
	case 2:
		log.Info(C.GoString(message))
		break
	case 3:
		log.Debug(C.GoString(message))
		break
	default:
	}
}

Код не компилируется. Пробовал другие варианты, но тоже не выходит. В гугле внятного ответа не нашел.

./main.go:155: cannot use (*C.void)(unsafe.Pointer(logMessage)) (type *C.void) as type unsafe.Pointer in argument to func literal
./main.go:155: cannot convert logMessage (type func(C.int, *C.char)) to type unsafe.Pointer

Спасибо.

Например uint32_t* при единичном смещении каждый раз смещается на 4, uint16_t* на 2, и т.п. Мой компилятор показывает 1, но будет ли так всегда?

Я прочитал статью " Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go» " ( https://habrahabr.ru/post/337098/ ), и у меня создалось ощущение, что чувак умом тронулся. Go - хипстерский язык, на который вообще нет никаких стандартов (в отличии от XEP явы), на котором пишут обычно просто мелкие сервисы и утилиты.

Каким образом на go можно писать нормальные сервера, если:
1. это развивающийся язык => никакого энтерпрайза
2. либы отвратительного качества (и количества) => никакого энтерпрайза
3. go изначально проталкивался одним человеком, который упоролся, а гугл выделил ему ресурсы на создание языка.
4. зачем, если есть java для бизнес-логики?
5. зачем, если есть nodejs для вебни? Причём не знаю, почему автор гонит на производительность, на том же хабре была статья, где на nodejs делали http/https-балансер (прокси с ssl-терминацией и оркестрацией виртуалок в облаке, запуская и останавливая их в зависимости от нагрузки).
6. зачем, если есть rust для быстроты и низкого уровня?
7. зачем, если есть python для админских скриптов с кууууучей либ?

Также язык:
1. Не асинхронен.
2. Не предназначен для энтерпрайза.
3. Бинарный (но при этом нельзя использовать для системного программирования, как rust).
4. Неудобный перехват эксепшенов.
5. Плохо документирован.
6. Нету каких-то киллер-фитч, типа (как в той же nodejs) простая организация очереди, тредов (причём нормальных, а не green), позволяя быстро делать многотредовые прилоежния). Или специализация на определенных задачах (например, как php и nodejs на вебне).

В чём соль? Очередной хипстерский хайп или я, как обычно, не догоняю за современной модой, предпочитая классические решения (типа J2EE на IBM i)?

No trolling.

Перемещено beastie из development

https://github.com/cbaggers/varjo

1500 коммитов за 4 года, два контрибюьтора.

• Поддерживает макросы, в т.ч. define-compiler-macro
• Статическая типизация
• multiple-values
• defstruct
• ограниченная поддержка ф-й первого класса (функции должны быть разрешены статически)
• inline GLSL expressions
• WIP for declare and extensible declaration identifiers
• проверка типов внутри и между этапами шейдинга

Остальное не понял.

> (ql:quickload :varjo)

Сабж.

Сегодня перевел статейку на Швабру, и там у автора прямо истерика случилась на тему - ни за что не храните в докере данные.

Аргументация про то, что де когда докер оказывается под нагрузкой, в нем ломается всё что подключено, а если не повезет - уносит вместе с корневой файловой системой (на линуксе), и паники ядра постоянно, так что данные не держатся.

Насколько это всё реально? У вас есть какая-нибудь нагруженная БД в докере на проде, как полёт?

Всем привет. Недавно начал знакомство с Docker,вроде все понятно, но есть несколько вопросов.

1.Использование БД в контейнере. Не нашел причин по которой нужно БД в контейнере держать. Маунтить хостовую папку чтоб данные не потерялись, и т.д. с логами понятно еще, но с БД не очень понял. Если только это какая то своя БД которая относится к этому сервису Redis и т.д. В каких случаях лучше хранить БД в контейнере? Если процесс умер и я заново запущу контейнер, БД сразу нормальная будет или нужно что то разворачивать?

2.В докер-файле можно указать команду которая выполнится после запуска контейнера.Мне нужно запустить контейнер чтоб он отработал и умер. Команда которая выполняется при запуске с параметрами. Могу ли при запуске контейнера передать входящие параметры, которые бы использовались в команде или, например, при запуске передать строкой саму команду?

Я не думаю, что кого-то можно впечатлить принципиальной возможностью запустить 10к потоков для обслуживания клиентов. Когда говорят про встанет раком, имеют в виду неоправданную потерю производительности.

Если ты готов померять реальный перформанс, пиши, я налабаю на еполле аналоги твоих тестовых серверов, чтобы не ты один тратил своё время. Меня например больше в всего в контексте этого спора интересует, как поведёт себя сервер с 10к потоков например на 4 ядрах против еполльного на одном таком же ядре, в вариантах без локов и с.

Результаты исследования можешь запостить на ЛОРе и восстановить честь среди пятизвездочных 😝

Начало дискуссии где-то рядом в удаленных по инициативе какого-то наркомана.

PS скорее всего я отвечу не раньше ночи или следующего утра.

У меня складывается стойкое ощущение, что использование классических супер-эффективных алгоритмов со всякими чудесными O(n) в современных реалиях, когда серверы со 128-ю процессорными ядрами стали скорее нормой, чем роскошью - в общем, это похоже на маразматическое ретроградство и заскорузлость мозга в принципиальном нежелании критически оценивать свои «бесценные» университетские знания, полученные от людей, не всегда догадывающихся о существовании многопоточности.

На мой взгляд, в современных реалиях наиболее эффективно себя показывают алгоритмы «разделяй и властвуй» наподобие QuickSort'а - т.е. те алгоритмы, которые позволяют разбить выполнение задачи на множество параллельно выполняющихся подзадач. А программистов, не задумывающихся о распараллеливании, синхронизации и склейке результатов - нужно гнать из профессии ссаными тряпками, сколько бы ни было у них гонора в связи с тем, что они всего Кнута выучили наизусть.

Это сугубо моё мнение, которое никому не навязываю, зато предлагаю открытую дискуссию.

В свое время давным-давно до меня доносился звон что эксепшены в плюсах реализованы через жопу, и что в отличие от какой-нибудь там джавы, где обработка исключительных ситуаций с помощью эксепшенов - это нормально и хорошо, в плюсах ими лучше лишний раз не пользоваться. Что, мол, организация стека в сях какая-то не такая, и что компиляторы костыли специальные городят чтобы корректно поднимать исключение наверх по вызовам, и всякое такое.

Кто-нибудь может накидать каких-нибудь технических статей на тему как следует или не следует применять эксепшены в плюсах?

UPD:
Из любопытного
почитать (стр. 32)
посмотреть

Вяло почитываю про сегментную адресацию первых интеловских камней. (Чувствую себя немного Сальвадором Дали, который тыкал палочкой дохлого ежа).

Я не понимаю, зачем инженеры intel забабахали такую замороченную систему? Сегмент FFFF, к нему камень добавляет 0, чтоб сегмент указывал на границу «параграфа», к этому плюсуется FFFF смещение. Получается вместо требуемых 1 048 576 ячеек – 1 114 096. Неадресуемая память. Плюс к этому смещение может перекрыть параграф, а значит адрес может быть описан разными парами сегмент+смещение. Что, потенциально, может привести к ошибкам.

Возникает вопрос – анакуа Зачем? Зачем 16-битное «смещение»? Зачем плюсование? Логичней ведь просто добавлять последний полубайт?

Или я чего-то не понимаю?