Есть ли лучше с? [закрыто]
Вы использовали псевдоним для имени таблицы, но во время объединения не использовали. Вот почему выдается ошибка, поэтому используйте псевдоним в соединении:
Select
d.id, d.Regnr, d.Name, d.LitterId, l.FatherId, l.MotherId,D1.Name as fathername,
D2.Name as motherName
From dbo.Litters L
left join dbo.Dogs D
on d.LitterId = l.Id
left join dbo.Dogs D1 on L.FatherId=D1.ID
left join dbo.Dogs D2 on L.MotherId=D2.ID
where
d.Regnr = 'NO34567/2012'
id Regnr Name LitterId FatherId MotherId fathername motherName
3 NO34567/2012 Fido 9000 2 1 king Queen
7 ответов
Rust
Другим (реальным) кандидатом на лучшее C является Язык программирования Rust .
В отличие от некоторых других предложений, (Go, Nimrod, D, ...) Rust может напрямую конкурировать с C и C ++, поскольку имеет ручное управление памятью и не требует сборки мусора (см. [1]). < / s>
Отличительной особенностью Rust является то, что он имеет безопасное ручное управление памятью . (Ссылка на блог pc Walton, одного из основных авторов Rusts и, как правило, заслуживает прочтения;) Среди прочего, это означает, что она исправляет миллиардную ошибку нулевых указателей. Многие из других языков, предлагаемых здесь, либо требуют сборки мусора (Go), либо включают сборку мусора, включенную по умолчанию, и не предоставляют средств для безопасного ручного управления памятью сверх того, что обеспечивает C ++ (Nimrod, D).
Несмотря на то, что у Rust есть императивное сердце, он действительно заимствует много хороших вещей из функциональных языков, например, типы сумм, называемые теговыми союзами. Он также действительно заинтересован в том, чтобы быть безопасным и ориентированным на производительность языком.
[1] В настоящее время существует два основных типа указателей , принадлежащих указателям (например, std :: unique_ptr в C ++, но с лучшей поддержкой со стороны проверки типов) и управляемых указателей , Как следует из названия, последний требует локальной сборки мусора для задач, но существуют мысли удалить их из языка и предоставить их только в виде библиотеки.
Отредактировано, чтобы отразить комментарий @ReneSacs: Сборка мусора не требуется в D и Nimrod.
Ним (бывший Нимрод) имеет мощную систему типов, с понятиями и простыми обобщениями. Это также показывает обширные механизмы времени компиляции с шаблонами и макросами. Он также имеет простую C FFI и все низкоуровневые функции, которые вы ожидаете от языка системного программирования, так что вы можете написать свое собственное ядро , например.
В настоящее время он компилируется в C, так что вы можете использовать его везде, например, в GCC. Если вы хотите использовать Nim только в качестве лучшего языка C, вы можете сделать это с помощью переключателя компилятора --os:standalone, который дает вам стандартную библиотеку без костей, без связей с ОС.
Например, для компиляции в микроконтроллер AVR вы можете использовать:
nim c --cpu:avr --os:standalone --deadCodeElim:on --genScript x.nim
Nim имеет мягкий ГХ в реальном времени, где вы можете указать, когда он запускается и максимальное время паузы. в микросекундах. Если вы действительно не можете позволить себе GC, вы можете полностью отключить его (--gc:none переключатель компилятора) и использовать только ручное управление памятью, например C, потеряв большую часть стандартной библиотеки, но при этом сохранив гораздо более разумную и мощную систему типов.
Кроме того, теговые указатели являются запланированной функцией, которая гарантирует, что вы не смешаете указатели уровня ядра, например, с указателями уровня пользователя.
Я не уверен, в каком состоянии находится Cyclone, но это обеспечило большую безопасность для стандарта C. D также может считаться «лучшим C» в некоторой степени, но его статус не очень ясен с его сплит-мозг в стандартной библиотеке.
В качестве «лучшего C» я выбрал язык OOC . Он еще молодой, но довольно интересный. Это дает вам ОО без убийственной сложности C++. Это дает вам легкий доступ к интерфейсам C (вы можете «покрывать» структуры C и использовать их обычно при вызове внешних библиотек / таким образом управлять планировкой памяти). Он по умолчанию использует GC, но вы можете отключить его, если вы действительно этого не хотите (но это означает, что вы больше не можете использовать стандартные библиотечные коллекции без утечки).
В другом комментарии упоминалась Ада, о которой я забыл, но которая напомнила мне: есть Oberon, который должен быть безопасным (-er) языком, но также содержит механизмы сборки мусора.
C ++ не решает эту проблему. И я не хочу использовать C ++ в любом случае. Я считаю, что ОО-классы и шаблоны являются головной болью.
Преодолей это отношение. Просто используйте C ++. Вы можете начать с кодирования C на C ++ и постепенно переходить к лучшему стилю.
Я мало что знаю о Haskell, но если вам нужна сильная система типов, взгляните на Ada. Он широко используется во встроенных системах для аэрокосмических приложений. Девиз SIGADA: «Мы доверяем строгой типизации». Однако это не принесет особого смысла, если вам придется делать драйверы устройств типа Windows / Linux.
Несколько причин, по которым он не так популярен:
- подробный синтаксис - предназначен для чтения, а не для записи
- компиляторы исторически были дорогими
- отношениями с Министерством обороны и дизайн-комитетами, которые программисты, кажется, выбивают
. Я думаю, правда в том, что большинство программистов не любят строгие системы типов.
D может предложить то, что вы хотите. Он имеет очень богатую систему шрифтов, но вы все равно можете управлять макетом памяти, если вам нужно. Он имеет неограниченные указатели, такие как C. Он собирает мусор, но вы не обязаны использовать сборщик мусора, и вы можете написать свой собственный код управления памятью, если действительно хотите.
Однако я не уверен, в какой степени вы можете смешать богатство шрифтов с низкоуровневым подходом, который хотите использовать.
Сообщите нам, если найдете что-то, что соответствует вашим потребностям.
Вы также можете посмотреть BitC . Это серьезный язык, а не игрушка, но он еще не готов и, вероятно, не будет готов вовремя, чтобы быть вам полезным.
Тем не менее, конкретная цель дизайна BitC - поддерживать низкоуровневую разработку в сочетании с системой типов в стиле Haskell. Первоначально он был разработан для поддержки разработки микроядра Coyotos. Я думаю, что Coyotos был убит, но BitC, по всей видимости, все еще находится в стадии разработки.